需求规格说明书编写指南

管理信息系统
[/b]

需求规格说明书编写指南
[/b]

文档属性：
[/b]

文档编号 [/b]
文档版本 [/b]	V1.0
保密级别 [/b]
拟制 [/b]
审核 [/b]
批准 [/b]

[/b]

修改记录：
[/b]

日期 [/b]	修改章节 [/b]	修改类型* [/b]	修改描述 [/b]	修改人 [/b]	版本 [/b]
03.8.10	All	A	创建	张昱	1.0

*修改类型分为 A[/b] - ADDED M[/b] - MODIFIED D[/b] – DELETED

[/b]

1、概述

指南
[/b]

目的：[/b]
[/b]

介绍系统的开发背景。

[/b]

内容：[/b]
[/b]

l 软件名称和版本

l 系统目标

l 客户和用户

l 产品理念

l 文档约定

l 参考文献

[/b]

方法和要点：[/b]
[/b]

l 1.1节填写软件名称和版本

l 1.2节填写软件开发目标，要求用量化的指标说明问题。可以参考《用户需求报告》

l 1.3节填写客户和用户。通常，购买软件的组织或个人是软件的客户；软件的具体使用人员是软件的用户。

l 1.4节填写产品理念，包括对产品的预期；产品的意义；产品的价值；产品的理论依据等。

l 1.5节填写文档约定，包括文档编号约定、命名标准、功能项描述约定、优先级说明、参考需求描述约定。

l 1.6节填写参考文献。包括参考的软件、文档和著作等。

1.1 软件名称和版本

1.2 目标

1.3 客户和用户

1.4 产品理念

1.5 文档约定

需求优先级说明
[/b]

优先级别	重要程度	说明
优先级1 [A1][/b]	最优先	必须实现。本文中未做特别表明的需求，优先级均默认为优先级1。
优先级2 [A2][/b]	优先	争取实现，如困难，可以变通的方式实现
优先级3 [A3][/b]	中等	争取以变通的方式实现，如困难，则考虑到再升级时实现
优先级4 [C4][/b]	可以等待	再升级时必须实现
优先级5 [C5][/b]	不太必要	再升级时以变通的方式实现

1.6 参考文献

2、术语表

指南
[/b]

目的：[/b]
[/b]

列出需要说明的概念、术语和缩写，以便读者能够准确而一致地理解文档内容。

[/b]

内容：[/b]
[/b]

l 业务术语和缩写

l 容易产生歧义的计算机属于和缩写。

[/b]

方法和要点：[/b]
[/b]

l 关注重要的、频繁出现的、不常见的、容易出现歧义的名词、术语和缩写。

l 如果术语较多，建议将术语分类。

l 对于名词、术语和缩写的解释尽量采用权威解释，尽量标明出处。

l 必要时添加图表辅助说明。

3、综合描述

指南
[/b]

目的：[/b]
[/b]

综合概括系统的应用情景。让用户和开发人员对系统，以及系统涉及到的相关方面有一个整体的认识。

[/b]

内容：[/b]
[/b]

l 系统的背景和范围

l 组织结构

l 岗位定义

l 作业流程

l 单据、账簿和报表

l 功能结构

l 功能列表

l 运行环境

[/b]

方法和要点：[/b]
[/b]

启用新系统后：

l 组织结构、岗位和流程将有哪些变化？

l 单据、账簿和报表将带来哪些改变？

l 系统的总体结构是什么？

l 系统提供哪些主要的功能？

l 系统的应用环境是什么？

本章回答上述问题。

计算机系统的启用，很可能为企业带来新的管理思想和经营方式，原有的组织结构、岗位定义和作业流程将面临变化。原有的组织结构可能被调整，原来的岗位可能撤销或合并，原来的部分手工操作可能被计算机系统所取代。伴随计算机系统的启用，还可能建立新的部门，并派生出新的岗位，原来的流程将被全面梳理。一个计算机系统的启用，如果“换汤不换药”，不对原有组织、岗位和流程进行一遍梳理，那么计算机系统产生的价值将得不到体现，时间一长，很可能从基层操作人员中萌生抵触情绪，最终流于形式。当然，并不一定使用计算机系统以后，组织、岗位和流程一定会变，有可能用户一开始已经建立了适应计算机管理的组织和流程，或者计算机系统的启用，不足以改变现有组织和流程，那么，不变也是对的。

