2、用户需求

　　用户需求是指描述用户使用产品必须要完成什么任务，怎么完成需求，通常是在问题定义的基础上进行用户访谈、调查，对用户使用的场景进行整理，从而建立从用户角度的需求。用户需求必须能够体现软件系统将给用户带来的业务价值 ，或用户要求系统必须能完成的任务，也是说用户需求描述了用户能使用系统来做些什么（what），这个层次的需求是非常重要的。用例、用户故事、特性等都是表达用户需求的有效途径。

　　户需求层次上的重心转移到如何收集用户的需求上，即确定角色和角色的用例，需求分析是很难的，因为很多需求是隐性的，很难获取，更难保证需求完整，而需求又是易变的。

　　3、功能需求

　　系统分析员描述 开发人员在产品中实现的软件功能，用户利用这些功能来完成任务，满足业务需求。功能需求是需求的主体，它描述的是开发人员如何设计具体的解决方案来实现这些需求（how），其数量往往比用户需求高一个数量级。 这些需求记录在软件需求规格说明（Software Requirments Specification）中。 SRS完整地描述了软件系统的预期特性。SRS我们一般把它当作文档，其实，SRS还可以是包含需求信息的数据库或电子表格；或者是存储在商业需求管理工 具中的信息；而对于小型项目，甚至可能是一叠索引卡片。开发、测试、质量保证、项目管理和其他相关的项目功能都要用到 SRS。

　　产品特性（feature），是指一组逻辑上相关的功能需求，它们为用户提供某项功能，使业务目标得以满足。对商业软件而言，特性则是一组能被客户识别，并 帮助他决定是否购买的需求，也是产品说明书中用着重号标明的部分。客户希望得到的产品特性和用户的任务相关的需求不完全是一回事。一项特性可以包括多个 用例，每个用例又要求实现多项功能需求，以便用户能够执行某项任务。

　　《Software Requirements》举了一个字处理程序的例子来说明需求的这三种不同种类。业务需求可能是：“用户能有效地纠正文档中的拼写错误”，该产品的包装盒封面上可能会标明这是个满足业务需求的拼写检查器。而对应的用户需求可能是“找出文档中的拼写错误并通过一个提供的替换项列表来供选择替换拼错的词”。同时，该拼写检查器还有许多功能需求，如找到并高亮度提示错词的操作；显示提供替换词的对话框以及实现整个文档范围的替换。

　　功能需求除了来自于用户需求，还来自于其它几方面需求：

　　1、系统需求（system requirement）

　　用于描述包含多个子系统的产品(即系统)的需求，它是从系统实现的角度描述的需求，有时还需要考虑相关的硬件、环境方面的需求。
         
　　2、业务规则

　　业务规划本身并非软件需求，因为它们不属于任何特定软件系统的范围。然而，业务规则常常会限制谁能够执行某些特定用例，或者规定系统为符合相关规则必须实现某些特定功能。它包括企业方针、政府条例、工业标准、会计准则和计算方法等。有时，功能中特定的质量属性（通过功能实现）也源于业务规则。所以，对某些功能需求进行追溯时，会发现其来源正是一条特定的业务规则。

　　3、质量属性（quality attribute）

　　产品必须具备的属性或品质。系统的质量属性包括可用性、可修改、性能、安全性、可测试行、易用性和McCall体系等

　　4、约束（constraint）

　　约束也称为限制条件、补充规约，通常是对解决方案的一些约束说明。

　　这三个层次  按照通俗一些的话来说，可以表示为下图：

　　棱锥图

　　在软件开发过程中，为重要的“用户需求”往往和数量巨大的”功能需求“混淆在一起，这会让太多没有直接提供业务价值的需求充斥在需求阶段，这会导致没有突出重点而忽视重要的业务特性，这对业务分析来说是非常有害的。 所以在开发过程中，很有必要加强认识并区分开来，有的开发平台（如普元）对这两类层次的需求区分开来，如下图的构件种类对应关系：