产品需求规格说明书CMMI项目管理模板

{项目名称}
产品需求规格说明书
文件修改版本控制
更新状态: 用字母表示。

C——创建，A——增加，M——修改，D——删除
目录
1引言 (5)
1.1 编制目的 (5)
1.2 预期读者 (5)
1.3 项目背景 (5)
1.4 编制原则 (5)
1.4.1内容上 (5)
1.4.2形式上 (6)
1.5 术语释义 (7)
1.6 参考文献 (7)
2项目概述 (8)
2.1 项目定义 (8)
2.2 项目目标 (8)
2.2.1本期目标 (8)
2.2.2长远目标 (8)
2.3 系统功能 (8)
2.4 用户权限 (8)
2.5 设计原则 (8)
3业务需求 (10)
3.1 业务理解 (10)
3.2 业务大类 (10)
3.3 业务子类 (10)
3.3.1总述 (10)
3.3.2业务流程图 (10)
3.3.3业务环节说明 (10)
3.3.4角色和作用 (10)
3.4 需求矩阵 (10)
4功能需求 (11)
4.1 功能大类 (11)
4.1.1子功能 (11)
4.1.1.1 功能描述 (11)
4.1.2.1 功能实现流程 (11)
4.1.3.1 业务中使用的信息项 (11)
5数据需求 (12)
5.1 数据质量需求 (12)
5.1.1规范性需求 (12)
5.1.2一致性需求 (12)
5.1.3完整性需求 (12)
5.1.4数据质量标准 (12)
5.2 数据接口 (12)
6其他需求 (13)
6.1 性能需求 (13)
6.1.1精度 (13)
6.1.2有效性 (13)
6.1.3健壮性 (13)
6.1.4响应时间 (13)
6.1.5数据更新处理时间 (13)
6.1.6灵活性 (13)
6.1.7前端展现工具的性能 (14)
6.2 系统需求 (14)
6.2.1安全性 (14)
6.2.2互操作性 (14)
6.2.3可管理性 (14)
6.2.4可用性 (14)
6.2.5系统效率 (14)
6.2.6设备 (15)
6.2.7支持软件 (15)
6.2.8接口管理 (15)
6.2.9网络环境 (16)
7附录 (17)
1引言
1.1编制目的
说明编写这份需求分析说明书的目的。

本需求分析说明书为XXXX公司XXXX项目的系统技术开发和需求分析编制。

此需求分析说明书的主要目的是为系统设计人员进行系统设计时提供详细的业务需求、功能需求、数据需求和其他需求的说明，使系统设计人员顺利的完成系统的设计和开发，给后期系统测试和维护人员提供参考。

1.2预期读者
指出这份需求分析说明书的预期读者。

文档读者包括：
（1）XXXX系统设计人员和开发人员；
（2）XXXX总公司最终用户及技术人员；
（3）XXXX各分公司最终用户及技术人员；
（4）××事业部BA成员及相关管理人员。

1.3项目背景
说明待开发软件系统的背景和目前面临的问题。

1.4编制原则
说明这份需求分析说明书在内容上和形式上的编制原则。

1.4.1内容上
为保证所编制需求分析说明书的科学性、系统性、规范性和适用性，使《XXXX项目需求分析说明书》具有较高的质量，我们坚持以下原则编制：
（1）科学性原则
科学性是编制的最基本原则，也是最高原则，充分、科学地深入理解客户的需求，并将其转化为技术上可以实现的系统开发和设计的说明书。

（2）系统性原则
系统性是需求分析说明书中各个章节之间具有系统联系。

如下图所示：
图2：《XXXX项目需求分析说明书》逻辑架构图
（3）可预测性和扩展性相结合原则
需求分析说明书既要考虑到XXXX项目现有的核心业务系统的技术和应用水平，也要对未来XXXX的需求应用的发展趋势有所预测，在应用体系上保持可扩展性，以适应XXXX战略发展及应用发展的需要。

