软件缺陷管理系统需求与设计Word格式.docx

软件缺陷管理系统需求与设计Word格式.docx

《软件缺陷管理系统需求与设计Word格式.docx》由会员分享，可在线阅读，更多相关《软件缺陷管理系统需求与设计Word格式.docx（14页珍藏版）》请在冰豆网上搜索。

本软件产品运行在装有java运行环境的任何操作系统上运行。

1.4Softwarefunction软件功能

功能模块

用例

一.Bug管理

1.Bug管理

2.分配给我的bug

3.我创建的bug

4.Bug查询

二.项目管理

1.项目管理

2.用户组管理

3.版本管理

4.查询统计

三.用例管理

1.测试用例管理

2.测试计划管理

3.用例测试结果管理

四.系统管理

1.用户管理

2.权限管理

3.测试类别管理

4.Bug级别管理

表格1软件功能表

1.5Actors

Actor为软件研发的项目经理，开发人员和测试人员

2FunctionalRequirements功能需求

2.1UseCaseDiagram系统总用例图

2.2系统活动图

2.3系统子用例图

2.3.1Project.Module01.Function01bug管理-bug管理

2.3.1.1GoalinContext简要说明

检索与维护所有项目的BUG的状态信息，BUG一共由8种状态。

状态1：

已提交：

测试员发现BUG后提交到BUG管理系统中的状态。

（初始状态）

状态2：

已修改：

程序员在修改了BUG后提交到BUG管理系统中的状态。

状态3：

不修改：

程序员或项目经理根据需求分析、概要设计、详细设计说明书等上的要求经过考虑后决定对BUG不进行修改。

其BUG的状态为不修改，需要说明理由。

状态4：

延迟：

根据目前项目进程或计划等情况，暂时延期的状态

状态5：

待讨论：

需要进行讨论后才能决定是否需要修改的BUG的状态。

状态6：

已验证：

已经解决的并经过测试员复测的BUG的状态。

状态7：

关闭：

完全解决了，只供以后备查的状态

状态8：

重新打开：

重新出现在新的版本中，重新打开以前关闭的bug状态。

2.3.1.2Preconditions前置条件

无

2.3.1.3EndCondition后置条件

2.3.1.4Actors

所有人员。

2.3.1.5Trigger触发条件

2.3.2Project.Module01.Function02bug管理-分配给我的bug

2.3.2.1GoalinContext简要说明

测试人员对对象软件进行测试发现了bug后分配给开发人员。

2.3.2.2Preconditions前置条件

测试人员发现了bug。

2.3.2.3EndCondition后置条件

获取bug信息。

2.3.2.4Actors

开发人员。

2.3.2.5Trigger触发条件

2.3.3Project.Module01.Function03bug管理-我创建的bug

2.3.3.1GoalinContext简要说明

根据测试人员给开发人员提供的bug信息创建一个处理这个bug的功能模块。

2.3.3.2Preconditions前置条件

获取bug信息。

2.3.3.3EndCondition后置条件

处理好这个bug以后，将信息交给测试人员。

2.3.3.4Actors

开发人员。

2.3.3.5Trigger触发条件

2.3.4Project.Module01.Function04bug管理-bug查询

2.3.4.1GoalinContext简要说明

查询bug信息的一个功能模块。

2.3.4.2Preconditions前置条件

无。

2.3.4.3EndCondition后置条件

无。

2.3.4.4Actors

所有用例。

2.3.4.5Trigger触发条件

2.3.5Project.Module02.Function01项目管理-项目管理

2.3.5.1GoalinContext简要说明

根据需求，实际情况，创建项目。

2.3.5.2Preconditions前置条件

了解需求，条件允许

2.3.5.3EndCondition后置条件

创建用户组

2.3.5.4Actors

项目经理

2.3.5.5Trigger触发条件

无

2.3.6Project.Module02.Function03项目管理-用户组管理

2.3.6.1GoalinContext简要说明

根据项目需求，选择合适人员，组成项目组

