软件缺陷管理系统需求与设计

1、软件缺陷管理系统需求与设计（软件文档写作课程设计）姓名：于家鹏班级：070608学号：070603114软件缺陷管理系统需求规格与设计说明书Prepared by 拟制于家鹏Date日期2010-10-28Reviewed by 评审人Date日期Approved by 批准Date日期1 Introduction 简介1.1 Purpose 目的本文档为软件缺陷管理系统项目的需求规格说明书，规范的定义本软件项目的需求。该项目计划的阅读人员包括项目经理、项目总监以及项目组中的所有成员。1.2 Scope 范围本文档包括：软件总体概述功能需求性能需求接口需求总体设计约束软件质量特性Gen era

2、l descripti on 总体概述本项目软件需求由项目经理提供，项目组通过需求调研 （网上查阅相关资料和同类产品比较），对需求进行裁剪。1.3 Software perspective 软件概述1.3.1 About the Project 项目介绍本系统是缺陷跟踪管理的专业软件，它用于帮助公司和团队跟踪工作中的问题， 管理和记录这些问题的处理过程。通过此系统可以整合客户、开发人员、测试人员，各人各司其职， 信息很快得到交流和反馈，让大家感到软件开发在顺利快速的进行，朝意想的目标迈进。它的主要作用是为开发人员服务，实时将信息反馈给开发人员，开发人员同时迅速地将修复的结果信息反馈到跟踪系统中

3、，最后通过持续集成，软件迅速地完成了更新，这些方便、便捷的操作会极大地鼓舞软件开发中的各方人员，甚至包括客户，及时响应。1.3.2 Environment ofProduct 产品环境介绍本软件产品运行在装有java运行环境的任何操作系统上运行。1.4 Software fun ction 软件功能功能模块用例一.Bug管理1. Bug管理2.分配给我的bug3.我创建的bug4. Bug查询二.项目管理1.项目管理2.用户组管理3.版本管理4.查询统计三用例管理1.测试用例管理2.测试计划管理3.用例测试结果管理四.系统管理1.用户管理2.权限管理3.测试类别管理4. Bug级别管理表格1软

4、件功能表1.5 ActorsActor为软件研发的项目经理，开发人员和测试人员2 Functional Requirements功能需求2.1 Use Case Diagram 系统总用例图2.2系统活动图2.3系统子用例图2.3.1 Project.Module01.FunctionO1 bug 管理-bug 管理2.3.1.1 Goal in Con text 简要说明检索与维护所有项目的 BUG的状态信息，BUG 共由8种状态。状态1：已提交：测试员发现 BUG后提交到BUG管理系统中的状态。（初始状态）状态2:已修改：程序员在修改了BUG后提交到 BUG管理系统中的状态。状态3:不修改

5、：程序员或项目经理根据需求分析、概要设计、详细设计说明书等上的要求经过考虑后决定对BUG不进行修改。其BUG的状态为不修改，需要说明理由。状态4:延迟：根据目前项目进程或计划等情况，暂时延期的状态状态5:待讨论：需要进行讨论后才能决定是否需要修改的BUG的状态。状态6:已验证：已经解决的并经过测试员复测的 BUG的状态。状态7:关闭：完全解决了，只供以后备查的状态状态8:重新打开：重新出现在新的版本中，重新打开以前关闭的bug状态。2.3.1.2 Preconditions 前置条件无2.3.1.3 End Condition 后置条件无2.3.1.4 Actors所有人员。2.3.1.5 T

6、rigger 触发条件无2.3.2 Project.Module01.Function02 bug 管理 -分配给我的 bug2.3.2.1 Goal in Context 简要说明测试人员对对象软件进行测试发现了bug后分配给开发人员。2.3.2.2 Preconditions 前置条件测试人员发现了 bug。2.3.2.3 End Condition 后置条件获取bug信息。2.3.2.4 Actors开发人员。2.3.2.5 Trigger 触发条件测试人员发现了 bug。2.3.3 Project.Module01.Function03 bug 管理 -我创建的 bug2.3.3.1