1.4.2形式上
（1）格式约定
✧一级标题为黑体，二号字体，黑色粗体显示；
✧二级标题三号字体，三级标题四号字体，都为黑体，黑色粗体显示；
✧正文为宋体、五号字体，1.5倍行间距。

（2）排版约定
✧标题编号采用每节独立编号；
✧在更新完内容后，更新目录域和相关的页数域。

1.5术语释义
提供专业数据分析方法涵义、领域术语的理解以及首字母缩写词和缩略语。

此小节应提供正确理解XXXX项目需求说明书所需的全部术语的定义、首字母缩写词和缩略语。

对于XXXX项目所涉及的数据分析方法的定义可以见下述定义（可选项）：
1.6参考文献
此小节应完整地列出需求分析说明书中所引用的所有文档。

✧每个文档应标有标题、报告号（如果适用）、日期和出版单位。

✧列出可以获取这些参考资料的来源。

这些信息可以通过参考附录或其他文档来提供。

2项目概述
2.1项目定义
说明待开发软件系统的名称、涉众者和范围。

说明：
（1）待开发的软件系统的名称；
（2）本项目的任务提出者、开发者、用户及实现该软件的计算中心或计算机网络；
（3）该软件系统同其他系统或其他机构的基本的相互来往关系。

2.2项目目标
说明待开发软件系统的本期目标和长远目标。

2.2.1本期目标
2.2.2长远目标
2.3系统功能
用树状图简要说明待开发软件系统的功能结构。

2.4用户权限
用矩阵方式说明待开发软件系统的功能与用户权限的配置，以及预计系统的可能用户数。

（根据不同的项目，此项可选）
2.5设计原则
说明待开发软件系统的设计原则。

✧人机可视化的操作界面
✧使用方便，操作简单
✧多种应用满足多种不同用户需求
✧灵活配置和调整，适应用户需求的改变✧个性化的用户页面
3业务需求
3.1业务理解
文字描述对XXXX项目的业务理解。

3.2业务大类
总体描述业务大类的具体业务情况。

3.3业务子类
3.3.1总述
从客户的角度描述业务分类所涉及的业务情况，实施业务所依据的相关法律法规，业务实现需要满足的业务规则等
3.3.2业务流程图
用流程图的方式展示业务处理的流程
3.3.3业务环节说明
针对业务流程图中的各个处理环节进一步说明。

3.3.4角色和作用
对业务流程图中涉及的相关角色和职责作用的描述
3.4需求矩阵
按照需求跟踪矩阵模板建立需求矩阵。

本章提供对功能需求的描述，包括展现方式，展现界面等的描述。

4.1功能大类
从系统实现的角度描述需要实现的功能的总体情况，其对于系统的作用，以及所包含的子功能。

4.1.1子功能
4.1.1.1功能描述
总体描述子功能实现的目标。

处理的主要问题。

4.1.2.1功能实现流程
简易流程的方式描述系统要实现该功能需要经历的功能实现流程。

该部分可以忽略4.1.3.1业务中使用的信息项
详细描述功能实现时涉及到的信息项以及其要求说明。

本章提供对数据质量需求的规范说明和数据质量标准的描述。

5.1数据质量需求
5.1.1规范性需求
对项目所涉及的业务数据进行规范性的定义和计算说明。

5.1.2一致性需求
对系统涉及到的数据的合法性、完整性和一致性的要求。

对于交叉性的数据需求提供一致性的客户确认说明。

5.1.3完整性需求
数据的完整性是指在技术上保证用户的业务数据的完整性。

5.1.4数据质量标准
（1）对数据质量结果的验证，如误差率。

（2）
5.2数据接口
数据源描述或者定义，数据结果获取途径或者方法。

如业务系统结构表，或者接口表
（1）需要的数据获取途径；
（2）统计需求与源系统的对应关系。

此部分可以忽略
本章提供对其他如性能需求、系统需求等非功能性需求的具体描述。