2.3.6.2Preconditions前置条件

项目已经建立

2.3.6.3EndCondition后置条件

制定项目计划

2.3.6.4Actors

2.3.6.5Trigger触发条件

该项目已经立项，项目计划已经建立

2.3.7Project.Module02.Function03项目管理-版本管理

2.3.7.1GoalinContext简要说明

对每一次出现bug并修改后的被测项目的版本进行修改。

2.3.7.2Preconditions前置条件

开发员对当前bug修改完成。

2.3.7.3EndCondition后置条件

修改被测项目的版本。

2.3.7.4Actors

项目经理。

2.3.7.5Trigger触发条件

当前Bug修改完成。

2.3.8Project.Module02.Function04项目管理-查询统计

2.3.8.1GoalinContext简要说明

查询反馈信息中已关闭的bug数量，来得到被测试项目某阶段解决bug的程度。

根据bug的解决程度用来控制被测项目的进度。

2.3.8.2Preconditions前置条件

2.3.8.3EndCondition后置条件

统计已关闭bug的数量。

2.3.8.4Actors

2.3.8.5Trigger触发条件

反馈信息确定。

2.3.9Project.Module03.Function01用例管理-测试计划管理

2.3.9.1GoalinContext简要说明

管理所有的测试计划，并可以添加、删除、修改、查询测试计划。

2.3.9.2Preconditions前置条件

制定项目计划。

2.3.9.3EndCondition后置条件

编写测试用例。

2.3.9.4Actors

软件测试人员。

2.3.9.5Trigger触发条件

项目计划的制定。

2.3.10Project.Module03.Function02用例管理-测试用例管理

2.3.10.1GoalinContext简要说明

用来管理测试用例：

可以对测试用例进行添加、删除、修改、查询。

2.3.10.2Preconditions前置条件

编写测试计划。

2.3.10.3EndCondition后置条件

管理所有bug。

2.3.10.4Actors

软件测试人员

2.3.10.5Trigger触发条件

测试计划的编写。

2.3.11Project.Module03.Function03用例管理-用例测试结果管理

2.3.11.1GoalinContext简要说明

在使用测试用例进行测试的时候要求测试用例应该包含5种状态，

未测试，说明还没有开始测试。

测试通过：

测试用例通过测试。

测试不通过：

测试用例没有通过。

测试阻塞：

阻塞表示该测试用例的前置条件还未符合，所以该用例测试没有办法开始进行。

测试取消：

取消表示如果测试用例与实际软件实现不想符合，那么测试用例不能按照实际情况测试，那么测试用例取消。

2.3.11.2Preconditions前置条件

2.3.11.3EndCondition后置条件

2.3.11.4Actors

2.3.11.5Trigger触发条件

当测试人员需要管理用例测试结果的时候

2.3.12Project.Module04.Function01系统管理-用户管理

2.3.12.1GoalinContext简要说明

创建系统用户

2.3.12.2Preconditions前置条件

2.3.12.3EndCondition后置条件

权限管理

2.3.12.4Actors

系统管理员

2.3.12.5Trigger触发条件

该项目已经立项

2.3.13Project.Module04.Function02系统管理-权限管理

2.3.13.1GoalinContext简要说明

对系统权限的管理

2.3.13.2Preconditions前置条件

用户创建

2.3.13.3EndCondition后置条件

2.3.13.4Actors

系统管理员

2.3.13.5Trigger触发条件

2.3.14Project.Module04.Function03系统管理-测试类别管理

2.3.14.1GoalinContext简要说明

软件测试常用的测试方法：

黑盒测试：

不基于内部设计和代码的任何知识，而是基于需求和功能性。

　白盒测试：

基于一个应用代码的内部逻辑知识，基于覆盖全部代码、分支、路径、条件。

　单元测试：

最微小规模的测试;

以测试某个功能或代码块。

　累积综合测试：

当一个新功能增加后，对应用系统所做的连续测试。

集成测试：

一个应用系统的各个部件的联合测试，以决定他们能否在一起共同工作。

