需求规格说明书样例.docx

需求规格说明书样例.docx

《需求规格说明书样例.docx》由会员分享，可在线阅读，更多相关《需求规格说明书样例.docx（24页珍藏版）》请在冰豆网上搜索。

需求规格说明书样例

需求规格说明书

第一章综述1

1.1编制目的1

1.2适用范围1

1.3参考依据1

1.4编制约束1

1.4.1图元约束1

1.4.2编码约束2

1.4.3格式约束3

1.5内容结构（可选）4

1.6导读说明4

第二章项目概述5

2.1项目背景5

2.2项目范围5

2.3项目目标5

2.4现状描述5

第三章需求总体分析6

3.1功能体系设计6

3.1.1功能结构6

3.1.2功能分布7

3.2整体业务流程（可选）8

3.3业务标准体系9

第四章功能性需求10

4.1功能综述10

4.2需求清单10

4.3需求优先级（可选）10

4.4功能编码?

功能项11

4.4.1功能综述11

4.4.2业务流程11

4.4.3关系分析13

4.4.4详细功能需求13

第五章非功能性需求17

5.1软件质量属性需求17

5.1.1运行期17

5.1.2非运行期20

5.2约束性需求20

5.2.1基础架构20

5.2.2标准规范21

5.2.3集成要求21

5.2.4其他约束21

第六章集成需求22

6.1技术要求22

6.2数据集成22

6.3应用集成22

6.4流程集成23

第七章尚需解决的问题24

7.1问题总表24

7.2问题处理24

附录I业务对象25

第一章综述

若采用分册编制方式组织，则本章与第二章、第三章单独成册，其它分册可略去本章、第二章和第三章内容。

一.1编制目的

用简洁的语言描述编写这个文档的目的。

一.2适用范围

本文档适用的范围。

一.3参考依据

列举编写软件需求规格说明时所参考的资料或其它资源。

这可能包括且不限于：

用户界面风格指导、合同、标准、系统需求规格说明、使用实例文档，或相关产品的软件需求规格说明。

对于非易获得性或项目所专属的参考资料，应当以附件形式提供。

一.4编制约束

一.4.1图元约束

（1）流程图图元约束：

图形符号

名?

?

称

定?

?

?

义

开始框

标准流程的开始，每一流程图只有一个起点

结束框

流程的中断和结束

处理框

表示对事件或结果的处理过程

决策或判断

用来根据给定的条件是否满足决定执行两条路径中的某一路径

流程线

箭头的方向表示流程执行的方向与顺序，两个符号间不得使用双箭头

连接标识

用于同一流程图中页和页的连续或者用于同页内从一个动作框转到另一个动作框

流程标识

表示在流程图中引用另一个流程

（2）流程图展示方式约束：

流程图推荐采用纵向页面布置、横向职能带布置的样式，另根据需要可增加划分业务流程阶段，但不得改变流程图基本样式。

流程图中所用符号应均匀分布，连线保持合理的长度，并尽量少用长线。

使用各种符号应注意符号的外形和各符号大小的统一，避免使符号变形或各符号大小比例不一。

符号内的说明文字尽可能简明。

通常按从左向右和从上向下方式书写，并与流向无关。

尽量避免流线的交叉，即使出现流线的交叉，交叉的流线之间也没有任何逻辑关系，并不对流向产生任何影响。

一个大的流程可以由几个小的流程组成。

单个流程过于复杂时，在不影响业务的完整性和连续性的前提下，应拆分为两个及以上子流程。

所附表单能体现流程要求时，则可简化流程图，尽量将表单能体现的流程要求合并为一个流程节点。

一.4.2编码约束

在信息一体化管控体系和标准化规范里面已经明确规定的，本处作为引用说明（如标准编码部分），没有明确说明的，采用以下编码约定方式：

（1）业务域编码（根据公司管理制度的划分，定为14个业务域。

业务域缩写说明：

前面2位数字是公司管理制度所用的分类编码，后面两位英文缩写是信息系统所用业务域编码）

●10安全管理（SM-SafetyManagement）：

包括安全综合管理、监督管理、风险管理、应急管理等。

●11生产管理（PM-PlantMaintenance）：

包括运行、维护、技改修理、设备资产策略、技术监督、科技进步等。

●12调度管理（DM-DispatchManagement）：

包括电力调度、运行方式、水调、技术经济、继电保护、安全自动装置、电力通信及调度自动化管理等。

●13规划建设（PP-ProductionPlanning）:

