需求规格说明书.docx

需求规格说明书.docx

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

需求规格说明书

需求规格说明书

版本历史记录

日期

版本号

版本内容

作者

审核人

审核日期

目录

1.项目概述4

1.1编写目的4

1.2项目背景4

1.3项目范围4

1.4参考文档4

1.5术语与缩写解释4

2.项目使用的用户对象及角色划分4

3.业务模型5

3.1业务用例图5

3.2业务用例16

3.3业务用例n7

4.功能性需求7

4.1系统用例模型7

4.2系统用例7

4.2.1系统用例17

4.2.2系统用例n8

4.3补充约束8

4.3.1字段列表8

4.3.2业务规则8

5.非功能性需求9

5.1用户界面需求9

5.2和其它系统的接口需求9

5.3软硬件环境需求9

5.4产品质量需求9

6.分析模型<仅针对新系统>10

6.1实体模型10

6.2系统用例序列图11

6.2.1用例111

6.2.2用例n13

7.随附模型13

8.版本变更记录13

1.项目概述

编写目的

项目背景

填写待开发系统的以下信息（按版本描述）：

用户

项目起因

说明目前的状态和商业环境、为什么要上该项目

要解决的问题

版本号

说明要解决的问题、实现的目标、用途

影响范围

工期要求

项目范围

提示：

阐述本项目“适用的领域”和“不适用的领域”，“应当包含的内容”和“不包含的内容”。

版本号

项目范围

参考文档

提示：

列出本文档的所有参考文献（可以是非正式出版物）。

格式如下：

文件编号

文献名称

作者

出版单位

发行日期

术语与缩写解释

缩写、术语

解释

SPP

精简并行过程，SimplifiedParallelProcess

SD

系统设计，SystemDesign

2.项目使用的用户对象及角色划分

提示：

（1）描述本项目面向的用户（客户、最终用户）的特征。

（2）阐述本项目的各种角色及其职责。

各种角色的具体行为将在功能性需求中描述。

（3）用户组织结构图。

角色名称

职责描述

对应部门

对应职位

备注

3.业务模型

业务用例图

业务用例1

提示：

可以使用序列图来描述，必要时需要添加文字说明

业务用例n

4.功能性需求

系统用例模型

提示：

使用用例图来描述

系统用例

系统用例1

提示：

使用用例需求分析法进行需求的描述（标*的为必填项）。

用例名称*

需求编号*

主执行人*

涉众利益*

识别出用例所有涉众，并详细描述涉众的利益

前置条件*

用例的前置条件（precondition）声明了启动该用例之前系统必须满足的条件。

通常，前置条件是指该条件已经通过其他用例的执行进行了设置:

最简单的例子，在论坛里发贴子用例的前置条件是用户已经登录。

后置条件

最小保证*

最小保证是系统向项目相关人员作出的最低承诺，尤其是在主执行者的目标不能被满足的情况下。

在目标遭遇失败的情况下，项目相关人员认可他们的利益得到了保护，这是最小保证是否成功/失败的测试标准。

如“系统将执行情况记入日志”。

成功保证*

成功保证（successguarantee）说明了用例成功结束后项目相关人员的哪些利益得到了满足，用例可以通过执行主场景获得成功，也可以通过执行可选路径获得成功。

成功保证通常作为最小保证的添加内容：

最小保证被满足以后，并且一些附加条件为真；附加条件中至少包括用例标题中声明的目标。

找到成功保证的最好方法是问这样一个问题：

“在用例结束时，什么事会使项目相关人员感到不高兴？

”这个问题通常很容易回答，然后写出答案的反面回答。

触发事件*

触发事件（trigger）指明了启动用例的条件；有时触发事件就是用例中的第一部操作。

基本路径*

扩展路径*

字段列表

业务规则

非功能性需求

包括可用性，可靠性，性能，可支持性，注意必须是可以度量的

设计约束

