我们应当怎样做需求分析？
成功的软件项目都是一样的，失败的项目却各有各的问题。不过归根到底还是需求的问题。正是我们在需求分析过程存在的巨大隐患，最终导致了那么多项目的失败。
只有深入地去理解客户的业务，最后做出来的东西必然是客户满意的。当客户提出业务变更的时候，一定不能被客户牵着走。要从业务角度深入的去分析，他为什么提出变更，提得合不合理，我有没有更合理的方案满足这个需求。当我们提出更加合理的方案时，客户是乐于接受的，变更也变得可控了。
客户提出的原始需求往往是不考虑技术实现，基于非计算机管理的操作模式提出来的。但我们作为技术人员，需求分析必须实事求是的、基于技术可以实现的角度去考虑。所以我们必须要基于技术实现去引导客户的需求。
软件项目的需求调研首先必须要进行角色分析，然后对不同的角色分别进行调研。
在敏捷开发过程中，需求分析阶段不可能解决所有的需求问题，因此在设计、开发、测试，直到最终交付客户，这整个过程都应当不停地用开发的成果与客户交流，及时获得反馈。只有这样才能及时纠正需求理解的偏差，保证项目的成功。
我们应当怎样做需求调研？
首先是双方初步认识，这个时候需要树立良好的职业威信，在交谈中进行详细角色分析，将与会各方代表对号入座，最后从宏观上制订目标与方案。
做好初步认识之后，接下来就要一一去拜访这些对应角色了。需求不是一蹴而就，在这漫长的时间里，我们需要依靠客户这个群体的帮助，一步一步掌握真实可靠的业务需求，这都需要有良好的客户关系。按照现在的软件运作理念，软件项目已经不是一锤子的买卖，而是长期的、持续不断的提供服务，这更需要我们与客户建立长期友好的关系。
然后就是研讨会的形式，有大型的会议，更多还是小型的会议研讨，更加深入的交流。
在与客户进行研讨之后，接下来就是内部进行研讨了，讨论客户的潜在需求等问题。
接下来的迭代贯穿于整个开发周期，反复进行。
然后进行与客户交流，挖掘潜在需求。
在挖掘潜在需求之后，就需要重要的建模来表示了。进行功能角色分析和用例图的创建，分析各个角色的作用和相应的操作需求。
与基层人员进行交流，分析业务的流程情况，进行用例说明，
用例说明时，在面向对象的时代，我们则是绘制行动图、状态图，以及编写用例说明来完成这部分工作。在这部分工作中，编写用例说明应当是最主要的工作，之后在一些关键部分辅之以行动图、状态图。需要将图形和文字描述进行结合表达。用例分析实质是需求人员的一份设计。既然是设计就可能出现偏差，最终偏离原始的需求。因此，将需求列表附在用例后面，便于日后的需求评审与确认。当每次需要升级时，则添加上新的需求，或对以往的需求进行更新。
用例图不能描述所有事件，比如报表类的，需要单独做报表分析描述。
用例模型将现实世界中连续的一个一个业务流程，按照场景划分到了一个一个的用例中。由于场景的出现，使得用例中的业务流程存在着高度的内聚性，从而成为了日后各种对象的雏形。同时，在用例分析中，又将那些存在于各个用例中的，相同或相近的业务操作提取出来，形成一个一个的子用例或扩展用例。
用例说明中对业务流程的描述，过早地将系统的整体流程，分散到了各个用例中了，丢失了对业务流程的整体描述。行动图（Active Diagram），比较类似于我们过去绘制的流程图，是UML中描述流程与分支的视图。对关键对象中流程中状态变化的描述，就需要状态图来进行描述。
在需求分析工作中，最后一项分析工作就是业务领域分析啦。业务领域分析，就是对需求分析中涉及到的业务实体，以及它们相互之间关联关系的分析。业务流程分析是对系统进行的一种动态的分析，分析的是那些行为，那些操作。因此，系统中应当有哪些实体，这些实体都有哪些属性，被赋予了哪些行为，它们之间的相互关系是怎样的，就成为了业务领域分析的重要内容，而业务领域分析也就成为了对系统进行的一种静态分析。
进行业务领域分析时，可以采用原文分析法，是在用例说明与流程分析的基础上进行的业务领域分析，是一项在需求研讨会后整理和分析需求的工作。
需求人员在开始一个新的管理系统的分析工作时，都有可能面临着一个全新的业务领域。在这个领域中，他们不可能一夜成为专家，也不必要成为专家。他们需要时间去学习领域知识，但这并不意味着学习所有的领域知识，而是与软件相关的领域知识。对领域模型的认识被延伸到了整个软件生命周期中，包括之后一次一次的升级完善。
我们做需求分析应当化繁为简，不必去拘泥于那些过程。寻找适合自己的，避免做过度分析和设计，这种思想也是敏捷开发的精髓。需求分析人员最容易忽略的部分就是非功能需求。非功能需求更加靠近的是技术，是设计，是实现，是架构师关注的内容，是需求人员最不擅长的方面，这也是非功能需求为什么常常被忽略的重要原因。正因为如此，架构师应当尽早参与到项目中，参与到需求分析中，尽早分析需求的技术可行性，尽早考虑性能、安全性、可靠性等非功能需求，尽早开始架构设计。
下一步就需要做需求列表了，又称之为需求跟踪表，是最原始的、用户对业务需求的描述。它不掺杂任何需求分析人员对业务需求的分析与设计，而是以简短扼要的语句，以业务人员的口吻表述的，今后要开发的这个系统应当提供给他们的各项功能。
首先，需求列表不掺杂我们对业务需求的任何分析与设计，这是需求列表的核心，也是它存在的意义。其次，需求列表应当是站在业务人员的视角，对业务需求的简明扼要的描述。最后，需求列表也不是一步到位的，而是经过由粗到细逐渐整理形成的。
应当在需求分析阶段采用快速原型法，拿出实物，用实物与用户确认需求，
本着实事求是、切实可行的态度，去描述用户的业务需求。那些不可行的需求被摒弃，或者换成更加可行的解决方案。这就是需求规格说明书的重要作用。从理论上讲，需求规格说明书分为用户需求规格说明书和产品需求规格说明书。用户需求规格说明书是站在用户角度描述的系统业务需求，是用于与用户签字确认业务需求；产品需求规格说明书是站在开发人员角度描述的系统业务需求，是指导开发人员完成设计与开发的技术性文档。领域驱动设计所提倡的就是要让用户、需求分析员、开发人员站在一个平台，使用统一的语言来表达大家都清楚明白的概念。从这个角度将，需求规格说明书就应当是一个，不区分用户需求规格说明书和产品需求规格说明书。
最后需要的就是评审与签字确认会。需求评审会的主要目的就是确认需求，以便以此开始我们的设计开发工作。
需要掌握的内容上有：
1.在开发过程中，要有迭代的思想，同时要把迭代用于实践，不断的与客户进行交流反馈，及时获得反馈信息，来进行需求的更新。
2.用例图，活动图等常用uml图的绘制。这些图是描述系统各部分之间联系的表示图形，如果不能清晰的进行表示出来，那说明这个系统还有需要分析的地方。
3.用例说明，同用例图一样重要，用例图不能清楚的反应各个相互联系，还需要语言描述来更加清楚的表达。
4.快速原型法，首先做出主要部分，与用户进行交流，然后再进行下一步。
5.需求规格说明书，文档的书写是非常重要的一个方面，需要提高文档写作的能力。