包括电网规划、节能减排、项目前期、项目计划及管理、工程管理、质量安全管理、造价管理、承建商管理等。

●14营销服务（BM-BusinessManagement）：

包括市场交易、营销策略、客户管理、业扩管理、抄核收管理、线损管理、营销稽查、用电检查、需求侧管理、计量管理、营配一体化等。

●15人力资源（HR-HumanResource）：

包括组织管理、人才管理、绩效与激励、培训管理等。

●16财务管理（FI-Finance）：

包括资金管理、预算管理、固定资产管理、产权管理、投资管理、成本管理、税务管理、会计核算、经营分析、经营考核、财务风险管理等。

●17物资管理（MM-MaterialManagement）：

包括物资管理策略、需求管理、采购管理、仓储物流、供应商管理、品控管理等。

●18信息管理（IM-InformationManagement）：

包括信息管理、运维管理、信息安全、信息应用等。

●19监审内控（EC-EnterpriseControl）：

包括法律与合同管理、纪检监察、内控审计等。

●20党群工作（CC-CorporateCulture）：

包括党的建设、企业文化、青年工作、思想教育、工会管理等。

●21行政办公（OA-OfficeAssistant）：

包括综合行政、新闻管理、后勤保障等。

●22基础管理（BA-Basis）：

战略管理、政策研究、体制改革、指标管理、制度建设、创新管理等基础性管理制度。

●23其他（OT-Other），不能划归以上分类的公司其他业务。

（2）业务类编码

●业务域编码+二位数字序号。

例：

营销业扩可编码：

BM01

（3）流程编码（Flow）

●F-业务类编码-四位数字序号。

（4）业务对象编码（Entity）

●E-业务类编码-四位数字序号。

（5）表单编码（Bill）

●B-业务类编码-四位数字序号。

（6）规则算法编码（Arithmetic）

●A-业务类编码-四位数字序号。

（7）标准规范编码（Standard）

●标准规范采用统一编码，S-业务域编码-四位数字序号。

（8）关系编码（Relation）

●业务域与业务域

R-主业务域编码-副业务域编码-2位序号。

●业务类与业务类

R-主业务类编码-副业务类编码-2位序号。

（9）功能项编码（Model）

●一级功能：

M-业务类编码-3位序号

●二级功能：

一级功能编码-3位序号。

●N级功能：

以此类推。

一.4.3格式约束

文档模板：

文档编制必须严格依据本文档模板的格式要求。

（1）引用描述格式

●《<资料名称>》<发布单位><发布日期>

●《<资料名称>》（<文号>）

●《<资料名称>》（<标准号>）

（2）文字格式

●Word样式，正文首行缩进

●首行缩进2字符，宋体，小四，1.5倍行距，段前0，段后0。

（3）表格格式

●列标题，Word样式，表格标题

●列标题，首行缩进无，居中，宋体，五号，单倍行距，段前0，段后0。

●列标题，重复标题行

●表格正文，Word样式，表格正文居左

●表格正文，首行缩进无，居左，宋体，五号，单倍行距，段前0，段后0。

●表格正文中的序号，Word样式，表格正文居中

●表格正文中的序号，首行缩进无，居中，宋体，五号，单倍行距，段前0，段后0。

（4）图格式

●Word样式，图居中

一.5内容结构（可选）

对文档的内容编排进思路、结构进行说明，对于复杂业务或文档内容超越300页以上的文档，建议在结构允许的情况下，分册编制，并在此处对每个分册的内容简要介绍，便于给阅读者以完整概念。

一.6导读说明

为便于读者有针对性的阅读（特别针对预期读者），本部分对各章节（及存在的分册）进行索引和导读。

形式建议：

序号

如果您是：

请关注以下部分：

1

领导层

2

公司业务人员

3

公司信息人员

4

项目建设人员

5

评审人员

6

……

第二章项目概述

二.1项目背景

对项目工作产生的背景做明晰的描述。

二.2项目范围

本业务模型涉及到的业务覆盖范围和组织覆盖范围。

二.3项目目标

明确描述项目建设要达到的目的、指标、功能要求等。

二.4现状描述

简要阐述业务现状，以业务为主，尽量用表格或图示方式综合展现。

第三章需求总体分析

根据业务发展战方向，在业务范围内对业务模型做总体规划，分解业务体系结构，建立整体业务模型视图，包括业务域、业务类、业务流程、功能项等内容。

三.1功能体系设计

