p.p1 { margin: 0.0px 0.0px 0.0px 0.0px; font: 11.0px "PingFang SC"; color: #000000 }
p.p2 { margin: 0.0px 0.0px 0.0px 0.0px; font: 11.0px "Helvetica Neue"; color: #000000; min-height: 12.0px }
span.s1 { }
span.s2 { font: 11.0px "Helvetica Neue" }
通过阅读《我们应当怎么做需求分析》我了解了需求分析需要进行的阶段，以及需要掌握的内容。
需要掌握的内容如下：
（1）需求调研：其中包括如何与客户交流、建立良好的合作关系、通过研讨会与客户交流获得项目的原始需求并对需求进行研讨，并采用迭代的方式进行需求的不断完善。
（2）需求分析：分析用例、分析业务流程、构建用例说明、其他例如查询功能的分析、子用例及扩展用例的分析、行动图和状态图、业务领域分析、原文分析、非功能需求分析。
（3）需求确认：列出需求列表得到用户确认、利用快速原型法得到用户的确认、构建需求规格说明书。
一、需求调研
1、与客户初识：
要树立良好的职业威信。不要在客户面前唯命是从，要适当地提出自己的见解，这样不但会让客户对自己有信心，而且自己也可以规范化客户的需求，不至于客户提出什么我们就按照客户说的做什么。
进行详细的角色分析，对号入座。客户方有很多的角色，每一个角色都有自己独特关注的地方，要合理地进行角色分析，让他们了解他们所希望了解的问题，对于需求的调研分析非常地重要。
从宏观上制定目标。在将角色进行分析后，要对每一个角色进行特定地分析，与各个角色进行详细地业务分析，详细了解业务的流程，对于需求的分析非常重要。
2、拜访客户
需求分析需要与客户进行交流，与人交流就要处理好与他人的关系，我们应该在项目的整个过程中与客户建立良好的友谊关系，好的关系可以提高交流的效率。客户是一个大群体，有很多部门，有的部门与项目关联较大，有的则关联较小，不管关联大还是小我们都要与客户建立良好的友谊关系，这对项目的良好开展非常地重要。
3、开研讨会
将项目负责人以及客户代表聚到一起开需求研讨会是非常重要的，在研讨会上可以详细地对项目进行需求分析，将客户聚到一起一方面可以将各个部门的客户的需求统一化，避免每个部门的需求不一致，导致项目需要开发很多的版本，导致项目太大开发困难而且不容易维护；另一方面可以将各个部门的需求进行分析，取长补短，从而制定一个好的项目。
4、进行需求研讨
需求研讨是在客户提出需求时，需求人员对客户的需求进行可行性分析，因为客户一般都是非专业人员，对项目的开发不了解，以致于提出的需求不合理或者很难实现，所以需求人员需要对希求进行可行性分析，如果客户提出的需求不合理则应该充分了解客户为什么会提出这项需求，客户究竟想要实现什么功能，充分了解客户，充分理解需求，制定出替代的方案，然后跟客户进行协商，以达到客户的满意和自己项目的正常进行。
5、迭代
在从客户那里得到需求后，我们应该分析用户的每一项需求，对需求进行分析，绘制类图和对象图等，详细地进行设计分析，然后不断地与客户进行交流，细化需求，进行迭代开发，每次多理解一点，最终使软件更接近用户的满意。
6、需求捕获
从客户那里得到需求是需求分析的关键，如何从客户那里捕获需求，捕获的需求是否明确非常重要，我们应主动地从客户那里捕获需求，不能被动地捕获，这样可以有效地分析客户业务的详细流程，了解由谁来操作，并了解为什么要这样操作，深入地了解这些领域和知识，另外因为我们对客户的业务不熟悉，我们要主动地对客户进行询问，深入明确地了解用户的需求和业务流程。大多数客户对于软件开发并不专业，所以很有可能会遗漏一些东西，需求人员应该深入分析客户的需求，提出客户遗漏的东西，使需求更接近与客户真正的需求。
二、需求分析
1、功能角色分析与用例图
我们应根据需求分析角色，分析出各个角色的功能，绘制用例图，其中包括参与者、用例与系统边界。用例图是提供给客户看的，所以不应该出现技术性较强的表达方式，应该用客户易懂的词语进行功能描述，从而让客户了解我们了解到的需求，并提出修改意见。
2、业务流程分析
应根据需求对业务流程进行分析，分清系统外和系统内，将需要信息化管理的部分进行开发，不需要信息化管理的部分则不开发，使软件真正地实现提高工作效率，而不是加重负担。
3、用例说明
在进行业务流程分析时绘制用例图能够生动形象地描述我们的分析，但是其会丢失很多信息，所以我们需要有一些文字的描述，就是用例说明。
4、查询报表分析
我们应根据需求实际设计不同的查询报表，报表的内容应符合客户的需求，对必须的内容要加上，不需要的可以删掉。
5、子用例与扩展用例
在基本流程中将多个用例所共有的，可以相互共享的流程，将这些流程提取出来就是子用例，这样提取公共部分提高了系统的内聚降低了系统的耦合。
6、行动图和状态图
用例图只是描述了某一个用例自己的功能，而各个功能很分散，没有联系，所以需要行动图和状态图来将各个模块组织起来，来对业务进行整体的描述。状态图描述了业务流程状态的转换，可以清晰地展现各个业务流程。
7、业务领域分析
业务领域分析就是通过与该业务领域的专家进行学习，了解该领域的一些基础知识，然后构建该领域的知识体系，了解该领域需要什么实体，并可以对业务流程更加熟悉，有助于在项目开发中进行参考，从而提高项目的正确性和提高项目的开发效率。
8、原文分析法
原文分析就是分析需求的原文，提取出业务领域的名词，对名词进行分析提取出业务领域的实体。
9、非功能需求
非功能需求包括可用性、可靠性、性能、可支持性以及其他，非功能需求时需求人员非常容易忽略的，但是确实对软件开发非常重要的，某一方面考虑不周全，可能会导致软件的失败，例如界面不友好，性能差，支持性差等都会导致客户不想使用导致软件开发的失败。
三、需求确认
在开始因为没有实物，客户往往描述不清楚自己的确切需求，所以需求往往不明确，我们应该根据用户的初步需求利用快速原型法快速构建出一个实物供用户参考，然后再让用户提出更深一层次的需求，从而不断地深化、细化需求，从而使用户的需求都展现给需求人员。我们不能仅利用用户原始的需求进行开发，应该制定用户需求规格说明书，因为用户描述的需求是脱离了技术实现的，所以我们应该编写自己的需求规格说明书，本着实事求是、切实可行的态度去描述用户的业务需求。
关联关系：
