需求分析类文档模板

许多有经验的开发团队在开始需求调查的时候，总会将“软件客户需求权利书”和“软件客户需求义务书”提交给客户，让客户明确其权利与义务，将会对需求调研、分析的工作带来意想不到的效果，你可以一试。

软件客户需求权利书

1.要求分析人员使用符合客户语言习惯的表达；

2.要求分析人员了解客户系统的业务及目标；

3.要求分析人员组织需求获取期间所介绍的信息，并编写软件需求规格说明。

4.要求开发人员对需求过程中所产生的工作结果进行解释说明；

5.要求开发人员在整个交流过程中保持和维护一种合作的职业态度；

6.要求开发人员对产品的实现及需求都要提供建议，拿出主意。

7.描述产品使其具有易用、好用的特性；

8.可以调整需求，允许重用已有的软件组件；

9.当需要对需求进行变更时，对成本、影响、得失有个真实可信的评估；

10.获得满足客户功能和质量要求的系统，并且这些要求是开发人员同意的。

软件客户需求义务书

1.给分析人员讲解业务及说明业务方面的术语等专业问题；

2.抽出时间清楚地说明需求并不断完善；

3.当说明系统需求时，力求准确详细；

4.需要时要及时对需求做出决策；

5.要尊重开发人员的成本估算和对需求的可行性分析；

6.对单项需求、系统特性或使用实例划分优先级；

7.评审需求文档和原型；

8.一旦知道要对项目需求进行变更，要马上与开发人员联系；

9.在要求需求变更时，应遵造开发组织确定的工作过程来处理；

10.尊重需求工程中开发人员采用的流程（过程）。

软件项目视图和范围

编者说明：

项目所涉及的内容与所解决的问题都是有限的，而且项目应该是十分有目的性的，是为了实现某个可度量的目标而做的。因此，在需求分析的前期应该将“项目的目 标与范围”这一项目的本质文档化，让每一个项目成员对其达成共识。该文档是十分重要，但却又是十分容易被忽视的。该文档模板比较适用于定制开发项目。

1.业务需求

[业务需求说明了提供给客户和产品开发商的新系统的最初利益。不同产品可能会有不同的侧重点。本部分描述了你为什么要从事此项项目的开发，以及它将给开发者和购卖者带来的利益。]

1.1 背景

[在这一部分，总结新产品的理论基础，并提供关于产品开发的历史背景或形势的一般性描述。]

1.2 业务机遇

[描述现存的市场机遇或正在解决的业务问题。描述商品竞争的市场和信息系统将运用的环境。包括对现存产品的一个简要的相对评价和解决方案，并指出所建议的 产品为什么具有吸引力和它们所能带来的竞争优势。认识到目前只能使用该产品才能解决的一些问题，并描述产品是怎样顺应市场趋势和战略目标的。]

1.3 业务目标

[用一个定量和可测量的合理方法总结产品总结产品所带来的重要商业利润。关于给客户带来的价值在后面阐述，这里仅把重点放在给业务的价值上。这些目标与收入预算或节省开支有关，并影响到投资分析和最终产品的交付日期。]

1.4 客户或市场需求

[描述一些典型客户的需求，包括不满足现在市场上的产品或信息系统的需求。提出客户目前所遇到的问题在新产品中将可能（或不可能）出现的阐述，提供客户怎 样使用产品的例子。确定了产品所能运行的软、硬件平台。定义了较高层次的关键接口或性能要求，但避免设计或实现细节。把这些要求写到列表中，可以反过来跟 踪调查特殊用户和功能需求。]

1.5 提供给客户的价值

[确定产品给客户带来的价值，并指明产品怎样满足客户的需要。可以用下列言辞表达产品带给客户的价值：

• 提高生产效率，减少返工；
• 节省开支；
• 业务过程的流水线化；
• 先前人工劳动的自动化；
• 符合相关标准和规则；
• 与目前的应用产品相比较，提高了可用性或减少了失效程度。]

1.6 业务风险

[总结开发（或不开发）该产品有关的主要业务风险，例如市场竞争、时间问题、用户的接受能力、实现的问题或对业务可能带来的消极影响。预测风险的严重性，指明你所能采取的减轻风险的措施。]

2.项目视图的解决方案

[文档中的这一部分为系统建立了一个长远的项目视图，它将指明业务目标。这一项目视图为在软件开发生存期中作出决策提供了相关环境背景。这部分不包括详细的功能需求和项目计划信息。]

2.1 项目视图陈述

[编写一个总结长远目标和有关开发新产品目的的简要项目视图陈述。项目视图陈述将考虑权衡有不同需求客户的看法。它可能有点理想化，但必须以现有的或所期待的客户市场企业框架。组织的战略方向和资源局限性为基础。]

[如："化学制品跟踪系统"可使科学家查询到化学制品仓库或供应商将提供的化学制品容器。系统可随时了解公司每一个化学制品容器所处的位置，容器中所剩余 的药品剂量，任何时候每个容器所处的位置和用法的历史记录。通过充分利用公司内部的可用化学制品，废弃极少量已使用或过期失效的化学制品，使用标准的化学 制品的购买过程等将在化学制品上节省25%开支。"化学制品跟踪系统"还能产生符合政府部门规定所要求的全部报表，包括化学制品的使用、存储和废弃等报 表。]

2.2 主要特征

[包括新产品将提供的主要特性和用户性能的列表。强调的是区别于以往产品和竞争产品的特性。可以从用户需求和功能需求中得到这些特性。]

2.3 假设和依赖环境

[在构思项目和编写项目视图和范围文档时，要记录所作出的任何假设。通常一方所持的假设应与另一方不同。如果你把它们都记录下来，并加以评论，就能对项目 内部隐含的基本假设达成共识。比如，"化学制品跟踪系统"的开发者假设：该系统可以替代现有的仓库存货系统，并能与有关采购部门的应用相连接。把这些都记 录下来以防止将来可能的混淆和冲突。还有，记录项目所依赖的主要环境，比如：所使用的特殊的技术、第三方供应商、开发伙伴及其它业务关系。]

3.范围和局限性