从业务实际出发，以功能为单元，划分合理的业务功能结构，以业务结构图表达更清晰。

三.1.1功能结构

三.1.1.1功能结构图

可以以树型或关系型图展现合理划分的业务功能构成的整体结构。

例如关系型展如下：

三.1.1.2功能列表

列出一级功能清单，为每个功能按规则编码，并清晰阐述功能主要内容。

功能编码

功能项名称

说明

三.1.2功能分布

业务功能在不同的管理层级、不同的单位所表现的侧重点及应用面。

例如，可以以图示方式展示如下：

也可以以表格方式说明。

三.2整体业务流程（可选）

以图示的方式展示业务的整体流程，如无法归纳完整，则略过此小节，在各功能中详细阐述。

整体流程一般为概念意义，例如资产管理流程：

流程模型在阐述时一定要注意横向各部门、纵向各单位之间的流转关系，如果涉及，应详细说明。

三.3业务标准体系

在业务建模过程中，如存在根据业务情况已经或可标准化的业务信息，以树型或列表方式全面罗列。

编号

标准名称

说明

第四章功能性需求

四.1功能综述

功能需求分三级：

业务类、业务流程、业务环节。

●业务类需要描述该业务系统包含的业务流程及模块；

●业务流程需要描述该流程包含的功能项；

●功能项描述具体功能点的业务需求，具体功能描述可以向下逐层细化。

四.2需求清单

例表：

业务类

业务流程

功能编码.功能项

业务环节

功能子项编码.功能子项名称

说明

业扩报装

高压新装

AXX0011.高压新装

提交申请

AXX0011-01.申请受理

查勘

AXX0011-02.查勘

审批

AXX0011-03.审批

计费流程

AXX0012.工作流管理

……..

……..

……..

……..

……..

/

/

查询

XX查询

注：

对于不能归于某类和某流程的功能子项，业务类、业务流程留空。

四.3需求优先级（可选）

业务类所属业务流程对应的每个功能，均要按照下面的表格提供优先级说明，以供设计、开发、测试人员参考对工作进行安排。

表1需求优先级

业务类--

业务流程

功能

编码

功能项

重要性（10）

紧迫性（10）

成本（10）

难易程度（10）

累计

业扩报装—新装

AXX0011

高压新装

8

8

8

6

30

AXX0012

低压新装

7

7

7

7

28

AXX0013

增容

10

10

10

8

38

……

说明：

重要性（最高10分，最低1分）、紧迫性（最高10分，最低1分）、成本（实现成本最低时，该项得10分）、实现难易程度（最高10分，最低1分，容易实现的分数高），累计最高分数的需求应优先满足。

四.4功能编码?

功能项

例：

AXX0011-01?

高压新装

四.4.1功能综述

包括功能背景、功能目标、服务对象、场景等内容。

四.4.2业务流程

以轨道图的方式清晰阐述流程全过程，明确责任节点工作内容。

需求差异内容做到流程全覆盖，特殊情况和较大的差异需要加以标注和说明。

流程节点功能分析：

对于复杂的流程节点，采用文字说明补充。

编号

名称

描述

对应角色

1

查勘派工

查勘环节对业务申请受理传递过来的申请进行现场勘查，指定查勘人员进行业务的处理和现场工作

查勘人员

2

一级审批

对供电方案进行审批，审批需要注意的事项：

1、2、3…..

审批人员

3

……

……

……

四.4.3关系分析

以列表的方式将每个关系编号、功能项间关联关系、关系涉及到的表单、触发条件等做详细说明。

四.4.3.1内部关系（可选）

以图示的方式展现业务功能内部各功能之间的关系、接口，也可用文字、表格、图表结合表达。

编码

关系标识

说明

R-PS01-PL02-01

进度管理<->规划业务

表格中不便于阐述的，可以单独设立章节，详细说明

四.4.3.2外部关系

以图示的方式展现业务功能外部相关的关系、接口，也可用文字、表格、图表结合表达。

编码

关系标识

说明

R-PS01-PL02-01

进度管理<->规划业务

表格中不便于阐述的，可以单独设立章节，详细说明

四.4.4详细功能需求

四.4.4.1功能子项编码?

功能子项（二级）

如果业务较为复杂的，可以继续分解功能，内容同功能章节内容，目录级别降一级，其中没有内容的小节，可略。

如果到具体的节点功能项的，以本小节格式为主。

四.4.4.1.1功能综述

