资源描述
项目名称
用户需求说明书
文档修改摘要
日期
版本号
修订说明
修订人
审核人
同意人
目 录
1 文档介绍 4
1.1 文档目标 4
1.2 范围 4
1.3 名词定义 4
1.4 参考文件 4
2 系统概述 5
2.1 系统介绍 5
2.2 系统目标 5
2.3 系统范围 5
2.4 系统面向用户群体 5
2.5 遵照标准和规范 5
3 功效需求 6
3.1 系统总体功效 6
3.2 功效需求1 6
3.3 功效需求2 6
4 非功效需求 7
4.1 用户界面需求 7
4.2 软硬件环境需求 7
4.3 接口需求 7
4.4 性能需求 7
4.5 品质需求。 7
4.6 安全和保密需求 8
4.7 扩展性需求 8
4.8 其它需求 8
5 需求优先级 9
6 附录 10
1 文档介绍
本章将简明地说明用户需求说明书(以下简称本说明书)目标、范围、读者对象、名词定义和参考文件
1.1 文档目标
本说明书目标在于说明XXXXXX系统(以下简称本系统)用户需求。
本说明书为编制其它相关文件提供基础依据。
本说明书搜集和整理了用户需求,并提供作为和用户讨论和确定需求依据。
1.2 范围
本用户需求说明书内容涵盖了用户提出业务、非功效需求等。
本说明书阅读、使用者包含:
项目管理人员
软件设计人员
编程人员
软件测试人员
软件质量控制人员
软件维护人员
用户代表(需求方、需求部门主管)
1.3 名词定义
提醒:正确地解释本说明书所包含字头词和缩写词
1.4 参考文件
标题
文件号
公布日期
出版单位
2 系统概述
提醒:本章将简明地进行本系统介绍、说明系统目标、范围、面向群体和标准规范。
2.1 系统介绍
提醒:系统介绍关键说明系统特征、用途、背景等。
2.2 系统目标
提醒:说明本系统所要达成目标。
2.3 系统范围
提醒:(简单描述)说明本系统所涵盖范围,比如:
l 业务范围
l 组织范围
l 功效范围
本子章节应提供软件所实现功效一个概要描述。比如,对一个财务软件SRS,我们应在此部分说明用户帐户维护,用户申明和发票准备等功效,对每个功效进行大量细节说明放在功效需求或非功效需处说明。
2.4 系统面向用户群体
提醒:描述本系统面向用户(用户、最终用户)特征,说明产品对她们用处,带来利益等。
2.5 遵照标准和规范
提醒:描述本系统遵照标准和规范。
3 功效需求
3.1 系统总体功效
功效类别
子功效
编号
提醒:对需求调研取得用户需求进行分类。
3.2 功效需求1
提醒:具体描述需求调研取得用户功效需求1
3.3 功效需求2
提醒:具体描述需求调研取得用户功效需求2
4 非功效需求
4.1 用户界面需求
提醒:对于用户界面需求进行描述,可包含风格、布局、色调、图片、控件、提醒等方面需求。
4.2 软硬件环境需求
提醒:用户提出软硬件环境需求。
4.3 接口需求
提醒:需求调研中获知系统和其它系统需要接口。
4.4 性能需求
提醒:描述系统性能需求。如
u 对事务响应时间(平均、最长);
u 吞吐量,比如每秒处理事务数;
u 容量,比如系统能够容纳用户或事务数;
u 负载,系统负载能力,并发数等;
u 资源利用情况,如内存、磁盘、通信等。
4.5 品质需求。
提醒:应明确说明软件品质需求各属性,方便能客观地验证其达成情况。属性包含:
l 可靠性
说明为了达成整个系统可靠性需求,而对软件提出可靠性需求。下面这段话就是一个简单例子:‘本软件须被测试完全,以避免任何数据储存及运算可能发生错误。’
l 可维护性
说明为了达成整个系统可维护性需求,而对软件提出可维护性需求。比如:
l 可用性
说明为了使整个系统达成指定可用性水准,而对软件提出可用性需求。比如:检验点、恢复、重新开启等。下面这段话就是一个简单例子:
‘为了确保系统可用性,软件必需采取检验点、恢复、重开启机制。在每日9小时、每七天七日操作情况下,本软件之可用性应在99.5%以上。’
l 可移植性
若有可移植性要求,即要求软件能方便地从一个环境转移到另一个环境,那么应该在此明确指出,并指明转移之程序,和界面限制等。
l 其它
4.6 安全和保密需求
1) 安全
说明为预防可能发生人员、财物或实体环境伤害而对软件设计提出安全需求。比如:
l 经过提供数据备份和恢复功效,来确保数据文件安全(当系统中数据文件遭到破坏时,能够把备份数据读入系统,使系统能够继续运行)。
l 经过数据库管理软件提供各式数据备份/恢复功效,来确保数据库/表安全。
2) 保密
说明保护系统免遭意外或恶意存取、使用、修改、破坏或泄密需求。包含:
l 利用某种密码技术;
l 设置专门日志或历史数据集;
l 给不一样模块分配不一样功效;
l 对一个程序中各部分之间通讯实施限制;
l 对关键量实施“检验和”校验等等。
4.7 扩展性需求
4.8 其它需求
5 需求优先级
需求优先级定义为三个等级:强制、可协商、理想,定义需求优先级时还要考虑模块关联性、技术难易程度等,每个需求对应优先级定义详见【需求跟踪矩阵】,具体个优先级应对策略以下表所表示:
需求优先级
应对策略
强制
需求是必需做
可协商
需求是选择性做
理想
需求是有时间和资源就做
6 附录
可附需求访谈统计表、用户调研会议纪要、调研汇报等。
展开阅读全文