需求的层次

在开发早期提高项目需求分析的质量，减少重复劳动，通过控制项目范围的扩大及需求变更来达到按计划完成预订目标，是这里讨论的主要内容。

软件行业存在这样一个问题：用于描述需求工作的术语没有统一的定义。

对同一项需求，不同的人会有不同的描述，称其为用户需求、软件需求、功能需求、系统需求、技术需求、业务需求、产品需求.

客户对需求的定义，在软件开发人员看来可能只是高级别的产品概念；

而开发人员的需求概念对用户来说也许就是详细的用户界面设计。

需求的多样性导致了令人迷惑和沮丧的沟通问题。

但有一点是必须的：需求必须记录成文档。

不要一厢情愿地认为项目的利益相关者（Stake holder）对需求的理解是一致的。应该事先给出定义，才能保证大家谈论的是同一个问题。

软件需求包括3个不同的层次——业务需求、用户需求、功能需求。

除此之外，每个系统还有各种非功能需求。

下图的模型给出了各种需求关系的示意图，和其它所有模型一样，这个模型也不能面面俱到，但它确实有助于理解需求的整体概念。

椭圆代表各类需求信息，矩形则是存储这些信息的载体（文档、图形、数据库）。

业务需求（Business requirement）： 表示组织或客户高层次的目标。

业务需求通常来自项目的投资人、购买产品的客户、实际用户的管理者、市场营销部门 或 产品策划部门。

业务需求描述了为什么要开发一个系统，即组织、客户、公司或其他利益相关者(Stake holder)希望达到的业务目标。

业务需求为项目的其他部分提供了参考框架。所有其他产品特性和需求都必须满足业务需求。但是，业务需求没有提供足够的细节帮助开发人员了解项目。

可以用Vision和Scope（前景和范围）文档来记录业务需求。这份文档有时也被称为 项目轮廓图（Project Charter）或 市场需求（Market Requirement）。Charter :A charter is a formal document describing the rights, aims, or principles of an organization or group of people.

定义项目范围（Scope）是控制范围扩大这个常见问题的第一步。

要控制项目范围的改变，首先应该明确项目的业务目标、全局规划、范围、限制、成功标准以及产品的预计用途。然后参考这一框架对所有新特性和需求变更进行评估。

业务需求位于需求链的最顶层，这种需求定义了软件系统的Vision和Scope，用户需求和软件功能需求都必须符合业务需求设定的Vision和Scope，无助于系统达到业务目标的需求都不应包含在SRS中。如果项目没有一个明确定义的方向，或者不能让每个人都充分理解这个方向，就必然会走向失败。

项目的参与者如果对项目的目标和优先级各执已见，就会在不经意间背道而驰。

Stake holder（利益相关者）如果对产品的业务目标缺乏共同的理解，便无法就需求取得一致。

清晰的Vision和Scope对多地点合作开发的项目尤为重要。

业务需求定义不充分的一个迹象是：某些特性先是被添加，然后被删除，之后又被加入。

关于Vision和Scope的问题都必须在详细定义功能需求之前得到解决。关于项目的Scope和Limitation的声明对讨论提议的特性和目标版本很有帮助。在考虑是否接受提议的需求变更和系统增强时，Vision和Scope也为决策提供了参考。

用户需求（User requirement）：描述的是用户目标，或用户要求系统必需能完成的任务。

这类实际使用产品的用户（通常被称为‘最终用户’）构成了另一类型的客户。用户能够描述出他们需要使用产品完成哪些任务，以及他们希望系统具备哪些质量特征。

提供业务需求的客户往往自称为用户的代言人，但实际上他们并不是系统的直接用户，因此不可能准确提供用户的需求。对于信息系统、签约开发或自己开发的项目，业务需求来自直接投资项目的人，而用户需求来自产品的实际使用者。利益相关者（Stake holder）各方必须对用户需求和业务需求间的一致性进行检查。

用例（use case）、场景描述 和 事件-响应表 都是表达用户需求的有效途径。

也就是说用户需求描述了用户能使用系统来做些什么。

系统需求（System requirement）：用于描述包含多个子系统的产品（即系统）的顶级需求。

系统可以只包含软件子系统，也可以既包含软件又包含硬件子系统。

人也可以是系统的一部分，因为某些系统功能可能要由人来承担。

功能需求（Functional requirement），规定开发人员必需在产品中实现的软件功能，用户利用这些功能来完成任务，满足业务需求。

功能需求有时被称作 行为需求（behavioral requirement），因为习惯上总是用‘应该’对其进行描述。

功能需求描述的是开发人员需要实现什么。

功能需求记录在 软件需求规格说明（SRS）中。

除功能需求外，SRS还包括非功能需求，包括 性能指标 和对 质量属性 的描述。

质量属性（quality attribute）对产品的功能描述作了补充，它从不同方面描述了产品的各种特性。

这些特性包括 可用性、可移植性、完整性、效率 和 健壮性，它对用户和开发人员都很重要。

其他非功能需求包括系统与外部世界之间的外部界面，以及对设计与实现的约束。

约束（constraint）限制了开发人员设计和构建系统时的选择范围。

人们经常谈论到产品特性。

所谓特性（Feature），是指一组逻辑上相关的功能需求，它们为用户提供某项功能，使业务目标得以满足。

对商业软件而言，特性则是一组能被用户识别，并帮助他决定是否购买的需求，也就是产品说明书中用着重号标明的部分。

客户希望得到的产品特性  与 用户的任务相关的需求 不完全是一回事 ：一项特性可以包括多个用例，每个用例又要求实现多项功能需求，以便用户能够执行某项任务。

还有一项称为 可用性（usability）的质量属性，它规定了业务需求中“有效”（efficiently）一词的含义。

管理人员 和 市场营销人员 负责定义软件的业务需求，以提高公司的 运营效率（对信息系统而言）或 产品的市场竞争力（对商业软件而言）。

所有的用户需求都必需符合业务需求。

需求分析员从用户需求 推导出 产品应具备哪些对用户有帮助的功能。

开发人员则根据功能需求和非功能需求设计解决方案，在约束条件的限制范围内实现必需额功能，并达到规定的质量和性能指标。

上面的模型显示的是一个自顶向下的单向需求流，没能反映出业务需求、用户需求 和 功能需求 之间可能存在的循环和迭代关系。

当一项新的特性、用例 或 功能需求 被提出时， 需求分析员 必需思考这样一个问题：“它在范围内吗？”。

如果是，则该需求属于需求规格说明，反之则不属于。

但答案也许是“不在，但应该在”，这时必须由业务需求的负责人或投资管理人来决定：是否扩大项目范围以容纳新的需求——这是一个可能影响项目进度和预算的商业决策。