总体阐述功能业务情况、功能目标、应用场景和业务要求等。

四.4.4.1.2业务对象

列出本功能子项涉及的业务对象。

格式如下：

编码

业务对象

说明

四.4.4.1.3业务活动及流程

业务功能的活动流程图，描述关键环节和流程关系，图例如下：

四.4.4.1.4功能用例

用例编号

XX（一级编码）?

XX（二级编码）

用例名称

归档

业务说明

依据最终处理结果更新档案资料。

业务规则

档案变更完整的档案资料应包括：

「档案变更工作单BM19_BD_01」；

「用电变更现场勘查工作单BM01_BD_07」；

及时进行归档处理，以免对其它相关业务造成影响。

档案变更的内容如果涉及到合同履行，应联系客户修订合同。

档案变更的内容如果涉及到退补电量电费，应发起退补电量电费的业务。

使用级别

地市公司、区县公司、供电所

先决条件

审批已通过，且电子工作单已发送到归档环节。

功能要求

基本

功能

共计8个基本功能点

查询并选定待归档的档案维护电子工作单。

查询选定电子工作单的『档案变更申请信息』（19_001_001）、『档案变更资料核实信息』（19_001_002）、『档案变更审批信息』（19_001_003）。

根据工单信息的完整性和逻辑性对工单信息的正确性进行校验，校验不通过，可以选择环节退回。

根据『档案变更资料核实信息』（19_001_002）对相关客户档案信息进行修订，保存『档案变更归档记录』（19_001_004）。

登记『业务资料归档信息』（01_099_042）。

归档客户档案，发送资料归档通知到BM19_003_002〖档案资料管理〗【登记存档管理】业务项。

档案变更的内容如果涉及到合同履行，启动变更合同流程。

档案变更的内容如果涉及到退补电量电费，启动退补电量电费流程。

辅助

功能

共计2个辅助功能点

可查询『流程记录信息』（01_099_045）。

可以设置工单信息校验的业务规则。

提示

信息

对客户档案资料进行完整性校验，并提示校验结果。

对违反处理约束的内容进行提示。

处理

约束

必须输入业务资料归档信息：

资料编号，资料存放位置。

信息处理

要

求

输入

信息

『档案变更申请信息』（19_001_001）、『档案变更资料核实信息』（19_001_002）、『档案变更审批信息』（19_001_003）

『当前流程信息』（01_099_044）、『流程记录信息』（01_099_045）

输出

信息

『档案变更归档记录』（19_001_004）、『业务资料归档信息』（01_099_042）

『当前流程信息』（01_099_044）、『流程记录信息』（01_099_045）

考核要素

记录受理到归档的时间。

对从电子工作单到达至电子工作单归档的时间段进行考核。

非功能需求

快速响应类

根据权限设置只能处理本单位的工作单。

统计要素

档案维护归档户数

差异说明

无

表卡单据

无

四.4.4.1.5规则算法（可选）

本功能所涉及到的业务规范和标准，特别是信息分类与编码体系相关标准，在此处详细列出，并说明应用场景、限制原则和应用要求等。

编码

算法名称

说明

A-MM-0012

专家选取算法

…

表格中不便于阐述的，可以单独设立章节，详细说明。

A-MM-0013

供应商后评估算法

…

表格中不便于阐述的，可以单独设立章节，详细说明。

分项详细说明。

四.4.4.1.6界面原型

界面原形可以是独立运行的文件，如果没有可独立运行的界面原型文件，则通过这一节贴界面原型图片进行设计描述和展示，所有原型制定统一的编号，有特殊的要求要予以说明备注。

[图XXXX-XXX]

如果功能用例中有原型图片编号，需要与该编号一致

第五章非功能性需求

非功能需求是指软件质量属性定义中相对于功能性需求的其他质量属性，包括各类软件项目实施约束，统称为软件非功能性需求，是软件产品为满足用户业务需求而必须具有且除功能需求以外的特性。

软件产品的非功能性需求包括系统的性能、可靠性、安全性、可维护性、易用性、备份要求、集成要求等。

五.1软件质量属性需求

五.1.1运行期

五.1.1.1性能

五.1.1.1.1典型业务活动分析

典型业务活动通常指发生频率高或者系统涉及的核心业务活动，典型业务活动的完成效率是系统质量属性的重要表现，系统分析人员应充分识别分析典型业务活动，尽可能量化业务要求，建议采用如下方式：

业务活动

实际使用用户数量

业务发生数

（笔/天、小时、秒）

