需求规格说明书(样例)(共29页).doc

《需求规格说明书(样例)(共29页).doc》由会员分享，可在线阅读，更多相关《需求规格说明书(样例)(共29页).doc（29页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、精选优质文档-倾情为你奉上 需求规格说明书专心-专注-专业目 录第一章 综述若采用分册编制方式组织，则本章与第二章、第三章单独成册，其它分册可略去本章、第二章和第三章内容。1.1 编制目的用简洁的语言描述编写这个文档的目的。1.2 适用范围本文档适用的范围。1.3 参考依据列举编写软件需求规格说明时所参考的资料或其它资源。这可能包括且不限于：用户界面风格指导、合同、标准、系统需求规格说明、使用实例文档，或相关产品的软件需求规格说明。对于非易获得性或项目所专属的参考资料，应当以附件形式提供。1.4 编制约束1.4.1 图元约束（1）流程图图元约束：图形符号名 称定 义开始框标准流程的开始，每一流

2、程图只有一个起点结束框流程的中断和结束处理框表示对事件或结果的处理过程决策或判断用来根据给定的条件是否满足决定执行两条路径中的某一路径流程线箭头的方向表示流程执行的方向与顺序，两个符号间不得使用双箭头连接标识用于同一流程图中页和页的连续或者用于同页内从一个动作框转到另一个动作框流程标识表示在流程图中引用另一个流程（2）流程图展示方式约束：流程图推荐采用纵向页面布置、横向职能带布置的样式，另根据需要可增加划分业务流程阶段，但不得改变流程图基本样式。流程图中所用符号应均匀分布，连线保持合理的长度，并尽量少用长线。使用各种符号应注意符号的外形和各符号大小的统一，避免使符号变形或各符号大小比例不一。符

3、号内的说明文字尽可能简明。通常按从左向右和从上向下方式书写，并与流向无关。尽量避免流线的交叉，即使出现流线的交叉，交叉的流线之间也没有任何逻辑关系，并不对流向产生任何影响。一个大的流程可以由几个小的流程组成。单个流程过于复杂时，在不影响业务的完整性和连续性的前提下，应拆分为两个及以上子流程。所附表单能体现流程要求时，则可简化流程图，尽量将表单能体现的流程要求合并为一个流程节点。1.4.2 编码约束在信息一体化管控体系和标准化规范里面已经明确规定的，本处作为引用说明（如标准编码部分），没有明确说明的，采用以下编码约定方式：（1） 业务域编码（根据公司管理制度的划分，定为14个业务域。业务域缩写说

4、明：前面2位数字是公司管理制度所用的分类编码，后面两位英文缩写是信息系统所用业务域编码）l 10安全管理（SM-Safety Management）：包括安全综合管理、监督管理、风险管理、应急管理等。l 11生产管理（PM-Plant Maintenance）：包括运行、维护、技改修理、设备资产策略、技术监督、科技进步等。l 12调度管理（DM-Dispatch Management）：包括电力调度、运行方式、水调、技术经济、继电保护、安全自动装置、电力通信及调度自动化管理等。l 13规划建设（PP-Production Planning）: 包括电网规划、节能减排、项目前期、项目计划及管理、

5、工程管理、质量安全管理、造价管理、承建商管理等。l 14营销服务（BM-Business Management）：包括市场交易、营销策略、客户管理、业扩管理、抄核收管理、线损管理、营销稽查、用电检查、需求侧管理、计量管理、营配一体化等。l 15人力资源（HR-Human Resource）：包括组织管理、人才管理、绩效与激励、培训管理等。l 16财务管理（FI-Finance）：包括资金管理、预算管理、固定资产管理、产权管理、投资管理、成本管理、税务管理、会计核算、经营分析、经营考核、财务风险管理等。l 17物资管理（MM-Material Management）：包括物资管理策略、需求管理、