7、Goal in Context 简要说明根据测试人员给开发人员提供的bug信息创建一个处理这个 bug的功能模块。2.3.3.2 Preconditions 前置条件获取bug信息。2.3.3.3 End Condition 后置条件处理好这个bug以后，将信息交给测试人员。2.3.3.4 Actors开发人员。2.3.3.5 Trigger 触发条件获取bug信息。2.3.4 Project.Module01.Function04 bug 管理-bug查询2.3.4.1 Goal in Con text 简要说明查询bug信息的一个功能模块。2.3.4.2 Preconditions 前置条

8、件2.3.4.3 End Condition 后置条件无。2.3.4.4 Actors所有用例。2.3.4.5 Trigger 触发条件无。2.3.5 Project.Module02.Function01 项目管理 -项目管理2.3.5.1 Goal in Context 简要说明 根据需求，实际情况，创建项目 。2.3.5.2 Preconditions 前置条件了解需求，条 件允 许2.3.5.3 End Condition 后置条件创建用户组2.3.5.4 Actors项目经理2.3.5.5 Trigger 触发条件无2.3.6 Project.Module02.Function03

9、项目管理 -用户组管理2.3.6.1 Goal in Context 简要说明根据项目需求，选择合适人员，组成项目组2.3.6.2 Preconditions 前置条件项目已经建立2.3.6.3 End Condition 后置条件制定项目计划项目经理2.3.6.4 Actors2.3.6.5 Trigger 触发条件 该项目已经立项，项目计划已经建立2.3.7 Project.Module02.Function03 项目管理 -版本管理2.3.7.1 Goal in Context 简要说明对 每一次出现 bug 并修改后的被测项目的版本进行修改。2.3.7.2 Preconditions

10、前置条件开发员对当前bug修改完成。2.3.7.3 End Condition 后置条件 修改被测项目的版本。2.3.7.4 Actors项目经理。2.3.7.5 Trigger 触发条件当前Bug修改完成。2.3.8 Project.Module02.Function04 项目管理 -查询统计2.3.8.1 Goal in Context 简要说明查询反馈信息中已关闭的 bug数量，来得到被测试项目某阶段解决bug的程度。根据bug的解决程度用来控制被测项目的进度。2.3.8.2 Preconditions 前置条件无。2.3.8.3 End Condition 后置条件统计已关闭bug的数

11、量。2.3.8.4 Actors项目经理。2.3.8.5 Trigger 触发条件反馈信息确定。2.3.9 Project.Module03.Function01 用例管理 -测试计划管理管理所有的测试计划，并可以添加、删除、修改、查询测试计划。2.3.9.1 Goal in Context 简要说明2.3.9.2 Preconditions 前置条件制定项目计划。2.3.9.3 End Condition 后置条件 编写测试用例。2.3.9.4 Actors 软件 测试人员。2.3.9.5 Trigger 触发条件项目计划的制定。2.3.10 Project.Module03.Functio

12、n02 用例管理 -测试用例管理2.3.10.1 Goal in Context 简要说明 用来管理测试用例：可以对测试用例进行添加、删除 、修改、查询。2.3.10.2 Preconditions 前置条件 编写测试计划。2.3.10.3 End Condition 后置条件 管理所有 bug 。2.3.10.4 Actors软件测试人员2.3.10.5 T rigger 触发条件测试计划的编写。2.3.11 Project.Module03.Function03 用例管理 -用例测试结果管理2.3.11.1 Goal in Context 简要说明 在使用测试用例进行测试的时候要求测试用例

13、应该包含5种状态，状态 1：未测试，说明还没有开始测试。状态 2：测试通过：测试用例通过测试。状态 3：测试不通过：测试用例没有通过。状态 4：测试阻塞：阻塞表示该测试用例的前置条件还未符合，所以该用例测试没有办 法开始进行。状态 5：测试取消：取消表示如果测试用例与实际软件实现不想符合，那么测试用例不 能按照实际情况测试，那么测试用例取消。2.3.11.2 Preconditions 前置条件系统管理 -用户管理系统管理 -权限管理无2.3.11.3 End Condition 后置条件无2.3.11.4 Actors软件测试人员2.3.11.5 T rigger 触发条件当测试人员需要管理

14、用例测试结果的时候2.3.12 Project.Module04.Function012.3.12.1 Goal in Context 简要说明创建系统用户2.3.12.2 Preconditions 前置条件无2.3.12.3 E nd Condition 后置条件权限管理2.3.12.4 A ctors系统管理员2.3.12.5 T rigger 触发条件该项目已经立项2.3.13 Project.Module04.Function022.3.13.1 Goal in Context 简要说明对系统权限的管理2.3.13.2 Preconditions 前置条件用户创建2.3.13.3 E

