需求规格说明书
2018年7月
编制
文档修改历史
序号 1 2 3 4 版本修改记录 创建版本 版本 V1.0 修改人 刘友兵 修改时间
公司地址： 邮编
1. 引言 ................................................................. 5
1.1. 1.2. 1.3.
编写目的 ..................................................... 5 术语介绍 ..................................................... 5 参考文献 ..................................................... 5
2. 项目概述 ............................................................. 6
2.1. 2.2. 2.3. 2.4.
背景（现状） ................................................. 6 项目简介 ..................................................... 6 项目目标 ..................................................... 6 标准与规范 ................................................... 6
引用的标准与规范 ..................................... 6 拟定的标准与规范 ..................................... 7
2.4.1. 2.4.2.
3. 系统功能与特点 ....................................................... 7
3.1. 3.2. 3.3. 3.4.
系统功能 ..................................................... 7 系统特点 ..................................................... 8 面向的用户群体及特点 ......................................... 8 相关假设、依赖与限制条件 ..................................... 8
4. 系统架构 ............................................................. 8
4.1. 4.2. 4.3.
系统架构图 ................................................... 8 业务流程图 ................................................... 8 网络拓扑图 ................................................... 8
5. 项目范围 ............................................................. 9 6. 需求中的角色 ......................................................... 9 7. 系统需求 ............................................................ 10
7.1.
功能性需求 .................................................. 10
功能点一 ............................................ 10 公共功能 ............................................ 10
7.1.1. 7.1.5. 7.2.
非功能性需求 ................................................ 11
界面要求 ............................................ 11 软硬件环境要求 ...................................... 14 产品质量要求 ........................................ 14 安全需求 ............................................ 15
7.2.1. 7.2.2. 7.2.3. 7.2.4.
7.2.5. 7.3.
性能需求 ............................................ 16
数据字典 .................................................... 18
系统参数 ............................................ 18
7.3.1. 7.4.
接口 ........................................................ 19
软件接口 ............................................ 19 硬件接口 ............................................ 19 通信接口 ............................................ 19
7.4.1. 7.4.2. 7.4.3.
8. 进度计划 ............................................................ 19 9. 验收标准 ............................................................ 19 10.
附录A：需求建模与分析报告 ...................................... 20 10.1. A.1 1需求模型 .............................................. 20
11. 附录B：需求确认 ................................................ 21
1. 引言
1.1. 编写目的
1.2. 术语介绍
术语名称 解释 1.3. 参考文献
文献名称
文献说明
2. 项目概述
2.1. 背景（现状）
2.2. 项目简介
2.3. 项目目标
2.4. 标准与规范
提示：阐述本产品应当遵循什么标准、规范或业务规则（Business Rules），违反标准、规范或业务规则的产品通常不太可能被接受。 2.4.1. 序号 1 2 3 引用的标准与规范 引用位置 标准名称
2.4.2. 序号 1 2 3
拟定的标准与规范 引用位置 标准名称 3. 系统功能与特点
3.1. 系统功能
系统名称 功能名称
优先级 功能描述
3.2. 系统特点
3.3. 面向的用户群体及特点
提示： （1）描述本产品面向的用户（客户、最终用户）的特征， （2）说明本产品将给他们带来什么好处？他们选择本产品的可能性有多大？
3.4. 相关假设、依赖与限制条件
4. 系统架构
4.1. 系统架构图
4.2. 业务流程图
4.3. 网络拓扑图
5. 项目范围
提示：阐述本产品“适用的领域”和“不适用的领域”，本产品“应当包含的内容”和“不包含的内容”。说清楚产品范围的好处是：（1）有助于判断什么是需求，什么不是需求；（2）可以将开发精力集中在产品范围之内，少干吃力不讨好的事情；（3）有助于控制需求的变更。 6. 需求中的角色
提示：阐述本产品的各种角色及其职责。各种角色的具体行为将在功能性需求中描述。 角色名称
职责描述
7. 系统需求
7.1. 功能性需求 7.1.1. 7.1.2.
功能点一 功能概述
7.1.3.
业务流程
7.1.4.
功能要求
7.1.5. 公共功能
7.1.5.1. 公共界面
7.1.5.2. 消息提示
7.2. 非功能性需求 7.2.1.
界面要求
1. 一致性
坚持以用户体验为中心设计原则，界面直观、简洁，操作方便快捷，用户接触软件后对界面上对应的功能一目了然、不需要太多培训就可以方便使用本应用系统。 字体
保持字体及颜色一致，避免一套主题出现多个字体； 不可修改的字段，统一用灰色文字显示。 对齐
保持页面内元素对齐方式的一致，如无特殊情况应避免同一页面出现多种数据对齐方式。 表单录入
在包含必须与选填的页面中，必须在必填项旁边给出醒目标识（*）；
各类型数据输入需限制文本类型，并做格式校验如电话号码输入只允许输入数字、邮箱地址需要包含“@”等，在用户输入有误时给出明确提示。 鼠标手势
可点击的按钮、链接需要切换鼠标手势至手型；
保持功能及内容描述一致
避免同一功能描述使用多个词汇，如编辑和修改，新增和增加，删除和清除混用等。建议在项目开发阶段建立一个产品词典，包括产品中常用术语及描述，设计或开发人员严格按照产品词典中的术语词汇来展示文字信息。 2. 准确性
使用一致的标记、标准缩写和颜色，显示信息的含义应该非常明确，用户不必再参考其它信息源。
显示有意义的出错信息，而不是单纯的程序错误代码。 避免使用文本输入框来放置不可编辑的文字内容，不要文本将输入框当成标签使用。 使用缩进和文本来辅助理解。
使用用户语言词汇，而不是单纯的专业计算机术语。 高效地使用显示器的显示空间，但要避免空间过于拥挤。 保持语言的一致性，如“确定”对应“取消”,“是”对应“否”。 3. 布局
在进行UI设计时需要充分考虑布局的合理化问题，遵循用户从上而下，自左向右浏览、操作习惯，避免常用业务功能按键排列过于分散，以造成用户鼠标移动距离过长的弊端。多做“减法”运算，将
不常用的功能区块隐藏，以保持界面的简洁，使用户专注于主要业务操作流程，有利于提高软件的易用性及可用性。 菜单
保持菜单简洁性及分类的准确性。 按钮
确认操作按钮放置左边，取消或关闭按钮放置于右边。 功能
未完成功能必须隐藏处理，不要置于页面内容中，以免引起误会。 排版
所有文字内容排版避免贴边显示（页面边缘），尽量保持10-20像素的间距并在垂直方向上居中对齐；各控件元素间也保持至少10像素以上的间距，并确保控件元素不紧贴于页面边沿。 表格数据列表
字符型数据保持左对齐，数值型右对齐（方便阅读对比），并根据字段要求，统一显示小数位位数。 滚动条
页面布局设计时应避免出现横向滚动条。 页面导航（面包屑导航）
在页面显眼位置应该出现面包屑导航栏，让用户知道当前所在页面的位置，并明确导航结构。
信息提示窗口
信息提示窗口应位于当前页面的居中位置，并适当弱化背景层以减少信息干扰，让用户把注意力集中在当前的信息提示窗口。一般做法是在信息提示窗口的背面加一个半透明颜色填充的遮罩层 7.2.2.
需求名称 软硬件环境要求
详细要求 7.2.3.
主要质量属性 产品质量要求
详细要求 正确性 健壮性 可靠性 易用性 清晰性 安全性 可扩展性 兼容性 可移植性 …
7.2.4. 安全需求
7.2.4.1. 应用安全
7.2.4.2. 数据安全
7.2.4.3. 主机安全
7.2.4.4. 网络安全
7.2.4.5. 终端安全
7.2.4.6. 密钥管理
7.2.4.7. 客户（用户）信息认证与保密
7.2.5. 性能需求
指标 说明 磁盘主要用于存取数据，因此当说到IO操作的时候，就会存在两种相对应的操作，存数据的时候对磁盘I/O 应的是写IO操作，取数据的时候对应的是是读IO操作，一般使用% Disk Time（磁盘用于读写操作所占用的时间百分比）度量磁盘读写性能 内存利用率=（1-空闲内存/总内存大小）*100%，一指标大类 指标小类 资源使 用率 内存使用率 般至少有10%可用内存，内存使用率可接受上限为85% CPU占用 率 用户进程与系统进程消耗的CPU时间百分比，长时间情况下，一般可接受上限不超过85% 一般使用计数器Bytes Total/sec来度量，Bytes Total/sec表示为发送和接收字节的速率，包括帧字带宽 符在内。判断网络连接速度是否是瓶颈，可以用该计数器的值和目前网络的带宽比较 并发用户 某一物理时刻同时向系统提交请求的用户数 某段时间内访问系统的用户数，这些用户并不一定并发处理 在线用户 同时向系统提交请求 接口并发 某一物理时刻同时向系统接口提交的请求数
指单位时间内系统处理用户的请求数。从业务角度看，吞吐量可以用：请求数/秒、页面数/秒、人数/吞吐量 天或处理业务数/小时等单位来衡量从网络角度看，吞吐量可以用：字节/秒来衡量 系统处理事务的响应时间的平均值。事务的响应时间是从客户端提交访问请求到客户端接收到服务器响应所消耗的时间。对于系统快速响应类页面，一般响应时间为3秒左右。 服务端响应时间：服务器完成交易请求执行的时间，不包括客户端到服务器端的反应（请求和耗费在网络上的通信时间），这个服务器端响应时间平均响应时响应时间 间 网络响应时间：网络硬件传输交易请求和交易结果所耗费的时间 客户端响应时间：客户端在构建请求和展现交易结果时所耗费的时间，对于普通的瘦客户端Web应用来说，这个时间很短，通常可以忽略不计；但是对于胖客户端Web应用来说，比如Java applet、AJAX，由于客户端内嵌了大量的逻辑处理，耗费的时间有可能很长，从而成为系统的瓶颈，这是要注可以度量服务器的处理能力。
意的一个地方。那么客户感受的响应时间其实是等于客户端响应时间+服务器端响应时间+网络响应时间。细分的目的是为了方便定位性能瓶颈出现在哪个节点上 事务成功率 稳定性 超时错误率 占总事务的比率 单位时间内系统可以成功完成多少个定义的事务 主要指事务由于超时或系统内部其它错误导致失败其它
根据实际的系统要求可增加 7.3. 数据字典 7.3.1.
编码
系统参数
类型名称 说明
7.4. 接口
7.4.1.
软件接口
7.4.2.
硬件接口
7.4.3.
通信接口
8. 进度计划
9. 验收标准
10. 附录A：需求建模与分析报告
10.1. A.1 1需求模型
提示：需求模型就是采用文字、图形化、表格化、公式化的方式，按照系统需求情况对系统进行可视化描述，提供一种详细说明系统的结构或行为的方法。需求模型就是需求分析的成果物。
11. 附录B：需求确认 提示：需求确认规程主要分两步：（1）需求评审，（2）需求承诺。对需求的评审应当采用“正式技术评审方式”，将产生一份“需求评审报告”，在获取责任人（Stakeholders）对需求的承诺之前，该《产品需求规格说明书》必须先通过需求评审。 需求评审报告摘要 需求文档 需求评审报告 评审结论 输入名称，标识符，版本，作者，完成日期，… 输入名称，标识符，评审日期，… [ ] 工作成果合格，“无需修改”或者“需要轻微修改但不必再审核”。 [√] 工作成果基本合格，需要作少量的修改，之后通过审核即可。 [ ] 工作成果不合格，需要作比较大的修改，之后必须重新对其评审。 评审意见 评审小组成员 输入评审小组成员 需求承诺 需求文档 输入名称，标识符，版本，作者，完成日期 客户承诺 承诺…
签字，日期 项目经理承诺 承诺… 签字，日期
因篇幅问题不能全部显示，请点此查看更多更全内容