[项目范围定义了所提出的解决方案和概念和适用领域，而局限性则指出产品所不包括的某些性能。如果一般客户所提出的需求超出项目的范围时就应当拒绝它，除非这些需求是很有益的。记录这些需求以及拒绝它们的原因，以待查。]

3.1 首次发行的范围

[总结首次发行的产品所具有的性能。描述了产品的质量特性，这些特性使产品可以为不同的客户群提供预期的成果。应当避免将想到的每一个特性都包括到1.0版本产品中去。开发者应把重点放在能提供最大价值、花花费最合理的开发费用及普及率最高的产品上。]

3.2 随后发行的范围

[如果你想象一个周期性的产品演变过程，就要指明哪一个主要特性的开发将被延期，并期待随后版本发行的日期。]

3.3 局限性和专用性

[明确定义包括和不包括的特性和功能的界线是处理范围设定和客户期望的一个途径。列出风险承担者们期望的而你却不打算把它包括到产品中的特性和功能。]

4.业务环境

[这一部分总结了一些项目的业务问题。]

4.1 客户概貌

[客户概述明确了这一产品的不同类型客户的一些本质特点，以及目标市场部门和在这些部门中的不同客户的特征。对于每一种客户类型，概述要包括：

• 各种客户类型将从产品中获得的主要益处；
• 它们对产品所持的态度；
• 感兴趣的关键产品的特性；
• 哪一类型客户能成功使用；
• 必须适应任何客户的限制。]

4.2 项目的优先级

[一旦明确建立项目的优先级，风险承担者和项目的参与者就能把精力集中在一系列共同的目标上。达到这一目的的一个途径是考虑软件项目的五个方面：性能、质量、计划、成本和人员。在所给的项目中，其每一方面应与下面三个因素之一相适应。

• 一个驱动----一个最高级别的目标；
• 一个约束----项目管理者必须操纵一个对象的限制因素；
• 一个自由度----项目管理能权衡其它方面，进而在约束限制的范围内完成 目标的一个因素。

未必所有的因素都能成为驱动，或所有的因素都能成为约束因素。在项目开始时记录和分析哪一个因素适用于哪一类型，将有助于使每一个人的努力和期望与普遍认可的优先级相一致。]

5.产品成功的因素

[明确产品的成功是如何定义和测量的，并指明对产品的成功有巨大影响的几个因素。不仅要包括组织直接控制的范围内的事务，还要包括我部素。如果可能，可建立测量的标准，用于评价是否达到业务目标，如：市场股票、销售量及收入、客户满意度、交易处理量和准确度。]

项目构想

编者说明：

这个文档模板与“软件项目视图与范围”文档的功能十分接近，只不过该文档更适合于产品型项目。其注重对项目的用户、市场进行分析，紧抓项目相关人员（也叫做风险承担者）的需求的本质。

1.文档简介

[软件需求规格说明书的整个内容还是锁定于整个系统的操作、使用层面之上的功能性需求，只是解决了How的问题，而并未回答Why的问题。这使得系统在开 发过程中，开发团队经常陷入知其然，而不知其所以然的困境，造成了不必要的误解与错误。因此，需要一个侧重于对项目的风险承担者、目标用户需要的文档，不 仅要了解他们需要的功能，还要找到他们提出这些需求的原因。这就是“项目构想”文档所要描述的重要内容。]

[本节的内容主要是提供项目构想文档的目的、范围、定义、参考资料以及对其的摘要性概述。]

1.1 目的

[说明该文档的写作目的。]

1.2 范围

[范围主要用来说明该文档描述的项目内容，以及与其相关的其它东西。]

1.3 定义、首字母缩写词和缩略语

[与其它文档一样，该文档也需要将本文档中所涉及的所有术语、缩略语进行详细的定义。还有一种可简明的做法，就是维护在一个项目词汇表中，这样就可以避免在每个文档中都重复很多内容。]

1.4参考资料

[在这一小节中，应完整地列出该文档引用的所有文档。对于每个引用的文档都应该给出标题、标识号、日期以及来源，为阅读者查找这些文档提供足够详细的信息。]

1.5 概述

[在本小节中，主要是说明项目构想各个部分所包含的主要内容，就像一个文章摘要一样。同时也应该对文档的组织方式进行解释。]

2.定位

2.1 商业机会

[如果该项目是一个产品型项目，那么应该在本小节中描述该产品所针对的商业机会。如果是定制开发项目，那么可以省去本小节。]

2.2 问题说明

[使用表格的形式，将该项目将要解决的问题进行概要性地描述：]

存在的问题	[问题的简要说明]
受影响的人群	[该问题对哪些人群带来了影响]
导致的后果	[该问题带来的不利因素]
希望的解决方案	[列出解决方案所能够解决的问题，以及其相应的优点。]

2.3 产品定位说明

[如果是产品型项目，则该小节将以表格的形式对产品的定位进行明确，如果是定制开发项目，可以省略本小节。]

目标市场	[描述产品目标客户群体]
目标客户需求	[说明客户的需要或者潜在的机会]
产品类别	[说明该产品属于什么领域]
主要优点	[描述让目标客户产生兴趣和购买欲的理由]
主要竞争对手	[列出与该产品有竞争的其它厂商的产品]
主要优势	[针对竞争产品的分析]

[一个具有清晰定位的产品，在开发过程中，团队将更好地理解，更容易开发出满足目标市场的产品，因而该部分内容是十分重要的。]

3.项目相关人员和用户说明

[了解用户、了解所有与该项目相关的人员，是有效地满足他们对系统、产品需求的基础。你应该在本小节中将所有的项目相关人员以及用户收罗在一起，并对他们进行简要的描述，对他们的需求、习惯、角度进行说明。这些内容将有助于开发团队更好的理解用户的需求本质。]

3.1 产品用户分析

[如果是产品型项目，那么你应该本节中对目标客户进行分析。可以在市场调查的基础上，对其市场的规模和增长率进行研究，从而估计其潜在的用户数量。另外， 还应结合目标市场的实际情况，分析你的组织是否在该市场上有拓展的优势，如何获得这些优势。如果是定制开发项目，可以省略这一小节。]

