用户需求说明书与需求规格说明书的区别

用户需求说明书与需求规格说明书的区别
1、用户需求说明书是用户的需求（期望），需要和用户确认的，重点是站在
客户的角度讲产品功能。

需求规格说明书是系统设计需求，主要是对内的，是从开发、测试的角度去讲产品功能。

2、优点：用户的语言与设计人员的语言是不同的，所以需要有面向不同人员
的文档。

缺点：层次越多，信息损失的越多，误解的概率就越大。

权衡的结果：基本上是依据项目的规模而定。

3、如果要省掉一个的话，更倾向于写用户需求，因为搞系统的时候要始终明
白用户在想什么，要解决什么问题。

需求规格相对不是很重要，具体实现用户需求的时候，你可以有各种方案，这个是用户不关心的。

要是用户需求就已经理解错了，特别是理解不全面，软件规格说明书写得好让用户签字就没有任何意义了。

4、最新的做法
➢使用UML语言，开发需求用例说明书，用例、场景描述和事件――响应表，既可面向客户，又可面向开发设计；
➢使用敏捷开发方法，通过用户故事描述用户需求，即客户想要实现一个什么功能，以满足某个方面的需求。

【相关知识】
●“需求管理”的文档大体上包含需求管理计划、需求检查表、需求跟踪表
（包含矩阵图）、需求变更状态跟踪表，以及与其配套产出的指南型文件。

●“需求开发”的文档大体上包含需求规格说明书，需求规格说明书检查
表，需求开发指南等。

●需求分析报告：一般是对某个市场或者是客户群来讲的，类似于调研报
告，重点是体现出产品要满足哪些功能，哪些是重点、热点。

●需求说明书：是根据与现场实际客户进行沟通，把客户的需求进行整理，
CMMI中有标准的模板，重点是站在客户的角度讲产品功能。

●需求规格说明书：是从业务规则讲起的，细一点偏向于软件的需求设计到
概要设计。

是从开发、测试的角度去讲产品功能，里面要包含原型界面、业务接口、活动图等。

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

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

业务需求描述了组织为什么要开发一个系统，即组织希望达到的目标。

使用前景和范围（vision and scope）文档来记录业务需求，这份文档有时也被称作项目轮廓图或市场需求（project charter 或market requirement）文档。

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

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

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

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

功能需求有时也被称作行为需求（behavīoral requirement），因为习惯上总是用“应该”对其进行描述：“系统应该发送电子邮件来通知用户已接受其预定”。

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

注意：用户需求不总是被转变成功能需求。

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

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

客户希望得到的产品特性和用户的任务相关的需求不完全是一回事。

一项特性可以包括多个用例，每个用例又要求实现多项功能需求，以便用户能够执行某项任务。

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

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

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

◆业务规则包括企业方针、政府条例、工业标准、会计准则和计算方法等。

业
务规划本身并非软件需求，因为它们不属于任何特定软件系统的范围。

然而，业务规则常常会限制谁能够执行某些特定用例，或者规定系统为符合相关规则必须实现某些特定功能。

有时，功能中特定的质量属性（通过功能实现）也源于业务规则。

所以，对某些功能需求进行追溯时，会发现其来源正是一条特定的业务规则。

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

SRS完整地描述了软件系统
的预期特性。

SRS我们一般把它当作文档，其实，SRS还可以是包含需求信息的数据库或电子表格；或者是存储在商业需求管理工具中的信息；而对于小型项目，甚至可能是一叠索引卡片。

开发、测试、质量保证、项目管理和其他相关的项目功能都要用到SRS。

◆需求层次：组织级需求->业务需求->用户需求->功能需求（有时也叫行为需
求）。

➢组织级需求：一般代表着组织的愿景和目标。

对于大的公司，一般是通过资深的咨询顾问和咨询公司得出的，呈现的方式是咨询报告。

比如在ITSM或者企业信息化这方面。

典型的组织级的需求是：降低成本、减少库存成本、提升IT服务部门在企业中的价值、通过ISO20000、提高IT服务的效率、提高员工的满意度等。

➢业务需求：是要完组织的使命，达成组织的愿景的各个业务流程和业务单元具有的需求。

业务需求服从于组织需求。

➢用户需求：用户级的需求，是在业务级的需求下，各个岗位协作完成业务而具有的需求。

我们在软件需求规格说明书中表述的需求其实主要是这一部分需求。

➢功能需求：同样，它代表着产品或者软件需求具备的能力。

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

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

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

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

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

如果答案是肯定的，则该需求属于需求规格说明，反之则不属于。

但答案也许是“不在，但应该在”，这时必须由业务需求的负责人或投资管理人来决定：是否扩大项目范围以容纳新的需求。

这是一个可能影响项目进度和预算的商业决策。

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

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

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

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

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

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

约束，在产品的架构设计中，是需要被首先考虑的问题。

如果说产品的功能代表了产品的能力，那么产品的质量属性代表了产品的品质，产品的约束代表了产品必须去满足的或者适应的条件！“用户体验”是产品的灵魂，对于个人级的软件这么说或许很恰当，当对于企业级甚至是行业级的产品，其灵魂有两个：一个是产品带给用户的价值，另一个是产品的品质，简单的说，就是价值和品质。

但其成为一个产品的前提应该是满足约束，否则就不应该设计、开发、进入市场而成为一个垃圾。

➢用户需求、功能需求区别。

简单的就是：用户需求。

用户需要在应用系统中实现什么东西，为实现这个目标，需要用户提供的全部的详细的业务说明，业务流程，表格样式等。

功能需求。

将用户需求归类分解为计算机可以实现的子系统和功能模块，用设计语言描述和解释用户的需求，以达到可以指导程序设计的目的。