示例：

电费发票打印

100

10000

五.1.1.1.2关键性能指标

软件系统性能需求定义，视不同的类型的应用，关键性能度量指标应有所侧重：

●交互式应用：

同时在线用户数、系统响应时间、计算机资源可用率；

●后端应用：

每秒完成事务数量、计算机资源可用率。

软件系统性能需求定义必须是可量化的指标，建议针对不同应用类型，按如下规格定义性能需求：

（1）典型交互式应用系统性能需求定义规格

关键系统用例

峰值时间段

支持同时使用用户数

系统最高响应时间

（秒）

计算机资源可用率

示例：

系统登录

8:

00-10:

00

100

3

CPU平均使用率:

<75%

内存使用率：

<70%

（2）典型后端应用系统性能需求定义规格

关键系统用例

峰值时间段

吞吐量

（笔/秒）

计算机资源可用率

示例：

电费批量处理

23:

00-1:

00

100

CPU平均使用率:

<75%

内存使用率：

<70%

示例：

电费批量处理

用于不同规模部署要求

21:

00-23:

00

50

CPU平均使用率:

<75%

内存使用率：

<70%

五.1.1.2可用性

软件系统可用性主要由两项指标反映：

系统可用时间和系统恢复时间，系统可用性指标应匹配业务要求。

建议采用如下方式定义软件系统可用性需求：

关键业务活动

使用时段

数据恢复目标（RPO）

恢复时间目标（RTO）

示例：

基础架构容量趋势查询

高峰时段：

每天上午9:

00-10:

00

运行维护窗口：

每周六23:

00-次日8:

00

9小时

恢复点目标（RPO）：

是指一个企业在一次灾难（停电、病毒、自然或人为灾难）中所能接受的总数据损失量。

恢复时间目标（RTO）：

是指企业从灾难状态中恢复联网和正常功能所需的时间。

五.1.1.3可靠性

五.1.1.4鲁棒性

鲁棒性指软件系统在以下情况下仍能正常运行的能力：

用户进行了非法操作；相连的软硬件系统发生了故障，以及其他非正常的情况。

软件系统鲁棒性需求定义建议采用如下规格：

系统功能

定义要素

需求内容

1示例：

客户账号创建

客户账号创建

支撑非法输入防范能力

2示例：

必须执行非空检查；

3示例：

客户邮箱、客户电话等信息必须执行合法性检查。

支撑用户误操作防范能力

支撑避免单点故障的能力

支撑事务一致性的能力

支撑系统故障防范的能力

支撑系统故障及时排除的能力

系统发生故障时，系统其他方面的容错能力

五.1.1.5可伸缩性

五.1.1.5.1业务容量分析

系统用户访问量快速增长、数据量高速增长要求软件系统具有较好的可伸缩性，因此，业务数据容量分析是定义可伸缩性需求的基础，建议采用如下方式分析业务容量需求：

（1）业务容量需求

预计当前系统注册用户数

增长率

（年增长率或月增长率）

三至五年后系统注册用户数

（2）业务数据容量需求

业务数据项

业务数据增长率

（年增长率或月增长率）

访问高峰系统吞吐量

（笔/月、天）

访问高峰系统吞吐吞吐量增长率

五.1.1.5.2需求规格

需求分类

定义要素

需求内容

纵向扩展能力

支撑高访问量能力

支撑大数据量能力

提升计算能力要求

横向扩展能力

支撑高访问量能力

支撑大数据量能力

提升计算能力要求

五.1.1.6互操作性

互操作性反应软件系统的集成能力，互操作性需求定义建议采用如下方式：

需求分类

定义要素

需求内容

应用集成能力

支撑业务流程管理能力

支撑应用集成能力

支持南方电网公司统一认证管理能力

支持南方电网公司统一门户集成能力

数据交换与共享能力

支撑南方电网公司统一数据共享的能力

支撑南方电网公司统一数据交换的能力

五.1.1.7安全性

安全性需求定义规范可参考公司信息系统相关安全规范，同时对本业务系统特殊要求的安全内容予以说明。

五.1.1.8易用性

软件系统易用性需求主要体现在易用性软件被理解、学习、使用和吸引用户的能力，建议采用如下方式定义易用性需求：

需求分类

定义要素

需求内容

用户界面

界面风格要求

界面导航要求

界面输入要求

界面提示要求

文档支持

在线帮助要求

离线文档要求

五.1.2非运行期

五.1.2.1可维护性