一.   需求概述

1.    需求的定义

软件产业存在的一个问题就是缺乏统一定义的名词术语来描述我们的工作。客户所定义的“需求”对于开发者似乎是一个较高层次的产品概念。而开发人员定义的“需求”对于用户来说又像是详细设计了。实际上，软件需求包含着多个层次，不同层次的需求从 不同角度和深度反映者细节问题。

IEEE对需求的定义（IEEE软件工程标准词汇表）

（1）     用户解决问题或达到目标所需的条件或能力。

（2）     系统或系统部件要满足合同、标准、规范或其他正式规定文档所需具有的条件和能力。

（3）     一种反映上面（1）或（2）所描述的条件或能力的文档说明。

IEEE公布的定义包括从用户角度（系统的外部行为）和开发者角度（一些内部特性）来阐述需求的概念。关键的一点是一定要编写需求文档。如果只有一堆邮件或者纸条，会谈过几次或一些零星的对话都不能算是明白了客户的需求。

下面是人们对需求定义的另外的一些看法：

●     需求是用户所需要的并能触发一个程序或者系统开发工作的说明，并且从系统外部能发现系统所具有的满足用户的特点、功能及属性等。

●     需求是指明必须实现什么规格的说明。它描述了系统的行为、特性或属性，是在开发过程中对系统的约束。

综上，并没有一个清晰的、毫无二义性的“需求”术语存在，真正的“需求”仅存在与人们的脑海中。任何文档形式的需求仅是一个模型，一种叙述。我们需要确保所有项目承担者在描述需求的名词的理解上务必一致。

2.    需求的特性

需求具有层次性

需求包含三个不同的层次----业务需求、用户需求、功能需求。

业务需求（business requirement）反映了组织机构或客户对系统、产品高层次的目标要求，它们在项目视图与规范文档中予以说明。用户需求（user requirement）文档描述了用户使用产品必须要完成的任务,这在使用用例（user case）文档或文档情景（scenario）说明中予以说明。功能需求（function requirement）定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求。

软件需求各组成部分之间的关系如图2-1所示。

需求具有难于描述性

需求具有易变性

3.    需求的细化

如上一节所述，层次性是需求的固有特性。除了上述的三个层次之外，对于大型复杂的系统而言，它一般是由若干个子系统构成的，子系统可能再划分为更小的子系统，因此需求也相应的被细化成不同级别子系统的功能需求。

图2-2显示了一个GSM系统需求级别定义的例子。

4.    需求的属性

除了文本，每个功能需求应该有一些与之相关的附加信息或称之为属性。这些属性在它的预期功能之外为每个需求建立了一个上下文和背景资料。

以下属性在需求文档中经常需要考虑：

●     创建时间

●     版本号

●     创建人

●     负责认可该需求的人员

●     状态

●     原因或根据（与之相关的附加信息）

●     涉及的子系统

●     涉及的产品版本号

●     使用验证方法或接受的测试标准

●     优先级

●     级别

●     稳定性

 在整个开发过程中，跟踪每个需求的状态是需求管理的另一个重要的方面。需要注意的是，只有当指定的状态转换条件被严格满足时，才能由专门的负责人去改变需求的状态。

5.    如何编写好的需求说明

高质量需求描述的特性

（1）     完整性

（2）     正确性

（3）     可行性

（4）     必要性

（5）     划分优先级

（6）     无二义性

（7）     可证实

二.   需求管理

需求管理是需求工程生命周期中重要的一环，它负责“建立并维护在软件工程中同客户达成的合同”，力图实现最终铲平同需求性的最佳结合。这种合同都包含在编写的需求说明书与模型中。通常需求管理活动包括：

●     定义需求基线（baseline，需求文档的主体）。

●     评审提出的需求变更，评估每项变更的可能影响从而决定是否实施它。

●     以一种可控制的方式将需求融入到项目中。

●     使当前的项目计划与需求一致。

●     估计变更需求所产生的影响并在此基础上协商新的承诺。

●     让每项需求都能与其对应的设计、源代码和测试用例联系起来以实现跟踪。

●     在整个项目过程中跟踪需求的状态及变更情况。

三.   基于DOORS需求工具的开发方案

1.    流程概述

2.    功能概述

需求管理模块包含需求收集，需求分析，需求处理，需求跟踪，版本管理，历史记录，需求文档生成模块，从需求的产生到需求在实际研发中的应用提供了一系列可追踪的功能。需求从一个大的需求面在需求拆分过程中将其分成一个个需求点，并在分析论证过程中讨论这一个个需求点的必要性，可行性等，从而将需求点转化成了一个个开发测试人员理解的功能性需求。经过规划组或CCB的规划，再将功能性需求转化成一个个的任务，从而在实际研发中得到落实。

3.    页面概述

需求申请

每个人都可以提出需求，指定需求产线。这里收集的需求不一定是有效需求。

需求指派

产线负责人对收集的需求进行审核，判断是否为有效需求，如果是有效需求则指定相应的负责人及参与人。如果不是则需求判定为无效或者挂起状态。这里产线负责人可以拆分需求，并可以对拆分后的需求进行指派。

论证分析

需求的参与人进行需求的论证讨论，需求的负责人可以增加讨论成员。将需求从需求面变成需求点，并讨论需求的必要性，可行性等，可适当的增加测试用例。

论证分析意见

需求负责人对论证结果进行总结，提出最终的结论。需求负责人可以选择申请规划或者申请变更，如果选择申请规划，则需求验证之后将由产品规划组进行需求处理。如果选择申请变更，则需求验证后将由CCB(变更控制委员会)进行处理。首次填写意见认为是0版，如果需求验证失败再次论证分析后，则版本递增1 。

确定分析意见

需求申请人对需求负责人提出的分析已经进行确认。

规划审批

规划组根据需求论证分析意见对产品进行规划。与之相关的项目计划和任务计划需要增加链接。

CCB审批

CCB根据需求论证分析意见对产品进行变更规划。与之相关的项目计划和任务计划需要增加链接。

• 上一篇：需求分发简介
• 下一篇：DFX和DFM技术原理及与产品设计相结合的应用案例研究