因为这个学期在上软件需求课，所以老师推荐了一篇关于软件需求分析的博客，读完以后深感软件需求工作的
不容易与难度之大，原来在自己印象中并不是很重要和麻烦的软件需求工作，竟然在软件开发过程占有如此举足轻重
的地位。
因为目前自己能力所限，能做的只是一些小软件，所以在没有接触软件需求分析之前，很难想象到在工程量大的软件工程
项目中，软件需求工作的繁复与重要。软件需求分析中我感觉首先要学会分析，学会选择性接受客户的意见。正如文中作者
所说，我们做的是软件需求分析工作，而很多人把这个分析忘记了，使自己的工作变为客户需求记录员。在整个需求分析中
没有对客户需求的反馈，只是单方面的记录客户的需求，这不仅会使软件工程项目难以进行，而且也会使项目完成后难以使
用户接受。我觉得这种方法是最不可取的。作为专业人员，我们应该在我们的角度对客户的需求进行分析。客户的需求也不尽是
合理的。我们应当在自己分析后，对用户的需求给出合理的反馈，这样对双方都好。第二个我觉得很重要的点，是学会敏捷开发。
软件的需求分析不仅是在软件工程项目的开始，而是要始终贯穿于整个软件开发过程中。正如作者拿自身经历所举的例子，项目从需求分析，
设计，开发，测试都十分顺利，但到了项目进程的后期，想要将开发结果展示给客户时，客户却觉得不满意，而且提出了修改量不小的
意见。虽然项目经过加班，赶工，压缩测试时间等，是项目如期上线，但是上线后才发现有很多bug存在。这件事告诉我们，软件需求不是
一蹴而就的，而是应该贯穿于整个开发过程中，不断分析确认过程。在设计，开发，测试，直到最终交付客户，这整个过程都应当不停地用开发的成果与客户交流，
及时获得反馈。只有这样才能及时纠正需求理解的偏差，保证项目的成功。然后就是用例图的应用。
与基层人员进行交流，分析业务的流程情况，进行用例说明，
用例说明时，在面向对象的时代，我们则是绘制行动图、状态图，以及编写用例说明来完成这部分工作。在这部分工作中，编写用例说明应当是最主要的工作，
之后在一些关键部分辅之以行动图、状态图。需要将图形和文字描述进行结合表达。用例分析实质是需求人员的一份设计。既然是设计就可能出现偏差，
最终偏离原始的需求。因此，将需求列表附在用例后面，便于日后的需求评审与确认。当每次需要升级时，则添加上新的需求，或对以往的需求进行更新。
用例图不能描述所有事件，比如报表类的，需要单独做报表分析描述。
用例模型将现实世界中连续的一个一个业务流程，按照场景划分到了一个一个的用例中。由于场景的出现，使得用例中的业务流程存在着高度的内聚性，从而成为了
日后各种对象的雏形。同时，在用例分析中，又将那些存在于各个用例中的，相同或相近的业务操作提取出来，形成一个一个的子用例或扩展用例。
用例说明中对业务流程的描述，过早地将系统的整体流程，分散到了各个用例中了，丢失了对业务流程的整体描述。行动图（Active Diagram），比较类似于我们过
去绘制的流程图，是UML中描述流程与分支的视图。对关键对象中流程中状态变化的描述，就需要状态图来进行描述。
在需求分析工作中，最后一项分析工作就是业务领域分析啦。业务领域分析，就是对需求分析中涉及到的业务实体，以及它们相互之间关联关系的分析。业务流程
分析是对系统进行的一种动态的分析，分析的是那些行为，那些操作。因此，系统中应当有哪些实体，这些实体都有哪些属性，被赋予了哪些行为，它们之间的相互
关系是怎样的，就成为了业务领域分析的重要内容，而业务领域分析也就成为了对系统进行的一种静态分析。
进行业务领域分析时，可以采用原文分析法，是在用例说明与流程分析的基础上进行的业务领域分析，是一项在需求研讨会后整理和分析需求的工作。
需求人员在开始一个新的管理系统的分析工作时，都有可能面临着一个全新的业务领域。在这个领域中，他们不可能一夜成为专家，也不必要成为专家。他们需要时间
去学习领域知识，但这并不意味着学习所有的领域知识，而是与软件相关的领域知识。对领域模型的认识被延伸到了整个软件生命周期中，包括之后一次一次的升级完善。
我们做需求分析应当化繁为简，不必去拘泥于那些过程。寻找适合自己的，避免做过度分析和设计，这种思想也是敏捷开发的精髓。需求分析人员最容易忽略的部分就是
非功能需求。非功能需求更加靠近的是技术，是设计，是实现，是架构师关注的内容，是需求人员最不擅长的方面，这也是非功能需求为什么常常被忽略的重要原因。正因为如此，
架构师应当尽早参与到项目中，参与到需求分析中，尽早分析需求的技术可行性，尽早考虑性能、安全性、可靠性等非功能需求，尽早开始架构设计。
下一步就需要做需求列表了，又称之为需求跟踪表，是最原始的、用户对业务需求的描述。它不掺杂任何需求分析人员对业务需求的分析与设计，而是以简短扼要的语句，以业务
人员的口吻表述的，今后要开发的这个系统应当提供给他们的各项功能。
首先，需求列表不掺杂我们对业务需求的任何分析与设计，这是需求列表的核心，也是它存在的意义。其次，需求列表应当是站在业务人员的视角，对业务需求的简明扼要的描述。最后，
需求列表也不是一步到位的，而是经过由粗到细逐渐整理形成的。
应当在需求分析阶段采用快速原型法，拿出实物，用实物与用户确认需求，
本着实事求是、切实可行的态度，去描述用户的业务需求。那些不可行的需求被摒弃，或者换成更加可行的解决方案。这就是需求规格说明书的重要作用。从理论上讲，需求规格说明书
分为用户需求规格说明书和产品需求规格说明书。用户需求规格说明书是站在用户角度描述的系统业务需求，是用于与用户签字确认业务需求；产品需求规格说明书是站在开发人员角度
描述的系统业务需求，是指导开发人员完成设计与开发的技术性文档。领域驱动设计所提倡的就是要让用户、需求分析员、开发人员站在一个平台，使用统一的语言来表达大家都清楚
明白的概念。从这个角度将，需求规格说明书就应当是一个，不区分用户需求规格说明书和产品需求规格说明书。
最后需要的就是评审与签字确认会。需求评审会的主要目的就是确认需求，以便以此开始我们的设计开发工作。
需要掌握的内容上有：
1.在开发过程中，要有迭代的思想，同时要把迭代用于实践，不断的与客户进行交流反馈，及时获得反馈信息，来进行需求的更新。
2.用例图，活动图等常用uml图的绘制。这些图是描述系统各部分之间联系的表示图形，如果不能清晰的进行表示出来，那说明这个系统还有需要分析的地方。
3.用例说明，同用例图一样重要，用例图不能清楚的反应各个相互联系，还需要语言描述来更加清楚的表达。
4.快速原型法，首先做出主要部分，与用户进行交流，然后再进行下一步。
5.需求规格说明书，文档的书写是非常重要的一个方面，需要提高文档写作的能力。
