需求分析：12条最佳实践

笔者在咨询实践中总结了针对软件需求工程的12条最佳实践，罗列如下。所谓最佳并非严密的逻辑证明，而是经过大量的实践与观察依据经验确定的，智者见智，仁者见仁，有争议在所难免，仅供参考，能够对大家有所启发，足矣。

1 成立甲乙双方参与的需求控制组
项目的成功不单是乙方的成功，而是甲乙双方的成功，甲乙双方紧密配合，互相理解，互相合作才能成功，需要避免一方独大，一方具有绝对控制权的现象，所以成立甲乙双方参与的需求控制组是避免需求蔓延的有效手段。该组织具有对需求的决策权，对于每项需求的增删改都要平衡了进度、质量、投入后才能确定，该组织不能是一个流于形式的组织，应切实地参与到需求的获取、描述、分析、确认、变更等活动中。

2 识别合适的需求提供者，尤其不要遗漏了最终用户
在获取需求时应该首先识别谁可能有需求，首先识别出来合适的需求提供者，需求的提供者中包括了客户、最终用户、间接用户。客户是掏钱买软件的人，最终用户是使用软件的人，间接用户是对软件有影响力，但是他可能不使用该软件，也不掏钱买该软件，三种类型的角色有可能有重合，三者都决定了软件的需求，可能不同的角色对需求的作用不同，不要忽略了任何一种类型的需求提供者。在很多项目中往往忽略了最终用户的需求，而导致操作层的需求捕获不全，系统在上线时返工很大。

3 定义需求调研问题单
在需求调研的准备阶段，需要准备好需要关注的问题，事先的准备可以保证需求调研活动的完备性、高效性。在调研问题单中尤其不要遗忘如下的问题：
异常是如何处理的？
峰值是如何处理的？
非功能性的需求有哪些？
未来可能的变化有哪些？
最重要的需求是什么？
对照问题单进行调研进行及时的记录后，调研记录可以请客户确认是否完备正确。

4 在项目初期教育客户如何实施一个软件项目
客户教育是一个大问题，尤其是对一个没有IT经验的客户，如果客户缺乏正确的实施一个IT项目的观点，那么他就不知道如何去提需求，如何控制需求的范围，如何管理一个IT项目。客户的需求是一个项目的输入，如果需求不明确、需求有遗漏、需求总是变化、需求不切实际、需求没有划分优先级，则对整个项目的成败影响重大。因此需要在项目的初期对客户实施教育，告诉客户项目成败的关键因子是什么，在整个项目进展过程中客户需要注意什么。

5 引导用户划分需求的优先级
用户往往不关注需求的优先级，认为所有的需求都重要，需求工程师需要引导用户划分需求的优先级，而不是单刀直入的让用户划分需求的优先级。可以通过如下的启发式问题引导客户划分需求的优先级：
在谈到的上述的需求中，最重要的3项需求是什么？
这个需求比另外一个需求更重要吗？
对于这个需求是否可以考虑采用其他的解决方案，而不通过系统来实现？或简单实现？
如果推迟或不实现这个需求，是否对项目的目标有影响？
如果推迟或不实现这个需求，会对哪些业务，哪些人员有影响？

6 采用用户故事+验收准则描述用户需求
用户故事是敏捷开发方法中描述用户需求的方法，该方法采用三段论的方式描述需求：
角色 功能 目的
如：
作为一个家庭主妇，我需要一个30平米的餐厅，以便于我招待10个朋友进餐。
作为一个系统管理员，我希望系统能够自动备份重要的数据，以便于在发生灾难时可以自动恢复。
通过这个描述方式可以帮助我们确定每个需求的重要性，同时也提供了一个伸缩的弹性，即这个需求的细节特性可能有比较大的协商空间，可以方便我们进行需求、质量、进度、投入的平衡。
仅仅描述了用户故事还不足以让开发人员准确了解需求，还需要描述每个故事的验收标准，通过验收标准来细化需求，在开发与用户之间达成对需求的一致理解。比如：
餐厅要灯光明亮；
餐厅要靠近厨房；
餐厅要5米*6米；
等等。
不仅仅是在敏捷方法中需要描述每个需求的验收准则，在传统的需求描述中也需要明确描述需求的验收标准，但是很多需求工程师恰恰忽略了这一点，很多项目的验收准则描述为参考需求规格说明书进行验收。客户在验收时检查的特性实际上比需求规格说明书中描述的特性要少的多，验收标准代表了客户的最低要求，通过编写验收标准可以发现需求中不明确的地方，凡是不能写出验收标准的需求，通常都是模糊的需求，通过编写验收标准可以起到对需求补充完善的作用，验证需求的作用。