6、采购管理、仓储物流、供应商管理、品控管理等。l 18信息管理（IM-Information Management）：包括信息管理、运维管理、信息安全、信息应用等。l 19监审内控（EC-Enterprise Control）：包括法律与合同管理、纪检监察、内控审计等。l 20党群工作（CC-Corporate Culture）：包括党的建设、企业文化、青年工作、思想教育、工会管理等。l 21行政办公（OA-Office Assistant）：包括综合行政、新闻管理、后勤保障等。l 22 基础管理（BA-Basis）：战略管理、政策研究、体制改革、指标管理、制度建设、创新管理等基础性管理制度。l

7、 23 其他（OT-Other），不能划归以上分类的公司其他业务。（2） 业务类编码l 业务域编码+二位数字序号。例：营销业扩可编码：BM01（3） 流程编码（Flow）l F-业务类编码-四位数字序号。（4） 业务对象编码（Entity）l E-业务类编码-四位数字序号。（5） 表单编码（Bill）l B-业务类编码-四位数字序号。（6） 规则算法编码（Arithmetic）l A-业务类编码-四位数字序号。（7） 标准规范编码（Standard）l 标准规范采用统一编码，S-业务域编码-四位数字序号。（8） 关系编码（Relation）l 业务域与业务域R-主业务域编码-副业务域编码-2位

8、序号。l 业务类与业务类R-主业务类编码-副业务类编码-2位序号。（9） 功能项编码（Model）l 一级功能：M-业务类编码-3位序号l 二级功能：一级功能编码-3位序号。l N级功能：以此类推。1.4.3 格式约束文档模板：文档编制必须严格依据本文档模板的格式要求。（1） 引用描述格式l l ()l ()（2） 文字格式l Word样式，正文首行缩进l 首行缩进2字符，宋体，小四，1.5倍行距，段前 0，段后 0。（3） 表格格式l 列标题，Word样式，表格标题l 列标题，首行缩进 无，居中，宋体，五号，单倍行距，段前 0，段后 0。l 列标题，重复标题行l 表格正文，Word样式，表格

9、正文 居左l 表格正文，首行缩进 无，居左，宋体，五号，单倍行距，段前 0，段后 0。l 表格正文中的序号，Word样式，表格正文 居中l 表格正文中的序号，首行缩进 无，居中，宋体，五号，单倍行距，段前 0，段后 0。（4） 图格式l Word样式，图居中1.5 内容结构（可选）对文档的内容编排进思路、结构进行说明，对于复杂业务或文档内容超越300页以上的文档，建议在结构允许的情况下，分册编制，并在此处对每个分册的内容简要介绍，便于给阅读者以完整概念。1.6 导读说明为便于读者有针对性的阅读（特别针对预期读者），本部分对各章节（及存在的分册）进行索引和导读。形式建议：序号如果您是：请关注以下

10、部分：1领导层2公司业务人员3公司信息人员4项目建设人员5评审人员6第二章 项目概述2.1 项目背景对项目工作产生的背景做明晰的描述。2.2 项目范围本业务模型涉及到的业务覆盖范围和组织覆盖范围。2.3 项目目标明确描述项目建设要达到的目的、指标、功能要求等。2.4 现状描述简要阐述业务现状，以业务为主，尽量用表格或图示方式综合展现。第三章 需求总体分析根据业务发展战方向，在业务范围内对业务模型做总体规划，分解业务体系结构，建立整体业务模型视图，包括业务域、业务类、业务流程、功能项等内容。3.1 功能体系设计从业务实际出发，以功能为单元，划分合理的业务功能结构，以业务结构图表达更清晰。3.1.

11、1 功能结构3.1.1.1 功能结构图可以以树型或关系型图展现合理划分的业务功能构成的整体结构。例如关系型展如下：3.1.1.2 功能列表列出一级功能清单，为每个功能按规则编码，并清晰阐述功能主要内容。功能编码功能项名称说明3.1.2 功能分布业务功能在不同的管理层级、不同的单位所表现的侧重点及应用面。例如，可以以图示方式展示如下：也可以以表格方式说明。3.2 整体业务流程（可选）以图示的方式展示业务的整体流程，如无法归纳完整，则略过此小节，在各功能中详细阐述。整体流程一般为概念意义，例如资产管理流程：流程模型在阐述时一定要注意横向各部门、纵向各单位之间的流转关系，如果涉及，应详细说明。3.3

