需求概述（需求定义，需求层次以及分类）

---

需求概述

一、需求问题

在Standish Group的报告中总结了导致项目失败的最重要的8大原因中，有5个与需求相关：

不完整的需求(13.1%)；
缺乏用户的参与(12.4%)；
不切实际的用户期望(9.9%)；
需求变更频繁(8.7%)；
提供了不再需要的需求(7.5%);
资源不足(10.6%),没有执行层支持(9.3%),规划不足(8.1%)

需求是软件项目成败的关键所在。越早发现需求错误，越早改正它，其代价越小。需求错误在不同阶段所需要付出的代价如下图。

二、需求定义

• IEEE软件工程标准词汇表（ 1 9 9 7年）中定义需求为：
  （1）用户解决问题或达到目标所需的条件或权能（ C a p a b i l i t y）。
  （2）系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或权能。
  （3）一种反映上面（1）或（2）所描述的条件或权能的文档说明。
  IEEE公布的定义包括从用户角度（系统的外部行为），以及从开发者角度（一些内部特性）来阐述需求。关键的问题是一定要编写需求文档。
• 另外一种定义中，Jones认为需求是“用户所需要的并能触发一个程序或系统开发工作的说明”
  需求分析专家Davis拓展了这个概念，“从系统外部能发现系统所有的满足于用户的特点、功能及属性等”。这些定义强调的是产品是什么样的，而并非产品是怎样设计、构造的。
• Sommerville的定义则从用户需求进一步移到了系统特征：需求是指明必须实现什么的规格说明。它描述了系统的行为、特性或属性，是在开发过程中对系统的约束。

三、需求层次与分类

软件需求各组成部分之间的关系：

(1)需求层次

• 业务需求（描述为什么要开发系统（why））

业务需求是指反映组织机构或客户对系统、产品高层次的目标要求，通常问题定义本身就是业务需求 。

举个例子，背景描述：XX保险公司希望充分利用日益完善的移动通信技术，在原有的办公系统的基础上进行扩展，使得在外的业务人员能够及时地获得客户、业务相关的动态信息，与此同时，实现企业内部的即时通信。
业务需求/目标 ：通过该系统的实施，将人工保费续缴、投保手续办理两项业务运转周期缩短10％以上，使企业内部沟通效率大幅改善，以帮助企业运转效率得以提高。

• 用户需求（描述系统能够帮用户做什么（what））

用户需求是指描述用户使用产品必须要完成什么任务，怎么完成的需求，通常是在问题定义的基础上进用户访谈、调查，对用户使用的场景进行整理，从而建立从用户角度的需求。

• 系统需求（描述达到用户要求的具体流程（How））

• 系统需求（system requirement）用于描述包含多个子系统的产品（即系统）的顶级需求。系统可以只包含软件系统，也可以既包含软件又包含硬件子系统。人也可以是系统的一部分，因此某些系统功能可能要由人来承担。
• 从系统实现的角度描述的需求。
• 开发人员（设计及分析人员）在业务需求、用户需求的基础上生成的。

(2)软件需求分类

• 功能需求

• 定义了开发人员必须实现的软件功能
• 描述系统应该提供的功能或服务，通常涉及用户或外部系统与该系统之间的交互，一般不考虑系统的实现细节。
• 描述软件系统所应具有的外部行为

• 非功能需求

• 描述了系统展现给用户的行为和执行的操作等。它包括外部界面的具体细节、性能要求及质量属性。
• 非功能需求是产品必须具备的品质，他们可以让产品有吸引力、易于使用、快速、可靠或者安全。
• 功能性需求是让产品工作的需求，非功能需求是为工作赋予特性的需求。

• 设计约束

• 设计约束是指对开发人员在软件产品设计和构造上的限制，产品必须遵从的标准、规范和合约。包括：非技术因素的技术选型、预期的软硬件环境和预期的使用环境三大类型。