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

用户需求说明书与需求规格说明书的区别 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。 需求层次：组织级需求 - 业务需求 - 用户需求 - 功能需求（有