12、 业务标准体系在业务建模过程中，如存在根据业务情况已经或可标准化的业务信息，以树型或列表方式全面罗列。编号标准名称说明第四章 功能性需求4.1 功能综述功能需求分三级：业务类、业务流程、业务环节。l 业务类需要描述该业务系统包含的业务流程及模块；l 业务流程需要描述该流程包含的功能项；l 功能项描述具体功能点的业务需求，具体功能描述可以向下逐层细化。4.2 需求清单例表：业务类业务流程功能编码.功能项业务环节功能子项编码.功能子项名称说明业扩报装高压新装AXX0011.高压新装提交申请AXX0011-01.申请受理查勘AXX0011-02.查勘审批AXX0011-03.审批计费流程AXX001

13、2.工作流管理./查询XX查询注：对于不能归于某类和某流程的功能子项，业务类、业务流程留空。4.3 需求优先级（可选）业务类所属业务流程对应的每个功能，均要按照下面的表格提供优先级说明，以供设计、开发、测试人员参考对工作进行安排。表1 需求优先级业务类-业务流程功能编码功能项重要性(10)紧迫性(10)成本(10)难易程度(10)累计业扩报装新装AXX0011高压新装888630AXX0012低压新装777728AXX0013增容101010838说明：重要性（最高10分，最低1分）、紧迫性（最高10分，最低1分）、成本（实现成本最低时，该项得10分）、实现难易程度（最高10分，最低1分，容易

14、实现的分数高），累计最高分数的需求应优先满足。4.4 功能编码功能项例：AXX0011-01高压新装4.4.1 功能综述包括功能背景、功能目标、服务对象、场景等内容。4.4.2 业务流程以轨道图的方式清晰阐述流程全过程，明确责任节点工作内容。需求差异内容做到流程全覆盖，特殊情况和较大的差异需要加以标注和说明。流程节点功能分析：对于复杂的流程节点，采用文字说明补充。编号名称描述对应角色1查勘派工查勘环节对业务申请受理传递过来的申请进行现场勘查，指定查勘人员进行业务的处理和现场工作查勘人员2一级审批对供电方案进行审批，审批需要注意的事项：1、2、3.审批人员34.4.3 关系分析以列表的方式将每个

15、关系编号、功能项间关联关系、关系涉及到的表单、触发条件等做详细说明。4.4.3.1 内部关系（可选）以图示的方式展现业务功能内部各功能之间的关系、接口，也可用文字、表格、图表结合表达。编码关系标识说明R-PS01-PL02-01进度管理规划业务表格中不便于阐述的，可以单独设立章节，详细说明4.4.3.2 外部关系以图示的方式展现业务功能外部相关的关系、接口，也可用文字、表格、图表结合表达。编码关系标识说明R-PS01-PL02-01进度管理规划业务表格中不便于阐述的，可以单独设立章节，详细说明4.4.4 详细功能需求4.4.4.1 功能子项编码功能子项（二级）如果业务较为复杂的，可以继续分解功

16、能，内容同功能章节内容，目录级别降一级，其中没有内容的小节，可略。如果到具体的节点功能项的，以本小节格式为主。4.4.4.1.1 功能综述总体阐述功能业务情况、功能目标、应用场景和业务要求等。4.4.4.1.2 业务对象列出本功能子项涉及的业务对象。格式如下：编码业务对象说明4.4.4.1.3 业务活动及流程业务功能的活动流程图，描述关键环节和流程关系，图例如下：4.4.4.1.4 功能用例用例编号XX(一级编码)XX(二级编码)用例名称归档业务说明依据最终处理结果更新档案资料。业务规则档案变更完整的档案资料应包括：档案变更工作单BM19_BD_01；用电变更现场勘查工作单BM01_BD_07