6.1性能需求
6.1.1精度
系统内涉及的“金额”要求精确到小数后两位。

系统内涉及的“时间”要求精确到月或日，根据具体情况确定。

6.1.2有效性
时间特性需求：如系统持续运行时间，在无外界干扰（如停电、操作系统故障、硬件故障等）的正常情况下，系统能够执行7 *24的概率。

或者表述为“工作日期间，在当地时间早上6点到午夜，系统的有效性至少达到99.5%，在下午4点到6点，系统的有效性至少可到达99.95%。

1”
6.1.3健壮性
健壮性指当系统或者其组成部分遇到非法输入数据、相关软件或硬件组成部分的缺陷或异常的操作情况时，能继续正确运行功能的程度。

6.1.4响应时间
网络、主机、数据库系统无问题的情况下，除下载、上传大文档以外操作系统10秒以内完成。

6.1.5数据更新处理时间
界面刷新处理时间的要求，若在网络、主机、数据库系统无问题的情况下，除下载、上传大文档以外操作系统10秒内完成。

6.1.6灵活性
操作方式：每个功能模块化，操作方便，导航方式清晰。

如可以表述为：“一个至少具有6个月产品支持经验的软件维护程序员可以在一个小时之内为系统添加一个新的可支持硬拷贝的输出设备。

”
1行业惯例是当表述为系统的有效性达到99.9%，是以“天”作为故障统计的单位；99.99%，是以“小时”作为故障统计的单位；99.999%是以“分钟”作为故障统计的单位，而99.9999%则是以“秒”作为故障统计的单位。

6.1.7前端展现工具的性能
前端展现工具的性能（又成“效率”）直接影响用户对该系统的接受程度，在规定的时间内得不到想要的报表显然用户对系统不可接受，这就对前端展现工具提出了越来越高的要求。

6.2系统需求
6.2.1安全性
整个应用系统的安全管理简而言之是通过算法加密使用密码控制非法用户进入，通过密钥加密杜绝网上截取，通过功能级权限和数据级权限相结合的方式来限制越权行为。

表述如“只有拥有查账员访问特权的用户才可以查看客户交易历史”。

6.2.2互操作性
互操作性表明本产品与其他系统交换数据和服务的难易程度。

如表述为：“XXXX跟踪系统应该能够从MagicDraw UML工具中导入任何有效流程结构图。

”
6.2.3可管理性
系统应当具有较强的可管理性，提供简便的工具对整个系统的运行进行管理。

如提供统一门户管理等。

6.2.4可用性
可用性也称为“易用性”和“人类工程”，所描述的是许多组成“用户友好”的因素。

可用性衡量准备输入、操作和理解产品输出所花费的努力。

如可以描述为：“一个培训过的用户应该可以在平均3分钟或者5分钟时间以内，完成从反洗钱数据库中请求汇总统计的操作。

”
6.2.5系统效率
效率是用来衡量系统如何优化处理器、磁盘空间或者通信带宽。

2
为了在不可预料的条件下允许安全缓冲，可以如下定义：“在预计的高峰负载条件下，10%处理器能力和15%系统可用内存必须留出备用。

”在定义性能、能力和效率目标时，考
2DA VIS 1993提出效率是用来衡量系统如何优化处理器、磁盘空间或者通信带宽。

虑硬件的最小配置是很重要的，保守估计是20%。

6.2.6设备
6.2.7支持软件
此部分根据实际需要进行选择
6.2.8接口管理
说明该系统的硬件接口；
软件接口及需求发生变化时的适应能力；
通信接口。

6.2.9网络环境
本系统在企业内部局域网构建。

源码和许可权：开发商提供查询程序的源代码。

7附录
项目需求分析说明书应明确指出是否将附录当作需求分析说明的一部分。

业务部门代表确认：_________________
日期：
信息技术部确认：_________________
日期：
项目经理确认：_________________
日期：。