单据、账簿和报表是流程的载体，如果流程发生变化，单据、账簿和报表往往也发生相应的变化。启用计算机系统后，借助计算机系统强大的处理能力，用户可能查询到更多的数据，单据的格式也可能更趋于灵活、统一。基于上述原因，应该描述变化后的单据、账簿和报表。

系统功能结构，描述了我们对系统的“大局观”。这部分内容对于设计人员理解需求具有很大的帮助，同时可以验证分析人员是否正确设定了系统边界以及功能设计是否清晰合理。

系统功能列表，从产品角度代表了对客户的一种承诺。功能列表从管理角度讲，、可以导出到“需求设计实现测试覆盖列表”中，作为设计、实现和测试追溯的源头。

功能结构和功能列表，概括地给出了系统的总体规格。

系统的运行环境，将描述系统运行的软件、硬件和网络环境，以及大致的物理部署情况，其中还包括外设，特殊接口，第三方控件，中间件等。

下面是对本章各节的具体分工：

l 3.1节描述业务背景和范围。

l 3.2节描述使用该系统后，用户的组织结构以及部门职责。如果有《用户需求报告》，可以省略和《用户需求报告》相同的内容。如果没有《用户需求报告》，则不能省略这部分内容。

l 3.3节描述使用该系统后，用户的岗位定义。如果有《用户需求报告》，可以省略和《用户需求报告》相同的内容。如果没有《用户需求报告》，则不能省略这部分内容。

l 3.4节描述使用该系统后，用户的业务流程。如果有《用户需求报告》，可以省略和《用户需求报告》相同的内容。如果没有《用户需求报告》，则不能省略这部分内容。

l 3.5节描述使用该系统后，用户使用的单据、账簿和报表。如果有《用户需求报告》，可以省略和《用户需求报告》相同的内容。如果没有《用户需求报告》，则不能省略这部分内容。

l 3.6节给出功能结构，建议用图形辅助文字的形式进行描述。应当综合、概括地说明问题，避免陷入具体细节。

l 3.7节给出功能列表。必要时对功能进行分类。建议使用编号进行管理。建议建立优先级。

l 3.8节给出系统运行的硬件、软件环境，包括大致的物理部署。

3.1 背景和范围

3.2 系统的组织结构

组织结构图
[/b]

部门职责列表[/b]
[/b]

部门 [/b]	职责 [/b]

3.3 系统的岗位定义

岗位定义表[/b]
[/b]

岗位 [/b]	所在部门 [/b]	岗位职责 [/b]

3.4 系统的作业流程

3.5 系统的单据、账簿、报表格式

3.6 功能结构

3.7 功能列表

编号	功能项	优先级	功能简要说明

3.8 运行环境与物理部署

4、功能需求

指南
[/b]

[/b]

目的：[/b]
[/b]

用Use Case契约的形式给出详细的功能需求。

[/b]

内容：[/b]
[/b]

参见样例。

方法和要点：[/b]
[/b]

[/b]功能需求描述的一般要求。见下表。

功能需求的描述约定。见下表。

界面元素描述约定。见下表。

指南：功能需求的一般要求
[/b]

正确	准确地描述要交付的功能。用户决定需求的正确性。
明确	每个需求都有一种且只有一种解释。
一致	文档内容保持一致 文档与前期工作产品保持一致。
完整	包括所有的重要需求。
恰当	恰当地限制需求范围，合理地使用需求约束。 不指定任何设计或实施细节，不附加软件之外的更多约束。
可实现	每个需求必须是可是实现的。
可跟踪	每个需求都有明确的标识符。 每个需求的来源都是确定的。
可验证	每个需求是可验证的。
可修改	允许在结构和样式不变的情况下，方便地对更改需求。
易理解	容易被客户和开发人员理解。
可复用	容易被同类项目或产品复用。
优先级	每个需求都有明确的优先级。