17、；及时进行归档处理，以免对其它相关业务造成影响。档案变更的内容如果涉及到合同履行，应联系客户修订合同。档案变更的内容如果涉及到退补电量电费，应发起退补电量电费的业务。使用级别地市公司、区县公司、供电所先决条件审批已通过，且电子工作单已发送到归档环节。功能要求基本功能共计8个基本功能点查询并选定待归档的档案维护电子工作单。查询选定电子工作单的档案变更申请信息(19_001_001)、档案变更资料核实信息(19_001_002)、档案变更审批信息(19_001_003)。根据工单信息的完整性和逻辑性对工单信息的正确性进行校验，校验不通过，可以选择环节退回。根据档案变更资料核实信息(19_001_0

18、02)对相关客户档案信息进行修订，保存档案变更归档记录(19_001_004)。登记业务资料归档信息(01_099_042)。归档客户档案，发送资料归档通知到BM19_003_002档案资料管理【登记存档管理】业务项。档案变更的内容如果涉及到合同履行，启动变更合同流程。档案变更的内容如果涉及到退补电量电费，启动退补电量电费流程。辅助功能共计2个辅助功能点可查询流程记录信息(01_099_045)。可以设置工单信息校验的业务规则。提示信息对客户档案资料进行完整性校验，并提示校验结果。对违反处理约束的内容进行提示。处理约束必须输入业务资料归档信息：资料编号，资料存放位置。信息处理要求输入信息档案变

