产品经理PRD软件需求规格说明书模板

{产品名称}
软件需求规格说明书
XXXX科技有限公司版权所有（内部资料注意保密）
版本历史
目录
1.产品描述 (3)
1.1.编写目的 (3)
1.2.产品名称 (3)
1.3.文档范围 (3)
1.4.预期的读者和阅读建议 (3)
1.5.参考文档 (3)
1.6.缩略语和术语（可选） (3)
2.产品需求概述 (3)
2.1.用例简介 (3)
2.2.运行环境 (3)
2.3.条件与限制（可选） (4)
3.用例描述 (4)
3.1.用例1 (4)
3.2.用例N (5)
3.3.不支持的用例 (5)
4.数据描述 (5)
5.系统需求（可选） (5)
6.运行需求（可选） (6)
6.1.用户界面 (6)
6.2.硬件接口 (6)
6.3.软件接口 (6)
6.4.通信接口 (6)
7.其它需求（可选） (7)
8.特殊需求（可选） (7)
9.不确定的问题（可选） (7)
10.编写人员及编写日期 (7)
11.附录 (7)
11.1.引用文件 (7)
11.2.参考资料 (7)
1.产品描述
1.1.编写目的
【说明编写本软件需求规格说明书的目的，指出预期的读者。

】
1.2.产品名称
【本项目的名称，包括项目的全名、简称、代号、版本号。

】
1.3.文档范围
【文档范围包括：产品介绍，产品面向的用户群体，产品应当遵守的标准与规范，产品范围，产品中的角色，产品的功能性需求，产品的非功能性需求。

】
1.4.预期的读者和阅读建议
【各种管理人员及开发人员：项目经理、系统工程师、软件开发人员、硬件开发人员、测试人员、型态管理人员、品质保证人员和软件使用客户】
1.5.参考文档
【说明编写本软件需求规格说明书涉及参考文档。

】
1.6.缩略语和术语（可选）
【对重要的或是具有特殊意义的名词（包括词头和缩写）进行定义，以便读者可以正确地解释软件需求说明。

】
2.产品需求概述
2.1.用例简介
【对产品的基本用例做一个简介，包括：
1.本产品的开发意图、应用目标及作用范围。

2．概略介绍了产品所具有的主要用例。

用UML用例包图和用例图描述功能结构。

确定系统中所包含的参与者、用例和两者之间的对应关系。

简单的系统中只需要有一个用例图就可以把所有的关系都描述清楚。

复杂的系统中可以有多个用例图，例如每个用例包都可以有一个独立的用例图来描述该用例包中所有的参与者和用例的关系。

3．说明本产品与其他相关产品的关系，是独立产品还是一个较大产品的组成部分。

可以用表示外部接口和数据流的系统高层次图，或者方框图说明。

】
2.2.运行环境
1.硬件环境：
【详细列出本软件运行时所必须的最低硬件配置、推荐硬件配置(如主机、显示器、外部设备等)以及其它特殊设备。

】
2.软件环境：
【如操作系统、网络软件、数据库系统以及其它特殊软件要求。

】
2.3.条件与限制（可选）
【说明本软件在实现时所必须满足的条件和所受的限制，并给出相应的原因。

必须满足的条件包括输入数据的范围以及格式。

所受的限制包括软件环境、硬件环境等方面的内容。

例如：必须使用或者避免的特定技术、工具、编程语言和数据库；企业策略、政府法规或工业标准；硬件限制，例如定时需求或存储器限制；经费限制、开发期限；项目对外部因素存在的依赖。

例如其它项目开发的组件。

等等】
3.用例描述
【功能需求描述系统特性，即产品所提供的主要服务。

可以通过使用实例、运行模式、用户类、对象类或功能等级等不同方法来描述，还可以把它们组合起来使用。

】
3.1.用例1
【描述每一个用例的详细信息，这些信息包含在用例规约中，用例模型是由用例图和每一个用例的详细描述――用例规约所组成的。

每一个用例的用例规约都应该包含以下内容：
●简要说明 (Brief Description)
简要介绍该用例的作用和目的。

●事件流 (Flow of Event)
包括基本流和备选流，事件流应该表示出所有的场景。

A．基本流
基本流描述的是该用例最正常的一种场景，在基本流中系统执行一系列活动步骤来响应参与者提出的服务请求。

采用以下格式来描述基本流：
1) 每一个步骤都需要用数字编号以清楚地标明步骤的先后顺序。

2) 用一句简短的标题来概括每一步骤的主要内容（可以通过浏览标题来快速地了解
用例的主要步骤，只需标题描述不需更细内容描述）。

3) 当整个系统用例确定后，再针对每一步骤详细描述参与者和系统之间所发生的交
互。

建议采用双向描述法来保证描述的完整性，即每一步骤都需要从正反两个方面来描述:(1)参与者向系统提交了什么信息；(2)对此系统有什么样的响应。

B．备选流
备选流负责描述用例执行过程中异常的或偶尔发生的一些情况，备选流和基本流的组合应该能够覆盖该用例所有可能发生的场景。

在描述备选流时，应该包括以下几个要素：
1) 起点：该备选流从事件流的哪一步开始；
2) 条件：在什么条件下会触发该备选流；
3) 动作：系统在该备选流下会采取哪些动作；
4) 恢复：该备选流结束之后，该用例应如何继续执行。

备选流的描述格式可以与基本流的格式一致，也需要编号并以标题概述其内容，编号前可以加以字母前缀A(Alternative)以示与基本流步骤相区别。

●用例场景 (Use-Case Scenario)
包括成功场景和失败场景，场景主要是由基本流和备选流组合而成的。

