1）成立甲乙双方参与的需求控制组

项目的成功不单是乙方的成功，更是甲方的成功，甲乙双方紧密配合、互相理解、互相合作才能成功。

为避免一方具有绝对控制权的现象，成立甲乙双方参与的需求控制组是避免需求蔓延的有效手段。

该组织具有对需求的决策权，对每项需求的增删改查都是平衡了进度、质量、投入后才确定。

该组织不是一个流于形式的组织，应切实地参与需求的获取、描述、分析、确认、变更等活动。

2）识别合适的需求提供者，尤其不要遗漏最终用户 

在获取需求时首先识别谁是最可能有需求，识别出合适的需求提供者

需求的提供者包括了客户、最终用户、间接用户。客户是掏钱买软件的人；最终用户是使用软件的人；间接用户对软件有影响力，但可能不使用软件，也不掏钱买软件。三种角色可能有重合，不同的用户对需求的作用不同，必要忽略任何一种类型的需求提供者

在很多项目中往往忽略最终用户的需求，而导致操作层面的需求捕获不全，系统上线后返工很大

3）在项目初期引导客户如何实施一个软件项目

客户引导是一个大问题，尤其是一个没有IT经验的客户。如果客户缺乏正确的实施IT项目的观点，那么他就不知道如何去提出需求，如何控制需求范围，如何管理IT项目。

客户的需求是项目的输入，如果需求不明确，需求有遗漏，需求总是不切实际，需求没有划分优先级，则对整个项目的成本影响重大。因此需要在项目初期对客户实施引导，告诉客户项目成败的关键因素是什么，在项目的进展过程中客户需要注意什么

4）引导用户划分需求优先级

用户往往不关注需求的优先级，认为所有的需求都是重要的。需求工程师需要引导用户划分需求的优先级，而不是单刀直入地让用户划分优先等级。可以通过以下的启发式问题引导客户划分需求优先级。

在谈到的需求中，最重要的3项需求是什么？

这个需求比另外一个需求更重要么？

这个需求是否可以考虑采用其他的解决方案，而不是通过系统来实现？或是简单实现？

如果推迟或是不实现这个需求，是否对项目的目标有影响？

如果推迟或是不实现这个需求，会对哪些业务、哪些人员有怎样的影响？

5）采用用户故事+验收准则描述用户需求

用户故事是敏捷开发方法中描述用户需求的方法，该方法采用三段论的方式描述需求：

作为一个家庭主妇，我需要一个30平米的餐厅，以便招待10个朋友进餐

作为一个系统管理员，我希望系统能够自动备份重要的数据，以便在发生灾难时可以自动恢复。

通过这个描述，可以帮助我们确定每个需求的重要性，同时提供了一个伸缩的弹性，即这个需求的细节特征可能有比较大的协调空间，可以方便我们进行需求、质量、进度、投入的平衡。

仅仅描述了用户故事还不足以让开发人员准确了解需求，还需要描述每个故事的验收标准。通过验收标准来细化需求，在开发者与用户之间达成对需求的一致理解。比如：

餐厅要灯光明亮

餐厅要靠近厨房

餐厅面积要5米X6米；

。。。。。。

非敏捷的传统开发项目，也需要明确描述需求的验收标准。验收标准代表了客户的最低要求，通过编写验收标准可以发现需求中不明确的地方，凡是不能写出验收标准的需求通常是模糊的需求，通过编写验收标准可以起到对需求的补充完善作用。

6）需求描述中至少包括：业务流程图、用例、界面原型、非功能性需求与需求优先级。

业务流程图描述客户的业务处理流程，对于理解需求者提供了一个很好的背景信息，可以从业务流程图中提取出功能性需求与非功能性需求。

用例描述了人机交互的流程，划分了人与系统的职责，清晰刻画了正常与异常的事件流，无论是与客户还是与技术人员都很容易沟通，是描述功能需求的一种有效方式。

界面原型将软件的功能直观地展示出来。一图胜千言，便于引导客户提出更细致、更准确的需求，也便于与技术人员沟通。在需求获取与分析时，应该尽早构造出界面原型。并非需要针对所有的需求构造原型，只是核心的，难以理解的需求需要构造原型。

非功能性需求是用户容易忽略的需求，需求分析人员需要引导客户提出客户提出非功能需求，如果客户不能提出，需求分析人员要根据历史的经验定义出非功能性需求并和客户确认。非功能性需求一定要描述出来，不能想当然地认为应该如何如何，而没有文档化。非功能性需求能量化则量化，不能量化可采用原型描述。

需求的优先级一般最多划分为3级，优先级最高的最先实现。需求的优先级为采用迭代方法提供了一个基础，也为平衡进度、质量、需求、投入提供了决策。

在描述需求时，不仅仅局限这5个方面，还有项目的目标，涉及的用户角色、系统的运行环境、处理数据等等，但是上面的5个方面往往是最容易出问题的地方。

7）测试人员参与需求评审，确保需求的可测试性

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

8）采用功能点方法度量软件规模，确保需求描述的明确性

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

9）通过给客户讲解需求及演示界面原型的方式让客户确认需求

需求每经过一次传递，就会发生一次误传，要么信息有遗漏，要么信息有错误。通过需求的确认，可以及时发现这些错误。开发人员给客户讲解需求的理解，给客户演示界面原型，以及在开发过程中阶段性演示半成品，都是需求确认方式。人们只有看到实际的软件才能提出更多的需求，这是客观现实，因此应该多用原型法来确认需求，这也是敏捷方法中频繁交付这条实践的来源。

 对客户的需求可以确认多次。比如，首先是初步的需求访谈记录确认，然后是界面原型的确认，再进行高保真的界面原型确认。在项目开发过程中，可以不断地对软件半成品进行确认，指导最后的验收确认。

10）无论大小需求的变更都应纳入变更控制的流程

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

11）针对非功能性需求执行QFD（质量功能部署）

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