3.2 项目相关人员一览表

[使用下面的表格，对项目相关人员进行分析。]

人员类别	代表	作用
[ 指明项目相关人员的类别 ]	[ 列举该类人员的代表 ]	[ 说明其对产品、项目开发的影响 ]

3.3 用户一览表

[使用下面的表格，对项目、产品的用户进行分析。]

用户类型	说明	代表
[ 指明用户类别 ]	[ 简要说明他们在系统中代表的对象和充当的作用 ]	[ 列举出代表 ]

3.4 用户环境

[了解用户在使用环境下使用系统或产品，是十分有意义的事，也是实现产品更好地满足需求，提供更加方便的使用界面的基础。例如：该任务由多少人来完成？是 否总在变化？一个任务周期需要多长时间？执行每项活动要用多长时间？是否总在变化？是否有特殊的环境约束：移动、户外、乘机旅行等？目前使用的是哪些系统 平台？以后会使用哪些平台？还在使用哪些应用程序？您的应用程序是否需要和这些应用程序集成？他们的计算机硬件系统的环境情况如何？他们都是在什么样的工 作环境中使用系统的？]

3.5 项目相关人员的简要说明

[以下表的形式，将各类项目相关人员的基本情况进行说明，以帮助开发团队更好地了解他们的情况。为每一类人员生成一张表格。]

代表	[列出该类项目相关人员的代表。]
说明	[对该类人员进行简要说明。]
专业技能	[描述本类人员的技能特长、技术背景以及电脑系统操作的熟练程度（可以分成业务用户、专家用户、熟练用户、初级用户等）]
职责	[描述本类人员对系统开发所承担的职责，以及应享有的利益。]
验收标准	[描述验证系统是否满足其职责的标准。]
参与方式	[该类人员是否参与系统开发，如果参与将以什么形式参加。]
项目成果	[说明该类项目相关人员是否参与项目成果的开发，是否有与其相关的项目成果。]
意见/问题	[列出与该类项目成员相关的问题与建议。]

3.6 用户简要说明

[以下表的形式，将与系统相关的各种用户的信息整理出来，以方便开发团队针对性的工作。要注意的是，用户会有不同的类型，有些用户需要的是灵活性、方便快 速操作的高级功能，而有些用户则侧重与用户界面的友好性。这些与该用户的基本情况直接相关，了解用户才能够真正地开发出符合用户习惯和水平的系统。为每类 用户生成一张表。]

代表	[列出该类用户的代表。]
说明	[对该类用户进行简要说明。]
专业技能	[描述该用户的技能特长、技术背景和对计算机系统操作的熟练程度。]
职责	[列出该用户对所开发的系统负有的关键职责，如记录详细信息、撰写报告、协调工作等。]
验收标准	[描述验证系统符合用户需求的标准。]
参与方式	[说明该类用户是否参与开发，如何参与。]
项目成果	[说明是否有依赖于该类用户的项目成果。]
意见/问题	[列出一些该类用户对系统提出的一个意见与建议，并且收集其认为该系统将遇到的问题。]

3.7 关键的项目相关人员/用户需要

[列出项目相关人员提出的针对对于该解决方案的关键问题。对于列出的每个问题，需澄清：为什么会出现这一问题？目前的解决方案是什么？他们需要什么要的解决方案？或者对新的解决方案有什么样的预期？]

[还有一个很关键的内容就是，每个需求的优先级，这将对制定迭代计划时提供有效的基础，而优先级的确定，应该采用分级、累积投票等方法从用户、项目相关人员那里获得。应充分考虑项目客户方的要求。如果是产品型项目，则应该从产品经理、市场调查资料里获得。]

[经过整理后，将内容填入下表：]

需求	优先级	要点	目前解决方案	提议的解决方案

3.8 备选方案和竞争

[如果是产品型项目，应在此小节列举出客户除了购买该产品这外的选择，其中包括购买竞争对手的产品、自行设计解决方案甚至是维持现状。对所有潜在的竞争产品做一个列表，并根据客户的实际情况来确认主要优缺点。]

[而如果是定制开发型项目，则应该了解竞争对手提供的解决方案，比在此进行相应的比较。]

4. 产品概述

[本节主要从产品级、系统级的视角，高度概括产品的功能、与其它应用程序的交互以及所需的系统配置等。]

4.1 产品总体效果

[本小节主要将产品话在用户环境、使用环境的角度来介绍。如果是自成一体，则说明用户将如何使用；如果是与其它的应用系统进行交互的，则在此小节说明如何 与这些系统进行交互？它们之间采用什么样的通讯方式和接口。在这里最适合的方式是使用UML的部署图，让用户对系统最终的运行环境有一个较宏观的了解。]

4.2 主要功能

[本小节不是对系统或产品所有功能的罗列，而是将能够体现系统、产品主要优点和特性功能在此列出。在内容组织方面，应该直接与“客户能够通过产品获得的好 处”相联系，使读者能够将系统的功能与客户的价值直接联系起来，在开发时能够从本质出发，构建出更加符合客户需要的系统。]

4.3 假设与依赖关系

[在此小节中，列出所有会影响该文档中所述特性的各种因素。也就是列举出所有可能让该文档发生变化的假设条件。]

4.4 成本与定价

[该小节主要是对该项目的成本进行核算，对给出相应的定价策略。对于定制开发的项目，其成本主要包括开发的人工成本、公司管理成本、项目额外开支、相关软 硬件工具投资等方面。而对于产品型项目而言，还包括分销成本、用户手册制作、CD制作等方面的成本。这里的成本核算为最终的合同价格以及产品的销售价值将 提供一个基础的依据，因此也是十分重要的。]

4.5 许可与安装

[该小节中主要列出影响开发工作的一些许可和安装相关的问题。例如是否需要加密，如果验证用户合法性，安装界面的要求是什么。这方面对于产品型项目而言显得更加重要，也是对软件知识产权保护的一个重要措施。]

5.产品特性

