需求概述（需求定义，需求层次以及分类） 信托的含义和构成要素包括什么

目录 需求概述一、需求问题二、需求定义三、需求层次与分类(1)需求层次(2)软件需求分类

需求概述 一、需求问题

在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)软件需求分类 功能需求 定义了开发人员必须实现的软件功能描述系统应该提供的功能或服务，通常涉及用户或外部系统与该系统之间的交互，一般不考虑系统的实现细节。描述软件系统所应具有的外部行为 非功能需求 描述了系统展现给用户的行为和执行的操作等。它包括外部界面的具体细节、性能要求及质量属性。非功能需求是产品必须具备的品质，他们可以让产品有吸引力、易于使用、快速、可靠或者安全。功能性需求是让产品工作的需求，非功能需求是为工作赋予特性的需求。 设计约束 设计约束是指对开发人员在软件产品设计和构造上的限制，产品必须遵从的标准、规范和合约。包括：非技术因素的技术选型、预期的软硬件环境和预期的使用环境三大类型。