19、更申请信息(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.4.1.5 规则算法（可选）本功能所涉及到的业务规

20、范和标准，特别是信息分类与编码体系相关标准，在此处详细列出，并说明应用场景、限制原则和应用要求等。编码算法名称说明A-MM-0012专家选取算法表格中不便于阐述的，可以单独设立章节，详细说明。A-MM-0013供应商后评估算法表格中不便于阐述的，可以单独设立章节，详细说明。分项详细说明。4.4.4.1.6 界面原型界面原形可以是独立运行的文件，如果没有可独立运行的界面原型文件，则通过这一节贴界面原型图片进行设计描述和展示，所有原型制定统一的编号，有特殊的要求要予以说明备注。图XXXX-XXX如果功能用例中有原型图片编号，需要与该编号一致第五章 非功能性需求非功能需求是指软件质量属性定义中相对于

21、功能性需求的其他质量属性，包括各类软件项目实施约束，统称为软件非功能性需求，是软件产品为满足用户业务需求而必须具有且除功能需求以外的特性。软件产品的非功能性需求包括系统的性能、可靠性、安全性、可维护性、易用性、备份要求、集成要求等。5.1 软件质量属性需求5.1.1 运行期5.1.1.1 性能5.1.1.1.1 典型业务活动分析典型业务活动通常指发生频率高或者系统涉及的核心业务活动，典型业务活动的完成效率是系统质量属性的重要表现，系统分析人员应充分识别分析典型业务活动，尽可能量化业务要求，建议采用如下方式：业务活动实际使用用户数量业务发生数(笔/天、小时、秒)示例：电费发票打印10010000

22、5.1.1.1.2 关键性能指标软件系统性能需求定义，视不同的类型的应用，关键性能度量指标应有所侧重：l 交互式应用：同时在线用户数、系统响应时间、计算机资源可用率；l 后端应用：每秒完成事务数量、计算机资源可用率。软件系统性能需求定义必须是可量化的指标，建议针对不同应用类型，按如下规格定义性能需求：（1）典型交互式应用系统性能需求定义规格关键系统用例峰值时间段支持同时使用用户数系统最高响应时间（秒）计算机资源可用率示例：系统登录8:00-10:001003CPU平均使用率:75%内存使用率：70%（2）典型后端应用系统性能需求定义规格关键系统用例峰值时间段吞吐量（笔/秒）计算机资源可用率示例

23、：电费批量处理23:00-1:00100CPU平均使用率:75%内存使用率：70%示例：电费批量处理用于不同规模部署要求21:00-23:0050CPU平均使用率:75%内存使用率：70%5.1.1.2 可用性软件系统可用性主要由两项指标反映：系统可用时间和系统恢复时间，系统可用性指标应匹配业务要求。建议采用如下方式定义软件系统可用性需求：关键业务活动使用时段数据恢复目标（RPO）恢复时间目标（RTO）示例：基础架构容量趋势查询高峰时段：每天上午9:00-10:00运行维护窗口：每周六23:00-次日8:009小时恢复点目标(RPO)：是指一个企业在一次灾难(停电、病毒、自然或人为灾难)中所能

24、接受的总数据损失量。恢复时间目标(RTO)：是指企业从灾难状态中恢复联网和正常功能所需的时间。5.1.1.3 可靠性5.1.1.4 鲁棒性鲁棒性指软件系统在以下情况下仍能正常运行的能力：用户进行了非法操作；相连的软硬件系统发生了故障，以及其他非正常的情况。软件系统鲁棒性需求定义建议采用如下规格：系统功能定义要素需求内容示例： 客户账号创建客户账号创建支撑非法输入防范能力示例： 必须执行非空检查；示例： 客户邮箱、客户电话等信息必须执行合法性检查。支撑用户误操作防范能力支撑避免单点故障的能力支撑事务一致性的能力支撑系统故障防范的能力支撑系统故障及时排除的能力系统发生故障时，系统其他方面的容错能力

25、5.1.1.5 可伸缩性5.1.1.5.1 业务容量分析系统用户访问量快速增长、数据量高速增长要求软件系统具有较好的可伸缩性，因此，业务数据容量分析是定义可伸缩性需求的基础，建议采用如下方式分析业务容量需求：（1）业务容量需求预计当前系统注册用户数增长率（年增长率或月增长率）三至五年后系统注册用户数（2）业务数据容量需求业务数据项业务数据增长率（年增长率或月增长率）访问高峰系统吞吐量（笔/月、天）访问高峰系统吞吐吞吐量增长率5.1.1.5.2 需求规格需求分类定义要素需求内容纵向扩展能力支撑高访问量能力支撑大数据量能力提升计算能力要求横向扩展能力支撑高访问量能力支撑大数据量能力提升计算能力要求

26、5.1.1.6 互操作性互操作性反应软件系统的集成能力，互操作性需求定义建议采用如下方式：需求分类定义要素需求内容应用集成能力支撑业务流程管理能力支撑应用集成能力支持南方电网公司统一认证管理能力支持南方电网公司统一门户集成能力数据交换与共享能力支撑南方电网公司统一数据共享的能力支撑南方电网公司统一数据交换的能力5.1.1.7 安全性安全性需求定义规范可参考公司信息系统相关安全规范，同时对本业务系统特殊要求的安全内容予以说明。5.1.1.8 易用性软件系统易用性需求主要体现在易用性软件被理解、学习、使用和吸引用户的能力，建议采用如下方式定义易用性需求：需求分类定义要素需求内容用户界面界面风格要求

27、界面导航要求界面输入要求界面提示要求文档支持在线帮助要求离线文档要求5.1.2 非运行期5.1.2.1 可维护性软件系统可维护性需求定义建议采用如下方式：需求分类定义要素需求内容系统日志系统异常日志系统告警日志文档要求技术开发文档数据字典文档部署安装文档配置参数文档系统监控接入南网公司XX系统要求系统健康状态监控要求5.1.2.2 可移植性软件系统可移植新需求定义建议采用如下方式：需求分类定义要素需求内容技术标准技术标准要求开发技术要求运行环境支持不同操作系统要求支持不同中间件要求支持不同数据库要求5.2 约束性需求5.2.1 基础架构软件系统部署运行环境必须符合公司相关要求、规范和综合技术平

28、台的统一要求。5.2.2 标准规范软件系统设计、开发必须遵循公司相关标准和规范，包括业务标准和规范。编号标准名称说明S-MM-0012供应商分类与编码待制定表格中不便于阐述的，可以单独设立章节，详细说明。S-MM-0013物资分类与编码物资分类与编码标准体系表格中不便于阐述的，可以单独设立章节，详细说明。5.2.3 集成要求描述软件系统集成方面的要求。5.2.4 其他约束系统特有的其他约束条件。第六章 集成需求根据各业务分类与其他业务应用的关联，汇总描述系统与其他业务应用、外部系统的数据集成，应用集成，流程集成需求，举例如下：6.1 技术要求描述应用集成平台提供按照标准信息模型构建的数据、应用

29、和流程集成服务，并依据标准搭建相应的技术实现平台；描述应用集成平台提供的接口规范应包括但不局限于标准的Web Service、JMS等；描述应用集成平台提供统一的信息模型标准、统一的服务目录、服务的注册、发布和订阅机制，业务系统按照标准模型统一通过应用集成平台对外进行集成工作；描述系统支持按照国际标准信息模型（例如CIM）进行转换，并依据标准通过应用集成平台进行数据、应用和流程的集成；6.2 数据集成描述系统与其它业务系统实时性较高的数据共享需求，需要按照标准的信息模型通过应用集成平台企业服务总线进行数据共享和交换；描述系统与其它业务应用系统间非实时的批量数据共享数据需求，需要信息模型通过数据

30、中心ETL服务进行数据共享和交换。注：该部分除了文字还可以用表格形式展现集成关系序号源端目标端内容描述集成方式要求1生产系统营销系统线路负荷信息数据关联6.3 应用集成描述系统与其它业务应用系统，彼此调用功能获取信息，需要实时返回结果，通过调用应用集成平台按标准接口和模型封装的业务服务，并实时返回结果；描述系统与其它业务应用系统，彼此调用功能获取信息，需要非实时返回结果，通过应用集成平台调用按标准接口和模型封装的业务服务，非实时返回结果；描述系统与其它业务应用系统，彼此单向发送信息的，通过应用集成平台调用按标准接口和模型封装的业务服务，不需要返回结果；描述系统向多个业务应用系统发送信息，通过应

31、用集成平台调用按标准接口和模型封装的多个业务系统服务，不需要返回结果；6.4 流程集成描述涉及系统同时需要跨多个其它业务应用才能完成的业务，需要通过应用集成平台业务流程预先定义后，由应用集成平台BMP工具进行全生命周期管理；描述系统为支持跨业务的流程集成，需要通过应用集成平台提供用户、角色和权限服务，同时要可以从应用集成平台获取流程节点信息和推进状态;第七章 接口【此节规定应用程序必须支持的接口/界面。它应非常具体，包含协议、端口和逻辑地址等，以便于按照接口/界面需求开发并检验软件。】7.1 用户界面【说明软件将实现的用户界面。】7.2 硬件接口【此节指出软件所支持的所有硬件接口，其中包括逻辑结构、物理地址、预期行为等。】7.3 软件接口【此节说明软件系统中与其他构件之间的软件接口。这些构件可以是购入的构件、取自其他应用程序重新利用的构件，也可以是为此 软件需求规约 范围之外的子系统开发，但该软件应用程序必须与之交互的构件。】7.4 通信接口【说明与其他系统或设备（如局域网、远程串行设备等）的所有通信接口。】第八章 尚需解决的问题对于在需求阶段结束仍然遗留的待解决问题做归类说明。8.1 问题总表问题类别问题项说明精细管理差异8.2 问题处理逐个问题项分节阐述处理方法、处理结果或建议。附录I 业务对象业务对象清单编码业务对象说明业务对象编码业务对象名称序号数据项说明描述： 要求：