[在本节中将列出系统或产品的特性，特性是指实现用户价值的系统功能。每一个特性都是一个所需的服务，通常是通过一系列操作实现预期结果。在FDD中，也就是特征。通常一个特征会由一个或多个用例来实现，通常系统的特性应该进行整合打包，以25-99项为合适。]

[本小节的描述应该能够让用户、操作人员、外部系统直接从系统的外边感受到每项特性，这些特性应该包括功能性说明以及一些可用性问题。但是要注意，在这里不要过早地引入设计的内容，这里说明的是What，而不是How。]

[另外，因在所有特性的描述中，确定其优先级。]

6.约束

[记录用户、项目相关人员提供出的一些约束条件，以及与其它系统之间的依赖关系，这是制订解决方案时必须考虑到的问题。]

7.质量要求

[对于整个系统的质量要求，如可靠性、可用性、性能、容错等质量要求，在这此节中详细地定义与描述。]

8.其他产品需求

[一些要求符合的标准、硬件基础要求、软件基础要求、环境要求等。]

8.1 适用的标准

[列出产品必须符合的所有标准。其中可能包括法律和法规（FDA、UCC）标准、通讯标准（TCP/IP、ISDN）、平台一致性标准（Windows、Unix 等）以及质量和安全标准（UL、ISO、CMM）。]

8.2 系统需求

[确定支持该应用程序所必需的任何系统需求。其中可能包括操作系统、网络环境、系统配置、内存大小、硬盘大小、外围设备和配套软件。]

8.3 性能需求

[本节用于详细说明性能需求。性能问题可能包括在各种负载条件下的用户负载因素、带宽或通信容量、吞吐量、精确度以及可靠性或响应时间。]

8.4 环境需求

[对于基于硬件的系统，环境因素可以包括温度、振荡、湿度、辐射等。对于软件应用系统，环境因素可以包括使用条件、用户环境、资源可用性、维护问题、错误处理和恢复。]

9. 文档需求

[列举用户所需的与该系统或产品相关的文档。]

9.1 用户手册

[用户手册的制作说明，例如手册篇幅、详细程序、是否需要图、主要关心的点、要不要建立索引、词汇表，采用教程式还是速查手册式。]

9.2 联机帮助

[联机帮助是一种用户界面友好的服务，它可以为用户提供实时的协助。]

9.3 安装指南、配置文件、自述文件

9.4 标签与包装

10. 功能需求属性

[为了在项目开发过程中，对每个功能需求进行跟踪管理，在此对所有的功能进行一个总体的描述。]

[可以生成一张功能需求属性表，每条记录代表一条功能，每个功能包括以下字段：]

1）状态：标识该功能的最新状态。

• 已提出：已经提出来，但是还没有经过正式的复审而确定的需求；
• 已批准：已经经过正式的渠道复审而确定，准备实施的需求；
• 已加入：已经加入到需求管理基线中的特性。

2）利益：根据客户的态度，确定每个需求的重要程序，也是确定系统开发优先级的基础数据。

• 关键：必不可少的特性，缺少这些特性的系统将无法满足客户的要求，这些特性通常会在最早安排到迭代开发中去；
• 重要：对于系统来说，该特性是十分重要的，很难以通过其它方式来弥补，如果这些特性没有第一时间实现，将会使得客户满意度大大降低。因此是第二优先实现的特性；
• 有用：这些是一些有效，但使用频率较低的功能特性。如果没有在第一时间实现，也不会对客户满意度造成很大的影响；
• 无用：对于系统来说是“镀金”需求，有也可以，没有也行的。

3）工作量：根据特性所需的时间和资源进行估算，给出团队开发的工作时间或个人开发的工作时间。也可以估算出代码行数或功能点数，这也将为迭代开发计划的制定提供良好的基础。

4）风险：列出该特性开发的最大风险，可以对这些风险进行级别细分，对于影响较大的风险还应该制定相应的应对措施。

5）稳定性：对该特性需求是否容易变化进行一个预估，以帮助设计人员在设计解决方案时更加有效地避免变化对体系结构的影响，从而节省时间。

6）基线：确定其是否已经纳入基线；

7）职责分配：列出负责实现该特性的团队；

8）原因：列出提出该特性的原因，也可以将与客户交流的记录等资料放在这里，以帮助开发团队更好的理解客户的本意。

需求规格说明书(ISO标准版)

编者说明：

当需求调查、分析工作告一段落时，你就需要将这些需求进行规格化描述，整理成文，即软件需求规格说明书，也就是SRS。这是在软件项目过程中最有价值的一个文档。ISO所提供的标准虽然已经时间久远，但还是颇具参考价值的。

1．引言

1.1编写的目的

[说明编写这份需求说明书的目的,指出预期的读者。]

1.2背景

a. 待开发的系统的名称;

b. 本项目的任务提出者、开发者、用户；

c. 该系统同其他系统或其他机构的基本的相互来往关系。

1.3定义

[列出本文件中用到的专门术语的定义和外文首字母组词的原词组。]

1.4参考资料

[列出用得着的参考资料。]

2．任务概述

2.1目标

[叙述该系统开发的意图、应用目标、作用范围以及其他应向读者说明的有关该系统开发的背景材料。解释被开发系统与其他有关系统之间的关系。]

2.2用户的特点

[列出本系统的最终用户的特点，充分说明操作人员、维护人员的教育水平和技术专长，以及本系统的预期使用频度。]

2.3假定和约束

[列出进行本系统开发工作的假定和约束。]

3．需求规定

3.1对功能的规定

[用列表的方式，逐项定量和定性地叙述对系统所提出的功能要求，说明输入什么量、经怎么样的处理、得到什么输出，说明系统的容量,包括系统应支持的终端数和应支持的并行操作的用户数等指标。]

3.2 对性能的规定

3.2.1精度

[说明对该系统的输入、输出数据精度的要求，可能包括传输过程中的精度。]

3.2.2时间特性要求

[说明对于该系统的时间特性要求。]

3.2.3灵活性

[说明对该系统的灵活性的要求，即当需求发生某些变化时，该系统对这些变化的适应能力。]

3.3输入输出要求