指南：功能需求描述约定
[/b]

编号	<功能项编号>	优先级	<功能项的优先级>
功能描述	<功能项的简要描述>
交叉引用	<所引用的其他功能编号>
前置条件	<用户可以执行该功能的前提或条件>
典型操作
用户操作<逐条列举用户可能的操作，包括分支>	系统响应<系统对用户操作作出的反映>
1)	1)
2)	2)
3)	3)
4)	4)
后置条件	<该功能完成实现后，对业务系统的影响> <该功能完成实现后，系统的状态>
异常	<发生的例外情况>
参考界面
<界面图片>

指南：界面元素描述约定
[/b]

数据项	数据描述	约束	能否修改	初始值
<可见的元素>	<功能和作用>	<显示格式和范围>	<能否修改>	<初始值>
<其他的元素>	<功能和作用>	<约束和范围>	-	<初始值>

5、公共部件

指南
[/b]

[/b]

目的：[/b]
[/b]

提取可以复用的公共部件，减少文档冗余。

[/b]

内容：[/b]
[/b]

打印和预览。

条件查询

权限

……

方法和要点：[/b]
[/b]

基于增加复用和减少文档冗余的目的，建议分析人员将需求阶段比较明显的可以复用的需求规格项提取出来，独立成章，这样做的优点有两个：

1. 可以作为设计人员设计复用部件的依据。

2. 文档中使用这些共用部件的部分直接引用到公共部件，不需要重复说明，从而减少文档冗余。

[/b]

6、业务建模

指南
[/b]

目的：[/b]
[/b]

以第4章功能需求中定义的UseCase为线索，建立业务模型。

[/b]

内容：[/b]
[/b]

参考业务建模样例。

方法和要点：[/b]
[/b]

参考业务建模指南。
[/b]

7、数据实体

指南
[/b]

[/b]

目的：[/b]
[/b]

识别数据实体和实体关系。

内容：[/b]
[/b]

实体关系图

实体描述

方法和要点：[/b]
[/b]

业务系统往往使用关系型数据库。数据实体是建立关系型数据库数据结构的重要依据。

数据实体的重要来源是单据、账簿、报表，以及业务建模过程中识别出的永久保存对象。

数据实体的要素为：实体名、属性和实体关系。

指南：实体关联图样例
[/b]

指南：实体描述模板
[/b]

名称	<数据实体的名称>
注释	<数据实体的注释>
数据量的估计	<数据容量的估计（按行）> 行	<数据量的估计(按字节)> K
索引	<索引，根据情况可以不填>
别名	列名	数据类型	空值	缺省	规则	注释
<中文名称>	<正式的名称>	<数据类型>	<能否为空>	<能否缺省>	<是否主外键>	<注释>

8、非功能需求

指南
[/b]

目的：[/b]
[/b]

描述系统的非功能性需求

[/b]

内容：[/b]
[/b]

l 外观

l 易用性

l 性能

l 可靠性

l 质量要求

l 其他

方法和要点：[/b]
[/b]

l 8.1节填写期望的产品外观，包括：

显示方式

显示风格

外观倾向

外观意图

……

l 8.2节填写易用性要求，包括

易操作

易学习

易理解

……

l 8.3节填写系统性能。包括：

速度

效率

可用性

准确性

吞吐量

响应时间

恢复时间

……

l 8.4节填写可靠性。包括：

故障的频率/严重性

可恢复性

可预见性

准确性

平均故障响应时间（MTBF）

……

l 8.5节填写质量要求。

千行Bug数。

……

l 8.6节填写其他非功能性需求。

[/b]

8.1 外观

8.2 易用性

8.3 性能

8.4 可靠

8.5、质量要求

8.6、其他

9、其他描述

9.1 开发环境

9.2 设计和实现上的限制

9.3 需求—分配需求对应情况

需求—分配需求对应情况 [/b]
需求（按需求的编号，从小向大递增）	分配需求（对分配需求编的号）

10、附录：

10.1 待定问题列表

10.2 附件