7 需求描述中至少包括：业务流程图、用例、界面原型、非功能性需求、需求优先级
业务流程图描述客户的业务处理的流程，对于理解需求提供了一个很好的背景信息，可以从业务流程图中提取出功能需求与非功能性需求。
用例描述了人机交互的流程，划分了人与系统的职责，清晰刻画了正常与异常的事件流，无论是与客户还是与技术人员都很容易沟通，是描述功能需求的一种有效方式。
界面原型将软件的功能直观地展示出来，一图胜千言，便于引导客户提出更细致、更准确的需求，也便于与技术人员的沟通。在需求获取与分析时应该尽早构造出界面原型。并非需要针对所有的需求都要构造原型，核心的、难以理解的需求需要构造原型。
非功能性需求是用户容易忽略的需求，需求分析人员需要引导客户提出非功能性需求，如果客户不能提出来，需求分析人员需要根据历史的经验定义出非功能性需求并和客户确认，非功能性需求一定要描述出来，不能想当然的认为应该如何如何而没有文档化。非功能性需求能量化则量化，不能量化则采用原型描述。
需求的优先级一般最多划分为3级，优先级最高的最先实现。需求的优先级为采用迭代方法提供了一个基础，也为平衡进度、质量、需求、投入提供了决策依据。
在描述系统需求时不仅仅限于上述的5个方面，还有项目的目标、涉及的用户角色、系统的运行环境、处理的数据等等，但是上面的5个方面往往是最容易出问题的地方。

8 测试人员参与需求评审，确保需求的可测试性
需求的描述要详细到可测试的程度，所谓可测试即测试人员阅读了需求以后可以编写出测试用例，能够识别出输入、操作流程、处理逻辑及预期的输出。测试人员参与需求的评审关注的就是需求的可测试性，如果一个需求不可测试，则说明该需求描述的不够明确。

9 采用功能点方法度量软件规模，确保需求描述的明确性
功能点方法不仅仅是一种规模度量的方法，还是一种需求验证的方法，如果存在两个人功能点分析师对同一需求计算出的功能点不一致，往往是由于需求的描述不够明确而导致的。在需求阶段，通过度量软件的规模可以促进对需求的沟通、理解从而发现需求中模糊、有争议的地方。

10 通过给客户讲解需求及演示界面原型的方式让客户确认需求
需求每经过一个传递，就会发生一次误传，要么信息有遗漏，要么信息有错误，通过需求的确认可以及时发现这些错误，及时纠正这些错误。开发人员给客户讲解对需求的理解、给客户演示界面原型以及在开发过程中阶段性的演示半成品都是需求确认的方式。人们只有在看到实际的软件时才能提出更多的需求，这是客观的现实，因此应该多采用原型法来确认需求，这也是敏捷方法中频繁交付这条实践的来源。
对客户的需求可以确认多次，比如首先是初步的需求访谈记录确认，然后是界面原型的确认，再进行高保真的界面原型确认，在项目开发过程中，可以不断的对半成品的软件进行确认，直至最后的验收确认。

11 无论大小需求的变更都应纳入变更控制的流程
需求总是渐变的，对于大变更、小变更都纳入需求变更的流程，很多项目往往忽略了对小变更的控制，积少成多，最终导致需求、设计、代码的不一致。需求的变更可以分级控制，明确划分不同级别的需求变更，级别不同审批的流程与权限可以不同。

12 针对非功能性需求执行QFD（质量功能部署）
针对非功能性需求执行QFD，即建立非功能性需求与设计方案之间的映射关系，非功能性需求与测试用例之间的映射关系。在实际中项目组往往只会关注功能性需求的实现与测试，而忽略了非功能性需求的实现与测试，通过该实践可以规避对非功能性需求的实现风险。