[解释各输入输出数据类型，并逐项说明其媒体、格式、数值范围、精度等。对系统的数据输出及必须标明的控制输出量进行解释并举例。]

3.4数据管理能力要求（针对软件系统）

[说明需要管理的文卷和记录的个数、表和文卷的大小规模，要按可预见的增长对数据及其分量的存储要求作出估算。]

3.5故障处理要求

[列出可能的软件、硬件故障以及对各项性能而言所产生的后果和对故障处理的要求。]

3.6其他专门要求

[如用户单位对安全保密的要求，对使用方便的要求，对可维护性、可补充性、易读性、可靠性、运行环境可转换性的特殊要求等。]

4．运行环境规定

4.1设备

[列出运行该软件所需要的硬设备。说明其中的新型设备及其专门功能，包括：

a. 处理器型号及内存容量

b. 外存容量、联机或脱机、媒体及其存储格式，设备的型号及数量

c. 输入及输出设备的型号和数量，联机或脱机；

d. 数据通信设备的型号和数量

e. 功能键及其他专用硬件]

4.2支持软件

[列出支持软件，包括要用到的操作系统、编译程序、测试支持软件等。]

4.3接口

[说明该系统同其他系统之间的接口、数据通信协议等。]

4.4控制

[说明控制该系统的运行的方法和控制信号，并说明这些控制信号的来源。]

需求规格说明书(Volere版)

编者说明：

Atlantic System Guild（www.atlsysguild.com）公司所提供的Volere需求过程与软件需求规格说明书模板则充分利用了现代软件工程思想与技术， 是一个十分实用、完善的SRS模板。其所提供的Volere需求记录卡也十分实用，强烈推荐。

注：从Atlantic System Guild公司网站www.atlsysguild.com上获得，并稍做修改

1.产品的目标

1.1 该项目工作的用户问题或背景

[对引发开发任务的工作和情况的描述。同时也应描述用户希望用将要交付的软件来完成的工作。]

[该节内容为该项目提供了合法的理由，你应该考虑用户的问题是否严重，是否应该解决和为什么应该解决。]

1.2 产品的目标