部件可以是代码块、独立的应用、网络上的客户端或服务器端程序。

　　功能测试：

用于测试应用系统的功能需求的黑盒测试方法。

　　系统测试：

基于系统整体需求说明书的黑盒类测试;

应覆盖系统所有联合的部件。

2.3.14.2Preconditions前置条件

2.3.14.3EndCondition后置条件

2.3.14.4Actors

2.3.14.5Trigger触发条件

该项目已经立项

2.3.15Project.Module04.Function04系统管理-bug级别管理

2.3.15.1GoalinContext简要说明

BUG一般分为4个等级分别为

致命（可对应目前BUG体系中的“非常严重”）：

致命性问题主要为：

系统无法执行、崩溃或严重资源不足、应用模块无法启动或异常退出、无法测试、造成系统不稳定。

具体基本上可分为：

○内存泄漏

○用户数据丢失或破坏

○系统崩溃/死机/冻结

○模块无法启动或异常退出

○严重的数值计算错误

○功能设计与需求严重不符

○其它导致无法测试的错误

●严重（可对应目前BUG体系中的“严重”）

严重性问题主要为：

影响系统功能或操作，主要功能存在严重缺陷，但不会影响到系统稳定性。

○功能未实现

○功能错误

○系统刷新错误

○语音或数据通讯错误

○轻微的数值计算错误

○系统所提供的功能或服务受明显的影响

●一般（可对应于目前BUG体系中的“普通”）

一般性问题主要为：

界面、性能缺陷

○操作界面错误（包括数据窗口内列名定义、含义是否一致）

○边界条件下错误

○提示信息错误（包括未给出信息、信息提示错误等）

○长时间操作无进度提示

○系统未优化（性能问题）

○光标跳转设置不好，鼠标（光标）定位错误

●提示（可对应于目前BUG体系中的“轻微及建议”）

提示性问题主要为：

易用性及建议性问题

○界面格式等不规范

○辅助说明描述不清楚

○操作时未给用户提示

○可输入区域和只读区域没有明显的区分标志

○个别不影响产品理解的错别字

○文字排列不整齐等一些小问题

○建议

2.3.15.2Preconditions前置条件

2.3.15.3EndCondition后置条件

2.3.15.4Actors

2.3.15.5Trigger触发条件

3PerformanceRequirements性能需求

1.可以同时让30个用户同时在线操作.

2.保证系统在6个工作日内运行不能出现异常.

4OverallDesignConstraints总体设计约束

4.1Standardscompliance标准符合性

1.Java编码规范:

a）使用Tab键缩进;

b）使用驼峰标识;

c）主要方法和属性要有注释;

d）属性名小写;

e）方法名小写;

f）常量大写.

2.标准文档模板,格式:

参见所给文档模板.

4.2HardwareLimitations硬件约束

要求能运行在内存大于1G的各类PC机器上.

5SoftwareQualityAttributes软件质量特性

5.1Reliability可靠性

1.强大的及时存储能力,防止数据以外丢失.

2.经测试系统可靠性99.999%.

3.定期对系统进行维护和升级.

5.2Usability易用性

1.操作界面友好.

2.系统附带用户手册.

3.提供联机帮助.

6RequirementsClassification需求分级

RequirementID

需求ID

RequirementName

需求名称

Classification

需求分级

Project.Module01.Function01

bug管理

A

分配给我的bug

B

我创建的bug

C

bug查询

Project.Module02.Function01

项目管理

Project.Module02.Function02

用户组管理

Project.Module02.Function03

版本管理

Project.Module02.Function04

查询统计

Project.Module03.Function01

测试计划管理

Project.Module03.Function02

测试用例管理

Project.Module03.Function03

用例测试结果管理

Project.Module04.Function01

用户管理

Project.Module04.Function02

权限管理

Project.Module04.Function03

测试类别管理

Project.Module04.Function04

bug级别管理

表格2需求分级表

A.十分重要

B.重要

C.达到需求即可