常见的设计约束有：

界面设计约束、软硬件环境约束等

备注：

<其它说明信息>

系统用例n

……

补充约束

提示：

此处描述通用的业务规则和字段列表

字段列表

业务规则

5.非功能性需求

用户界面需求

需求名称

详细要求

主界面图示

界面布局说明

操作说明

和其它系统的接口需求

需求名称

详细要求

软硬件环境需求

需求名称

详细要求

产品质量需求

提示：

填写需求要求达到的的质量属性，即达到什么标准或满足什么指标。

主要质量属性

详细要求

正确性

正确性是指软件按照需求正确执行任务的能力。

正确的软件具备且仅具备软件“规格说明”中所列举的全部功能，能够在预期的环境下完成规定的工作。

健壮性

健壮性是指在异常情况下，软件能够正常运行的能力。

健壮性包含有两层含义：

一是容错能力，二是恢复能力。

系统万一遇到意外时能按照某种预定的方式作出适当处理,有异常的处理机制，从而避免出现灾难性的后果。

用户要求可不间断稳定运行的时间；具有良好的环境适应性，同时具有良好的抗变异能力，可支持并发用户的数量等。

可靠性

可靠性是指在一定的环境下，在给定的时间内，系统不发生故障的概率。

可靠的软件在正常情况下能够正常工作，在意外情况下亦能适当地处理以使软件故障可能导致的损失最小。

在用户导致系统中断或因系统本身而中断时，系统可以很容易地通过工具和诊断恢复到以前的已知状态，而且不会丢失数据。

系统可以按预期或承诺方式运行。

具体体现在三个方面：

①无缺陷性（测试覆盖--测量测试覆盖度，审查覆盖--计算已做过的代码审查模块）；②容错性（数据完整性---统计用户数据被破坏情况，数据恢复---测量恢复被破坏的数据的能力-时间）；③可用性（软件可用的百分比---软件可用时间除以总的软件使用时间）。

可用性

a．软件在投入使用时能实现其指定的系统功能的概率。

b．系统正常工作时间和总的运行时间之比。

c．在运行时，某一配置项实现指定功能的能力。

具体体现在以下四个方面:

①易理解性---新用户学习软件特性所花费的时间（比如30分钟）；②易学性------新用户学会操作软件提供的基本功能所花费的时间；③④易操作性和沟通性--新用户基于人类工程学对软件消极方面的评价数量。

性能，效率

性能通常是指软件的“时间-空间”效率，而不仅是指软件的运行速度。

包括执行效率和存取效率。

人们总希望软件的运行速度高些，并且占用资源少些。

可以通过优化数据结构、算法和代码来提高软件的性能。

易用性

易用性是指用户使用软件的容易程度。

包括安装和操作等方面。

通常要求：

界面友好、方便易用。

安全性

安全性是指信息安全，安全性是指防止系统被非法入侵的能力，既属于技术问题又属于管理问题。

描述保证安全性的方案或措施。

数据安全性,统计用户数据被破坏的情况；用户安全性,没有被阻止的非法用户入侵数。

可扩展性

可扩展性反映软件适应“变化”的能力。

兼容性

兼容性是指不同产品（或者新老产品）相互交换信息的能力。

环境变化软件安装后必须修改的环境变量数量。

可移植性

可移植性指的是软件不经修改或稍加修改就可以运行于不同软硬件环境（CPU、OS和编译器）的能力，主要体现为硬件独立性、软件独立性、可安装性（比如30分钟内安装完毕，有安装指南）、可重用性（计算能够或已经应用于其他软件系统的模块数量）

标准

软件符合相关标准

6.分析模型<仅针对新系统>

提示：

识别出业务实体类，并绘制系统序列图。

实体模型

如下图：

系统用例序列图

用例1

如下图：

用例n

7.随附模型

提示：

请将EA模型嵌入此处

8.版本变更记录

版本号

变更描述