[用一句话或很少的几句话来说明“我们希望该产品做什么？”换言之，即开发该产品的真正原因。

[项目如果没有一个表述清晰、易于理解的目标，就会迷失在产品开发的沙漠中。产品必须带来某种优势。典型的优势是产品会增加组织在市场上的价值，减少运作成本，或提供更好的客户服务。这个优势应该是可度量的，这样才能够让您确定交付的产品是否达到目标。]

2.客户、顾客和其它风险承担者

2.1 客户是为开发付费的人，并将成为所交付产品的拥有者

[这一项必须给出客户的姓名，三个以内是合理的。]

[客户最终将接受该产品，因此必须对交付的产品满意。如果你无法找到一个客户的姓名，那么也许你就不应该构建该产品。]

2.2 顾客是将花钱购买该产品的人

[也给出姓名和相关的信息]

2.3 其它风险承担者

[其他的一些人或组织的名称，他们或者受到产品的影响，或影响产品。]

1） 经理或项目负责人；
2） 业务领域专家；
3） 技术人员；
4） 系统开发者；
5） 市场人员；
6） 产品经理；
7） 测试和质量保证人员；
8） 审查员，诸如安全审查员或审计人员；
9） 律师；
10）易用性专家；
11）你所处行业的专业人员。

3.产品的用户

3.1 产品的用户

[产品的潜在用户或操作员的列表。针对每种类型的用户，提供以下信息：]

1） 用户分类
2） 用户工作的任务；
3） 主要相关的经验；
4） 技术经验；
5） 其他用户特征：包括身体、智力、工作态度、对技术的态度、教育程度、语言技能、年龄、性别等。

[用户是为了完成工作而与产品交互的人，你了解用户，就越可能提交适合用户工作方式的产品。]

3.2 对用户设的优先级

[在每类用户后面附上一个优先级，这区别了用户的重要性和优先地位：]

1） 关键用户：对产品的后续成功至关重要；
2） 次要用户：他们使用产品，但对产品的长期成功并无影响；
3） 不重要的用户：不常用、未授权和没有技能的用户。
[如果认为某些用户对产品或组织更重要，那么应该写明，因为它会影响你设计产品的方式。]

4.需求限制条件

4.1 解决方案限制条件

[此处明确了限制条件，它们规定了解决问题必须采取的方式。您可以认为它们是指令式的解决方案。仔细描述该解决方案，以及测试是否符合的度量标准。如果可能，您应该解释使用该解决方案的原因。]

[换一句话说，就是要求软件解决方案满足哪些限制条件！]

4.2 实现环境

[此处描述产品将被实施的技术环境和物理环境。]

[该环境也将成为设计解决方案时的限制条件之一。]

4.3 伙伴应用

[此处描述那些不属于产品的一部分，但产品却又必须与其协作的应用程序。]

4.4 COTS

[此处描述实现产品需求所必须使用的COTS(商业组件)。]

4.5 预期的工作场地环境

[此处描述用户工作和使用该产品的工作场地。此处应该描述任何可能对产品设计产生影响的工作场地特征。]

4.6 开发者构建该产品需要多少时间

[任何已知的最后期限，或商业机会的时限，应在此处说明。]

4.7 该产品的财务预算是多少

[该产品的预算，以金钱的形式或可得资源的形式说明。]

5.命名标准和定义

[定义项目中使用到的所有术语，包括同义词。这里的内容就是一个字典，包括在需求规格说明书中使用的所有名称的含义。这个字典应该使用你的组织或行业使用 的标准名称。这些名称也应该反映出在工作领域中当前使用的术语。该字典包括项目中用到的所有名称。请仔细地选择名称，以避免传达不同的、不期望的含义。为 每个名字写下简明扼要的定义，这些定义必须经过相应的风险承担者同意。]

6.相关事实

[可能对产品产生影响的外部因素，但不是命令式的需求限制条件。]

7.假定

[列出开发者所做的假设。]

[将所有的假设列在此的目的是让每一个项目成员都意识到这个假设。]

8.产品的范围

8.1 工作的上下文范围

[上下文范围图用来表示将要开发的系统、产品与其它系统之间的关系，以确定系统边界。]

8.2 工作切分

[一个事件清单，确定系统要响应的所有业务事件。清单包括：]
1） 事件名称
2） 输入和输出

8.3 产品边界

[你可以使用用例图(use-case)来确定了用户与产品之间的边界。]

9.功能性需求与数据需求

9.1 功能性需求

[对产品必须执行的动作的描述。]

[每个功能性需求必须有一个验收标准。]

9.2 数据需求

[与产品/系统有密切关系的主题域相关的业务对象、实体、类的说明书。]

[进行问题域建模，生成相应的类图。]

10.观感需求

[一些与产品的用户界面相关的需求描述。]

11.易用性需求

11.1 易于使用

[描述如何构建符合最终用户期望的产品。]

11.2 学习的容易程序

[学习使用该产品应该多容易的说明。通常是有学习时间来衡量。]

12.性能要求

12.1 速度需求

[明确完成特定任务需要的时间，这常常指响应时间。]

12.2 安全性的需求

[对可能造成人身伤害、财产损失和环境破坏所考虑到的风险进行量化描述。]

12.3 精度需求

[对产品产生的结果期望的精度进行量化描述。]

12.4 可靠性和可用性需求

[本节量化产品所需的可靠性。这常常表述为允许的两次失败之间无故障运行时间，或允许的总失败率。]

12.5 容量需求

[本节明确处理的吞吐量和产品存储数据的容量。]

13.操作需求

13.1 预期的物理环境

[本节明确产品将操作的物理环境，以及这种环境引起的任何特殊需求。]

13.2 预期的技术环境

[硬件和其它组成新产品操作环境的设备的规范。]

13.3 伙伴应用程序

[对产品必须与之交互的其它应用程序的描述。]

14.可维护性和可移植性需求

14.1 维护该产品需要多容易

[对产品作特定修改所需时间的量化描述。]

14.2 是否存在一些特殊情况适用于该产品的维护

[关于预期的产品发布周期和发布将采取的形式的规定。]

14.3 可移植性需求

[对产品必须支持的其他平台或环境的描述。]

15.安全性需求

15.1 该产品是保密的吗？

[关于该被授权使用该产品，以及在什么样的情况下授权等方面的描述。]

15.2 文件完整性需求

[关于需要的数据库和其他文件完整性方面的说明。]

15.3 审计需求

[关于需要的审计检查方面的说明。]

16.文件和政策需求

[本节包括针对社会和政策的因素的规格说明，这些因素会影响产品的可接受性。如果你开发的产品是针对外国市场的，可能要特别注意这些需求。]

[问一下是否产品的目标是你所不熟悉的文化环境，是否其它国家的人或其他类型的组织的人会使用该产品。人们是否有与你的文化不同的习惯、节日、迷信、文化上的社会行为规范。]

17.法律需求

17.1 该产品是否受到某些法律的管制

[明确该产品的法律需求的描述。]

17.2 是否有一些必须符合的标准

[明确适用的标准和参考的详细标准的描述。]

18.Opend问题

[对未确定但可能对产品产生重要影响的因素的问题描述。按照需求分析的术语还说，就是TBD（To Be Define）的问题。]

19.COTS解决方案

19.1 是否有一些制造好的产品可以购买

[应该调查现存产品清单，这些产品可以作为潜在的解决方案。]

19.2 该产品是否可使用制造好的组件

[描述可能用于该产品的候选组件，包括采购的和公司自己的产品。列出来源。]

19.3 是否有一些我们可以复制的东西

[其他相似产品的清单。]

20.新问题

20.1 新产品会在当前环境中带来什么问题

[关于新产品将怎样影响当前的实现环境的描述。]

20.2 新的开发是否将影响某些已实施的系统

[关于新产品将怎样与现存系统协同工作的描述。]

20.3 是否我们现有的用户会受到新开发的敌对性影响

[关于现有用户可能产生的敌对性反应的细节。]

20.4 预期的实现环境会存在什么限制新产品的因素

[关于新的自动化技术、新的组织结构方式的任何潜在问题的描述。]

20.5 是否新产品会带来其他问题

[确定我们可能不能处理的情况。]

21.任务

21.1 为提交该产品已经做了哪些事

[用来开发产品的生命周期和方法的细节。画一个高层的过程图展示各项任务和它们之间的接口，这可能是沟通这方面信息的最好办法。]

21.2 开发阶段

[关于每个开发阶段和操作环境中的组件的规格说明。]

22.移交

22.1 我们要让已有数据和过程配合新产品，有什么特殊要求

[一个移交活动的列表，一个实现的时间表。]

22.2 为了新产品，哪些数据必须修改/转换

[数据转换任务清单，同时确定新产品需要转换的数据。]

23. 风险

23.1 当你开发该产品时，要面对什么风险

23.2 你制定了怎样的偶然紧急情况计划

24.费用

[需求的其他费用是你必须投入到产品构建中去的钱或工作量。当需求规格说明书完成时，你可以使用一种估算方法来评估费用，然后以构建所需的资金或时间的形式表述出来。]

25.用户文档

[用户文档的清单，这些文档将作为产品的一部分交付。]

26.后续版本的需求

[这里记录下一些希望今后版本中实现的需求。]

Volere需求记录卡

编者说明：

正如前面所述，Atlantic System Guild还提供了一个配套的Volere需求记录卡，这个记录卡十分实用。建议大家在需求调查、分析过程中，将需求记录在一系列的Volere需求记录 卡上，这个卡让你能够很好的理清需求之间的关系，需求提出的背景，用户对需求的期望，有了这些素材，整理SRS时将变得更加简单。

注：顾客满意度是指完成该项功能顾客满意的程度，而顾客不满意度则是指未实现该功能顾客不满意的程度。

软件需求规格说明书

编者说明：

如果在需求分析时采用了用例（Use case）技术，那么该需求规格说明书将更加符合你的需要。当然，你也可以结合Volere需求规格说明书对该模板进行必要的修改。

1. 文档概述

[该部分主要是对软件需求规格说明书文档进行基本的描述，包括该文档的目的、范围、术语定义、参考资料以及概要。]

[软件需求规格说明书用来系统、完整地记录系统的软件需求。该软件需求说明书的基础是用例分析技术。因此该文档中应包括用例模型、补充规约等内容。]

1.1目的

[在此小节中，主要对软件需求规格说明书的目的做一概要性说明，通常软件需求规格说明书应详细地说明应用程序、子系统的外部行为，还要说明非功能性需求、设计约束，以及其它的相关因素。]

1.2范围

[系统是有范围的，而不是无限扩展的，对于无限扩展的需求是无法进行描述的。因此，在本小节应该对该说明书所涉及的项目范围进行清晰的界定。指定该规格说 明书适用的软件应用程序、特性或者其它子系统分组、其相关的用例模型。当然在此也需要列出会受到该文档影响的其它文档。]

1.3 定义、首字母缩写词和缩略语

[与其它文档一样，该文档也需要将本文档中所涉及的所有术语、缩略语进行详细的定义。还有一种可简明的做法，就是维护在一个项目词汇表中，这样就可以避免在每个文档中都重复很多内容。]

1.4参考资料

[在这一小节中，应完整地列出该文档引用的所有文档。对于每个引用的文档都应该给出标题、标识号、日期以及来源，为阅读者查找这些文档提供足够详细的信息。]

1.5 概述

[在本小节中，主要是说明软件需求规格说明书各个部分所包含的主要内容，就像一个文章摘要一样。同时也应该对文档的组织方式进行解释。]

2. 整体说明

[在本节中，将对整个软件需求进行总体性的描述，以期让读者对整个软件系统的需求有一个框架性的认识。也就是说，该节中主要包括影响产品及其需求的一般因素，而不列举 具体的需求。主要包括产品总体效果、产品功能、用户特征、约束、假设与依赖关系、需求子集等方面的内容。]

2.1用例模型

[在本小节中，将列出该软件需求的用例模型，该模型处于系统级，对系统的特性进行宏观的描述。在此应该列出所有的用例和Actor的名称列表，并且对其做出简要的说明，以及在图中的各种关系。]

2.2 假设与依赖关系

[在软件系统的开发过程中，存在许多假设和依赖关系。在本小节中应列举出所有的重要的技术可行性假设、子系统或构件可用性假设，以及一些可行性的假设。]

3. 具体需求

[如果说第二章节是框架，那么本节就是血肉。在本节中，应该详细列出所有的软件需求，其详细程序应使设计人员能够充分理解并且进行设计的要求，同时也应该给予测试人员足够的信息，以帮助他们来验证系统是否满足了这些需求。整个需求的组织可以采用用例描述进行。]

3.1用例描述

[如果你使用用例建模技术，那么你已经通过用例定义了系统的大部分功能性需求和一些非功能性需求。因此，在软件需求规格说明书只需将这些具体的用例描述， 整理在一起，全部放在该小节之中。当然也可以将用例描述做为附件，在此列出引用，只是这样做并不利于阅读。建议在组织形式上采用以“软件需求”为线索，在 每个需求中，填入对应的1个或几个用例描述。]

3.2补充需求

[由于用例毕竟主要针对功能性需求，因此还会有一些其它的补充需求遗漏，因此在本小节中就是将这些东西补充出来。这些补充需求大部分集中在非功能需求之上，包括以下几个方面的内容：]

1） 易用性：例如指出普通用户和高级用户要高效地执行某个特定操作所需的培训时间；指出典型任务的可评测任务次数；或者指出需要满足的可用性标准（如IBM的CUA标准、Microsoft的GUI标准。

2） 可靠性：包括系统可用性（可用时间百分比、使用小时数、维护访问权、降纸模式操作等）；平均故障间隔时间（MTBF，通常表示为小时数，但也可表示为天 数、月数或年数）；平均修复时间（MTTR，系统在发生故障后可以暂停运行的时间）；精确度（指出系统输出要求具备的精密度、分辨率和精确度）；最高错误 或缺陷率（通常表示为bugs/KLOC，即每千行代码的错误数目或 bugs/function-point，即每个功能点的错误数目）；错误或缺陷率（按照小错误、大错误和严重错误来分类：需求中必须对“严重”错误进行 界定，例如：数据完全丢失或完全不能使用系统的某部分功能）。

3） 性能：包括对事务的响应时间（平均、最长）；吞吐量（例如每秒处理的事务数）；容量（例如系统可以容纳的客户或事务数）；降级模式（当系统以某种形式降级时可接受的运行模式）；资源利用情况：内存、磁盘、通信等。

4） 其它：包括用户界面要求、联机帮助系统要求、法律许可、外购构件，以及操作系统、开发工具、数据库系统等设计约束。

4.支持信息

[支持信息用于使软件需求规格说明书更易于使用。它包括：目录、索引、附录等。]

计算机软件需求说明编制指南

编者说明：

软件需求规格说明是十分重要的文档，因此为开发团队提供一份详细的编制指南是十分有意义和必要的。本文档就是一个编制指南的例子，你可以根据该指南，结合自己的实际情况进行修改。

1．引言

1.1 目的和作用

本指南为软件需求实践提供了一个规范化的方法。本指南不提倡把软件需求说明（Software Requirements Specifications，以下简称SRS）划分成等级，避免把它定义成更小的需求子集。

本指南适用对象：

1）软件客户（Customers），以便精确地描述他们想获得什么样的产品。
2）软件开发者（Suppliers），以便准确地理解客户需要什么样的产品。

对于任一要实现下列目标的单位和（或）个人：

1）要提出开发规范化的SRS提纲；
2）定义自己需要的具体的格式和内容；
3）产生附加的局部使用条款，如SRS质量检查清单或者SRS作者手册等。

SRS将完成下列目标：

1） 在软件产品完成目标方面为客户和开发者之间建立共同协议创立一个基础。对要实现的软件功能做全面描述，帮助客户判断所规定的软件是否符合他们的要求，或者怎样修改这种软件才能适合他们的要求；
2） 提高开发效率。编制SRS的过程将使客户在设计开始之前周密地思考全部需求，从而减少事后重新设计、重新编码和重新测试的返工活动。在SRS中对各种需求 仔细地进行复查，还可以在开发早期发现若干遗漏、错误的理解和不一致性，以便及时加以纠正；
3） 为成本计价和编制计划进度提供基础。SRS提供的对被开发软件产品的描述，是计算机软件产品成本核算的基础，并且可以为各方的要价和付费提供依据。SRS对软件的清晰描述，有助于估计所必须的资源，并用作编制进度的依据；
4） 为确认和验证提供一个基准。任何组织将更有效地编制他们的确认和验证计划。作为开发合同的一部分，SRS还可以提供一个可以度量和遵循的基准（然而，反之 则不成立，即任一有关软件的合同都不能作为SRS。因为这种文件几乎不包括详尽的需求说明，并且通常不完全的）；
5） 便于移植。有了SRS就便于移值软件产品，以适应新的用户或新的机种。客户也易于移植其软件到其他部门，而开发者同样也易于把软件移植到新的客户；
6） 作为不断提高的基础。由于SRS所讨论的是软件产品，而不是开发这个产品的设计。因此SRS是软件产品继续提高的基础。虽然SRS也可能要改变，但是原来的SRS还是软件产品改进的可靠基础。

1.2 范围

本指南适用于编写软件需求规格说明，它描述了一个SRS所必须的内容和质量，并且在第6章中提供了SRS大纲。

2．引用标准

GB 8566 计算机软件开发规范
GB 8567 计算机软件产品开发文件编制指南
GB/T 11457 软件工程术语

3．定义

GB/T 11457所列术语和下列定义适用于本指南。

合同（contract）：是由客户和开发者共同签署的具有法律约束力的文件。其中包括产品的技术、组织、成本和进度计划要求等内容。
客户（customer）：指个人或单位，他们为产品开发提供资金，通常（但有时也不必）还提出各种需求。文件中的客户和开发者也可能是同一个组织的成员。
语言（language）：是具有语法和语义的通信工具，包括一组表达式、惯例和传递信息的有关规则。
分割（partitioning）：把一个整体分成若干部分。
开发者（supplier）：指为客户生产某种软件产品的个人或集团。在本指南中，客户和开发者可能是同一个组织的成员。
用户（user）：指运行系统或者直接与系统发生交互作用的个人或集团。用户和客户通常不是同一些人。

4．编写SRS的背景信息

4.1 SRS的基本要求

SRS是对要完成一定功能、性能的软件产品、程序或一组程序的说明。对SRS的描述有两项基本要求：

1）必须描述一定的功能、性能；
2）必须用确定的方法叙述这些功能、性能。

4.2 SRS的环境

必须认识到SRS在整个软件开发规范（见GB 8566）所规定的有关阶段都起作用。正因为如此，SRS的起草者必须特别注意不要超出这种作用的范围。这意味着要满足下列要求：

1） SRS必须正确地定义所有的软件需求；
2） 除设计上的特殊限制之外，SRS中一般不描述任何设计、验证或项目管理细节。

4.3 SRS的特点

4.3.1 无歧义性

当且仅当它对每一个需求只有一种解释时，SRS者是无歧义的。

2） 要求最终产品的每一个特性用某一术语描述；
3） 若某一术语在某一特殊的行文中使用时具有多种歧义，那么对该术语的每种含义作出解释并指出其适用场合。
需求通常是用自然语言编写的，使用自然语言的SRS起草者必须特别注意消除其需求的歧义性。提倡使用形式化需求说明语言。

4.3.2 完整性

如果一个SRS能满足下列要求，则该SRS就是完整的：

1） 包括全部有意义的要求，无论是关系到功能的、性能的、设计约束的，还是关系到属性或外部接口方面的需求；
2） 对所有可能出现的输入数据的响应予以定义，要对合法和非合法的输入值的响应做出规定；
3） 要符合SRS要求。如果个别章节不适用，则在SRS中要保留章节号；
4） 填写SRS中的全部插图、表、图示标记和参照，并且定义全部术语和度量单位。

4.3.2.1 关于使用“待定”一词的规定

任何一个使用“待定”的SRS都是不完全的。

1） 若万一遇到使用“待定”一词时，作如下处理：

• 对产生“待定”一词的条件进行描述，使得问题能被解决；
• 描述必须干什么事，以删除这个“待定”；

2） 包含有“待定”一词的任何SRS的项目文件应该：

• 标识与此特定文件有关的版本号或叙述其专门的发布号；
• 拒绝任何仍标识为“待定”一词的SRS章节的许诺。

4.3.3 可验证性

当且仅当SRS中描述的每一个需求都是可以验证的，该SRS才是可以验证的；当且仅当在某一性能价格比可取的有限处理过程，人或机器能通过该过程检查软件产品能否满足需求时，才称这个需求是可以验证的。

4.3.4 一致性

当且仅当SRS中各个需求的描述是不矛盾时SRS才是一致的。

4.3.5 可修改性

如果一个SRS的结构和风格在需求有必要改变时是易于实现的、完整性的、一致的，那么这个SRS就是可以修改的。可修改性要求SRS具备以下条件：

1） 具有一个有条不紊的易于使用的内容组织，具有目录表，索引和明确的交叉引用表；

2） 没有冗余。即同一需求不能在SRS中出现多次。

• 冗余本身不是错误，但是容易发生错误。冗余可增加SRS的可读性，但是在一个冗余文件被更新时容易出现问题。例如：假设一个明确的需求在两个地方详细列出，后来发现这个需求需要改变，若只修改一个地方，于是SRS就变得不一致了。
• 不管冗余是否必须，SRS一定要包含一个详细的交叉引用表，以便SRS具备可修改性。

4.3.6 可追踪性

如果每一个需求的源流是清晰的，在进一步产生和改变文件编制时，可以方便地引证每一个需求，则该SRS就是可追踪的。建议采用如下两种类型的追踪：

1） 向后追踪（即向已开发过的前一阶段追踪）。根据先前文件或本