开发人员必须
实现所有的场景、测试人员可以根据用例场景来设计测试用例
●特殊需求 (Special Requirement)
描述与该用例相关的非功能性需求（包括性能、可靠性、可用性和可扩展性等）和设计约束（所使用的操作系统、开发工具等）。

●前置条件 (Pre-Condition)
执行用例之前系统必须所处的状态。

●后置条件 (Post-Condition)
用例执行完毕后系统可能处于的一组状态。

用例规约基本上是用文本方式来表述的，为了更加清晰地描述事件流，也可以选择使用状态图、活动图或序列图来辅助说明
】。

3.2.用例N。

3.3.不支持的用例
【列出本软件所不支持的各项用例以及相应的原因。

此部分内容务必详细准确、无二义性，以作为将来验收和测试的标准。

】
4.数据描述
【说明本产品的输入、输出数据及数据管理能力方面的要求（处理量、数据量）。

描述的方式跟分析模型相关。

例如：
输入输出数据的类型及格式。

数据库描述(可选)：根据系统的总目标和范围，定义数据库的逻辑特性及物理特性。

数据流图；从数据传递和加工的角度描述的数据流图，此数据流图不包含任何有关实现的内容，只是从最上层对有关内容加以描述。

数据流图的表述形式参见软件工程中的有关规定。

数据词典：对于数据流图中出现所有被命名的图形元素在数据词典中作为一个词条加以定义，使得每一个图形元素的名字都有一个确切的解释。

】
5.系统需求（可选）
【
●功能性
功能性需求主要在用例模型中刻画，但是也有部分需求不适合在用例中表述。

有些功能性需求是全局性的，适用于所有的用例，如出错处理、I18N支持等，我们不需要在所有的用例中描述这些功能性需求，只需要在补充规约中统一描述就可以了。

●可用性
记录所有可用性相关的需求，如系统的使用者所需要的培训时间、是否应附合一些常见的可用性标准如Windows界面风格等。

●可靠性
定义系统可靠性相关的各种指标，包括：
1）可用性：指出可用时间百分比(xx.xx%)，系统处于使用、维护、降级模式等操作的小
时数；
2）平均故障间隔时间(MTBF)：通常表示为小时数，但也可表示为天数、月数或年数；
3）平均修复时间(MTTR)：系统在发生故障后可以暂停运行的时间；
4）精确度：指出系统输出要求具备的精密度（分辨率）和精确度（按照某一已知的标准）；
5）最高错误或缺陷率：通常表示为bugs/KLOC（每千行代码的错误数目）或bugs/function-point（每个功能点的错误数目）。

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

●可支持性
定义所有与系统的可支持性或可维护性相关的需求，其中包括编码标准、命名约定、类库、如何来对系统进行维护操作和相应的维护实用工具等。

●设计约束
设计约束代表已经批准并必须遵循的设计决定，其中包括软件开发流程、开发工具、系统构架、编程语言、第三方构件类库、运行平台和数据库系统等等。

】
6.运行需求（可选）
6.1.用户界面
【描述用户界面方面的需求，包括：
本软件的人机界面风格；屏幕布局或解决方案的限制；将出现在每个屏幕的标准按钮、功能或导航链接（例如一个帮助按钮）；快捷键；错误信息显示标准，等等；】
6.2.硬件接口
【描述系统中软件和硬件每一接口的特征。

这种描述可能包括支持的硬件类型、软硬件之间的交流的数据和控制信息的性质以及使用的通信协议。

】
6.3.软件接口
【描述该产品与其他外部组件（由名字和版本识别）的接口，包括数据库、操作系统、工具、库和集成的商业组件等。

对于每个需要的软件，应提供：
1.接口名称
2.规格说明
3. 版本号】
6.4.通信接口
【描述与产品所使用的通信功能相关的，包括电子、Web浏览器、网络通信标准或协议及电子表格等等。

定义了相关的消息格式。

规定通信安全或加密问题、数据传输速率和同步通信机制。

】
7.其它需求（可选）
【如健壮性、安全保密性、复用性、灵活性、易用性、可维护性、可移植性等。

指明不同属性的相对侧重点，例如易用程度优于易学程度，或者可移植优于有效性。

健壮性：说明软件在容错能力，故障处理能力上需要达到的目标，保证系统稳定可靠；
安全保密性：包括用户身份确认或授权方面的需求，保密性策略，产品所创建或使用的数据的保护等等；
复用性：说明本项目是否可以复用已有软件、是否可为其它产品复用；
灵活性：说明在运行环境、与其他软件的接口以及开发计划等发生变化时，应具有的适应能力。

】
8.特殊需求（可选）
【由用户提出的，或是本公司要求的特殊要求、特殊的情况等。

】
9.不确定的问题（可选）
【说明目前尚未确定的问题及处理的计划。

例如：编辑一张在软件需求规格说明中待确定问题的列表，为每一表项都是编上号的，以便于跟踪调查。

】
10.编写人员及编写日期
【列出参与编写的人员的名字，并标明负责人。

】
11.附录
11.1.引用文件
【没有引用文件时删除此项，否则依次列出本指南所引用的文件，如需求备忘录，需求调查报告等，如有多种，其序号使用1.、2.、……，】
11.2.参考资料
【没有参考资料时删除此项，否则依次列出本指南所引用的参考资料，如有多种，其序号使用1.、2.、……】
【编写说明】
编写文档时，要求具有本模板规定的所有条目。

如果某条目无内容，则填写“无”，并在可能的情况下说明理由。

必要时，可增加适当的条目。