这学期新增了《软件需求与分析》这门课程，通过阅读“我们应当怎样做需求分析”这篇博客，使我对这门课程有了初步的了解。
“需求分析既是一份体力活儿，更是一份技术活儿，它既是人际交往的艺术，又是逻辑分析与严密思考的产物。”有的项目开发是成功的，但也有许多失败的项目开发各有各的问题，把这些失败的一个个进行分析，会发现有的是需求的问题，有的是客户关系的问题，还有设计的问题、技术的问题、时间管理的问题、人员培养的问题......但归根到底更多的还是需求的问题。由于我们需求分析过程中的各种隐患造就了我们项目的失败。所以我们就需要了解应该怎样做需求分析。
1、需求调研
这是需求分析最重要的一环，也最集中的体现了需求分析的特点，既是一份体力活，更是一份技术活，既要求我们具有理解能力和设计能力，还要求我们具有与人交往沟通的能力。
（1）初识
与客户应当保持适当的谦卑，但却不可过度谦卑。对客户提出的需求深入理解后，运用我们的专业知识，提出更加合理，可操作的方案，让客户感觉自己说的就是想要的，这样客户会欣然接受自己的方案，而且自己在客户心目中形象也会提高。人与人交往，往往在接触的初期就决定了相互的行为方式，而与客户交往也是一样，我们要对自己有足够的信心，并且还要有循循善诱的表达能力，这样就会在客户心中形成一种威信，使项目向着一种良性的方向前进。
（2）拜访
需求调研不是一蹴而就的事，是一件持续数月乃至数年的工作。这段时间里，我们需要依靠客户这个群体的帮助，一步一步掌握真实可靠的业务需求。我们要分析一个客户人群的关系，我们要找到自己最可以依赖人，然后与他们建立战略合作伙伴关系。
（3）研讨会
业务研讨会是重要的，但也是灵活的，并没有一个特定的形式，需要根据实际情况，合理的与客户组织研讨会，不管怎样，一定注意两点：有效抑制个性化差异、分模块组织专项研讨会。
（4）需求研讨
做需求分析，眼界不能只停留在软件本身，应更开阔一点，扩展到跟这个业务有关的那些领域中。需求分析不是一种简单的你说我记的收集活动，而是在大量业务分析与技术可行性分析基础上的分析活动。
（5）迭代
需求分析是一个反复迭代的过程，从第一次需求分析开始，一直持续到整个项目生命周期。第一次需求分析阶段需要与客户进行反复讨论，这个过程往往是反复循环的：需求捕获->需求整理->需求验证->再需求捕获••••••
（6）需求捕获
需求捕获是我们最薄弱的环节，不仅仅是一个技术的问题，还涉及到人际交往、沟通、知识理解以及心理学等一系列问题。在这个过程中最容易犯错的问题是一个态度的问题，是采用主动态度还是被动态度去捕获需求。如果客户说什么就记什么，客户处于强势地位，而我们唯唯诺诺，这样记住客户说的每句话转身丢给开发人员，这就是采用被动的态度捕获业务需求的方式，这样的需求分析势必会给项目开发后期带来巨大风险。
当我们深入理解了客户现有的操作流程后，应当有意识发现那些不合理的部分，并最终提出更加合理、更适合信息化管理的流程。
2、需求分析
（1）功能角色分析与用例图
需求分析不应当是太公钓鱼，而应是拉网排查，任何一个疏忽都可能对项目研发带来风险。一般来说，信息化管理类软件项目通常从这几个方面着手分析：功能角色分析、业务流程分析与业务领域分析。在需求分析初期，我们对需求的认识往往是整体的、宏观的，随着分析工作的逐渐深入，一步步细化。功能角色分析就是从一个外部用户的视角分析整个软件系统能够提供的功能，以及这些功能到底是提供给哪些角色使用。
（2）业务流程分析
我们将从客户调研现场拿回来的需求，经过一番功能角色分析，整个系统的整体脉络与轮廓已经被勾画出来。进行业务流程分析就是要分析业务流程中哪些是需要信息化管理的，而哪些则不需要。信息化管理过细会加重基层业务人员的负担，适当的信息化管理可以提高工作效率。
（3）用例说明
在现在面向对象的时代绘制行动图、状态图以及编写用例说明来完成这部分工作，其中编写用例是最主要的工作。用例分析实质是需求人员的一份设计。每次需要升级时，添加新的需求，或对以往需求进行更新。
（4）查询报表分析
一个有效的报表，往往不是对数字的简单堆砌，它通过一组一组的数据，揭示的都是一些客观规律、复杂活动与发展趋势。报表作用体现的是报表对于不同用户的真实意图；输出列体现的是对各个数据项及其数据来源的说明；假设与约束罗列的是报表中各个数据项的运算公式、数据规则与约束；还有使用频率、数据链接、非功能需求，以及最后的界面原型，等等。
（5）子用例与扩展用例
用例分析中对子用例与扩展用例的分析，使我们对系统的设计，从一开始就将公共的、可共享的部分提取出来，使我们在日后的设计与开发中得以很好地复用，提高了系统的内聚并降低了系统的耦合，是一个优秀软件设计的开始。
（6）行动图和状态图
在使用状态图时，一个非常关键的概念就是，一定是对某个关键对象的状态变化的描述，而这些状态变化一定是在某个业务流程的大背景下进行的。 需求分析中，状态图并不是必须的，它仅仅出现在你认为需要对某个对象的状态进行说明的时候。
（7）业务领域分析
进行业务领域分析，就是通过与用户进行交流，掌握领域知识，然后绘制成业务领域模型，去指导我们软件开发的过程。可以通过两种分析方法一步步进行：原文分析法与领域驱动设计。
（8）原文分析法
原文分析法，是在用例说明与流程分析的基础上进行的业务领域分析，是一项在需求研讨会后整理和分析需求的工作。当我们完成了用例图的绘制，为每个用例编写出用例说明以后，原文分析的工作就可以开始了。可以让我们准确而高效地完成业务领域分析。
（9）领域驱动设计
需求人员在开始一个新的管理系统的分析工作时，都有可能面临着一个全新的业务领域。需要时间学习领域知识，但并不意味着学习所有的领域知识，而是与软件相关的领域知识。每认识深入一点儿，就可能会体现到你的分析设计中，并最终体现在开发的软件中。
（10）非功能需求
进行非功能需求的分析时，除了制订整体的原则以外，还要落实到各个具体的功能中，将这些功能所潜在的、特殊的非功能需求挖掘出来，提前进行分析设计，对于可行性不高的应及时与客户商讨，才能有效地避免日后存在的这些方面的风险。
3、需求确认
（1）需求列表
需求列表是经过由粗到细逐渐整理形成的。一个大的需求项目可以分解为多个细的需求项目，进而形成一个树状的需求列表。只要将系统需求描述清楚为宜。需求列表也是一个不断变化的过程，日后的每一次升级维护都需要不断增添和修改需求列表，使其与实际系统保持一致。
（2）快速原型法
在给用户看到原型前，一定要跟用户解释清楚。 根据实际情况灵活运用原型法，可以更加顺畅地与用户确认需求。
（3）需求规格说明书
需求规格说明书分为用户需求规格说明书和产品需求规格说明书不同的公司、不同的人、不同的项目，特别是在需求分析中采用不同的方法，写出来的需求规格说明书格式都是不一样的。
（4）评审与签字确认会
先召开内部评审会，然后召开外部需求评审会，也可称为签字确认会议，就是与用户就需求规格说明书进行评审，最后签字确认。