需求规格说明书.docVIP

- . z. **银行**系统 需求规格说明书 - . z. 文档信息及版本历史 版本 作者/修改者 日期 描述 - . z. 概述 编写目的 适用范围 术语和缩写 术语和缩写 解释 参考资料 列述参考资料 工程综述 {提示：概述正在定义的工程、使用工程的用户以及的限制、假设和依赖。} 工程介绍 此处介绍工程主要情况 工程面向的用户 {提示： 对工程面向的用户或用户群体进展简要说明，可以从下面两个方面考虑： 〔1〕描述本工程面向的用户〔客户、最终用户〕或用户群体的介绍。 〔2〕用户或用户群的特征、需求、业务机遇、正待解决的业务问题，包括对现存产品或工程的一个简要的评价。} 工程应当遵循的标准或标准 提示： 〔1〕描述本工程应当遵循的标准或标准；例如**系统业务标准和根据公司过程资产库裁剪的工程自定义过程标准，公司java编码标准等} 主要特征 {提示： 简要描述工程提供的主要特征。可以从以下几个方面考虑： 指明所开发的工程怎样满足用户或用户群体的需求，解决哪些用户关心的业务需求。 可以说明所开发的工程为什么具有吸引力和它所能带来的好处、竞争优势、重要商业利润、提供应客户的价值。} 工程范围 {提示： 阐述所开发的工程的系统范围，主要描述应当包含的内容〞和不包含的内容〞。说明清楚工程范围的好处是： 有助于判断什么是需求，什么不是需求。 可以将开发精力集中在系统范围内。 有助于控制需求的变更。 有助于最终评估和验收。} 工程中的角色 {提示： 阐述本工程操作过程中涉及的各种角色及其职责。各种角色的具体行为将在功能性需求中描述。} 角色名称 职责描述 功能性需求 功能性需求分类 {提示： 用M*代表模块，C*代表子模块，需求规格说明书第一次评审前，用F_*代表功能点，后续的变更或新增分别用CR_*和NF_*。其中*为序列号1、2、3……优先级请用P1、P2、P3、P4四层表示，P1代表最优先解决，优先级最少要有P1级的。} . 一级模块 二级模块 功能点编号及名称 优先级 M1_日常工作管理 M1_C1合理化建议流程 F_1提出建议 F_2区支撑审核 P1 F_3工会主席处理 P2 M1_C2营业条线疑难问题上报 F_4提出问题 P1 F_5综合部处理 P2 F_6问题解答 P2 F_7回复确认 P1 M1_C3每日情况流程 F_8厅经理起草 F_9区支撑审核 F_10综合部文秘审核 模块一 子模块一 {提示： 此处写一些承上启下的文字，阐述每一功能的详细需求。} 功能一 输入要素描述 a.输入画面设计 {提示：必要的输入画面说明以及处理画面说明} b.输入字段定义 字段名 类型 数据种类 是否必输 长度 范围(精度〕 输入限制 〔或数据字典〕 说明 字符 是 全部、已确认、已整改未确认、未整改 {类型：输入的方式，如单项选择项、多项选择项、系统自动产生，手工输入；数据种类：如字符、日期、数字等；输入限制：数据合法性校验限制} c.输入字段间的约束关系 功能描述 功能点编号 F_1 功能名 功能描述 优先级 使用角色 运行条件 业务处理流程 补充说明 输出要素描述 输出画面设计 {提示：必要的输出画面说明} b.输出字段定义 字段名 类型 数据种类 是否可选 长度 范围(精度〕 说明 字符 是 {类型：输出的方式，如系统自动产生；数据种类：如字符、日期、数字等} 接口需求 {提示:说明该工程同其他软件之间的接口、数据通信协议等。} 错误代码对照表 错误代码 错误代码描述 使用场景说明 非功能性需求 用户界面需求 {提示： 如果用户没有提出界面需求，则用户界面需求可以不写； 用户的界面需求有：界面的LOGO、界面的色彩基调、界面的布局、图片信息、文字信息、与现有*个系统的风格保持统一等等； 对于那些做了界面原型的工程，建议可以直接参见界面原型，但是界面原型需要放在工程配置库的目录中；} 需求名称 详细要求 … 软件环境需求 需求名称 详细要求 操作系统 JDK版本 中间件 数据库 … 硬件环境需求 需求名称 数量 每台需要存储空间 详细要求 产品质量需求 主要质量属性 详细要求 正确性 可靠性 性能 易用性 平安性 可扩展性 兼容性 可移植性 … 故障处理 {提示:为系统提供解决故障的处理手段，如：记录错误日志、错误提示、获取系统错误代码等。} 故障描述 详细要求 效劳器故障 系统运行故障 用户操作不正确 … 附件 {提示：本需求规格说明书的附件，如场景图等} 其他补充信息 {提示：外包公司需补充的其他设计说明} 相关责任方确认 {提示：信息科技部根据工程实际情况，对需核实的内容进展