15、 nd Condition 后置条件无2.3.13.4 A ctors系统管理员用户创建2.3.13.5 T rigger 触发条件2.3.14 Project.Module04.Function03 系统管理 -测试类别管理2.3.14.1 Goal in Context 简要说明软件测试常用的测试方法：黑盒测试：不基于内部设计和代码的任何知识，而是基于需求和功能性。白盒测试：基于一个应用代码的内部逻辑知识，基于覆盖全部代码、分支、路径、条件。单元测试：最微小规模的测试 ; 以测试某个功能或代码块。累积综合测试：当一个新功能增加后，对应用系统所做的连续测试。集成测试： 一个应用系统的各个部件

16、的联合测试， 以决定他们能否在一起共同工作。 部件可 以是代码块、独立的应用、网络上的客户端或服务器端程序。功能测试：用于测试应用系统的功能需求的黑盒测试方法。系统测试：基于系统整体需求说明书的黑盒类测试 ; 应覆盖系统所有联合的部件。2.3.14.2 Preconditions 前置条件无2.3.14.3 E nd Condition 后置条件无2.3.14.4 A ctors系统管理员2.3.14.5 T rigger 触发条件该项目已经立项2.3.15 Project.Module04.Function04 系统管理-bug级别管理2.3.15.1 Goal in Context 简要说

17、明BUG 一般分为 4个等级分别为致命（可对应目前BUG体系中的 非常严重”：致命性问题主要为： 系统无法执行、 崩溃或严重资源不足、 应用模块无法启动或异常退 出、无法测试、造成系统不稳定。具体基本上可分为：O内存泄漏O用户数据丢失或破坏O 系统崩溃 /死机 /冻结O 模块无法启动或异常退出O 严重的数值计算错误O 功能设计与需求严重不符O 其它导致无法测试的错误但不会影响到系统严重（可对应目前 BUG体系中的 严重”严重性问题主要为： 影响系统功能或操作， 主要功能存在严重缺陷， 稳定性。具体基本上可分为：O 功能未实现O 功能错误O 系统刷新错误O 语音或数据通讯错误O 轻微的数值计算错

18、误O 系统所提供的功能或服务受明显的影响 一般（可对应于目前 BUG 体系中的“普通”）一般性问题主要为：界面、性能缺陷具体基本上可分为：O 操作界面错误（包括数据窗口内列名定义、含义是否一致）O 边界条件下错误O 提示信息错误（包括未给出信息、信息提示错误等）O 长时间操作无进度提示O 系统未优化（性能问题）O 光标跳转设置不好，鼠标（光标）定位错误提示（可对应于目前BUG体系中的 轻微及建议”提示性问题主要为：易用性及建议性问题具体基本上可分为：O 界面格式等不规范O 辅助说明描述不清楚O 操作时未给用户提示O可输入区域和只读区域没有明显的区分标志O个别不影响产品理解的错别字O 文字排列不

19、整齐等一些小问题O 建议2.3.15.2 Preconditions 前置条件无2.3.15.3 E nd Condition 后置条件无2.3.15.4 A ctors系统管理员2.3.15.5 T rigger 触发条件该项目已经立项3 Performance Requirements 性能需求1. 可以同时让 30个用户同时在线操作 .2. 保证系统在 6个工作日内运行不能出现异常 .4 Overall Design Constraints 总体设计约束4.1 Standards compliance 标准符合性1. Java 编码规范 :a) b) c) d) e) f)使用 Tab 键缩进 ; 使用驼峰标识 ; 主要方法和属性要有注释 属性名小写 ; 方法名小写 ;常量大写 .2. 标准文档模板 ,格式:参见所给文档模板4.2 Hardware Limitations 硬件约束要求能运行在内存大于1G的各类PC机器上.5 Software Quality Attributes软件质量特性5.1 Reliability 可靠性1. 强大的及时存储能力，防止数据以外丢失.2. 经测试系统可靠性99.999%.3. 定期对系统进行维护和升级.5.2 Usability 易用性1. 操作界面友好.2. 系统附带用户手册.3.