Wylie College

需求管理计划

 

版本 2.0

 

 

修订历史记录

日期

版本

描述

作者

1999 年 1 月 8 日

1.0

初始发行版

Simon Jones

1999 年 2 月 10 日

2.0 

扩展计划 

 Simon Jones

 
 
 
 
 
 
 
 

 


目录

1.     简介  

1.1      目的  

1.2      范围  

1.3      定义、首字母缩写词和缩写  

1.4      参考资料  

2.     需求管理

2.1      组织、职责和界面  

2.2      工具、环境和基础结构  

3.     需求管理计划   

3.1      需求确定  

3.2      可跟踪性  

3.2.1     产品需求的条件

3.2.2     用例需求的条件

3.2.3     测试用例的条件

3.3      属性  

3.3.1      用例需求的属性

3.3.2     测试用例的属性

3.4      报告和评估  

3.5      需求变更管理

3.6      规程和任务  

4.     里程碑  

5.     培训和资源  


需求管理计划

1.                  简介

1.1               目的

需求属性指南确定并描述用于管理 Wylie College 的所有软件项目需求的属性。此外,此文档还概括了将在开发时维护的项目需求可跟踪性。

分配给每个需求的属性将用于管理软件开发和为每个发行版的功能划分优先级。

需求可跟踪性的目的在于减少在开发周期后期发现的缺陷数量。确保在软件需求、设计和测试用例中捕获所有产品需求,提高产品的质量。

1.2            范围

本文档中的属性和可跟踪性指南适用于所有 Wylie College 软件项目的产品需求、软件需求和测试需求。

1.3                定义、首字母缩写词和缩写

使用 Rational Unified Process 和 Rational RequisitePro 文档中定义的术语。

1.4                参考资料

以下参考资料可以在 Wylie College 软件流程 Web 站点上找到。

1. Wylie College 配置管理计划。
2. Rational Unified Process。
3. Wylie College 开发案例。

2.                  需求管理

2.1                组织、职责和界面

包含在个别项目的软件开发计划中。

2.2                工具、环境和基础结构

Rational RequisitePro 将用于管理需求属性和可跟踪性。其他基础结构详细信息可在 Wylie College 软件流程 Web 站点上找到。

3.                  需求管理计划

3.1                需求确定

每个项目都将确定和管理以下需求类型:

 

工作产品

 

需求类型

描述

远景

产品需求

产品功能、约束、质量范围以及其他产品需求。

用例模型

用例

用例记录在 Rational Rose 中

测试计划

测试用例

这些用例描述如何验证系统是否是按预期运作的。

 

3.2                可跟踪性

3.2.1     产品需求的条件

“远景文档”中定义的产品需求可追溯到“用例规范”和“补充规范”中的相应用例或补充需求。

每个产品需求都可追溯到一个或多个用例需求和补充需求。

每个产品需求都可追溯到一个或多个用例需求和补充需求。

3.2.2     用例需求的条件

“用例规范”和“补充规范”中定义的用例需求可追溯到“测试计划”中指定的相应测试用例。

每个用例需求都会追溯到一个或多个系统测试用例。

3.2.3     测试用例的条件

“测试计划”中指定的测试用例可追溯到产品需求(根据版本)和由特定测试用例验证的用例需求。

一个测试用例可追溯到一个或多个产品和用例需求。当测试用例正在验证派生的需求或设计时,测试用例可能不能追溯到原始的产品需求或用例需求。

3.3                属性

3.3.1      用例需求的属性

将使用此节中定义的属性管理用例需求和补充规范。 这些属性有助于管理开发工时、确定迭代内容和将用例与指定 Rose 模型相关联。

状态

在分析起草用例后设置。跟踪用例开发的进度,从用例的最初起草直至用例的最终验证。

已提议

尽管还未复审和核准,但已确定的用例。

已核准

已核准并供进一步设计和实施的用例。

已验证

已在系统测试中通过验证的用例。

优先级

由项目经理设置。根据为用例分配开发资源和监视用例开发进度的重要性,确定用例的优先级。 优先级通常基于用户认识到的利益、计划的发行版、计划的迭代、用例(风险)的复杂性以及实施用例的工时。

用例的优先级是相对较高的,以便确保密切监视用例的实施并向任务适当分配资源。

相对于其他用例,用例的优先级是中等的。

用例的优先级较低。 此用例的实施不太重要,并且可转移或重新安排到后续迭代或发行版中实施。

工时估计

由开发团队设置。 由于某些用例需要更多的时间和资源,估计团队或人员的工作周数(例如,所需的代码行或功能点)能够最有效地估计复杂性并确定预计在给定时间内可以和不可以完成哪些操作。 用于管理作用域和确定开发优先级。项目经理将利用这些工时估计值来确定项目日程表并有效地计划任务的资源配备。

按“工作天数”估计工时(假设一个工作日为 7.5 小时)。

技术风险

由开发团队根据用例发生意外事件(例如,工时超出限制、设计缺陷、缺陷数量过多、质量较差和性能较差等)的可能性进行设置。这种意外事件通常是由于以下方面造成的:对需求了解不够或定义不正确、知识匮乏、缺少资源、技术复杂以及不熟悉新技术、新工具或新设备。

Wylie College 项目将每个用例的技术风险划分为以下几类:高、中或低。

风险的影响以及风险发生的可能性都非常高。

风险的影响不太重要并且/或者风险发生的可能性不太大。

风险的影响和风险发生的可能性都非常小。

目标开发迭代

记录将实施用例的开发迭代。预计将在项目构造阶段期间通过一些开发迭代开发每个发行版。

项目经理将使用分配给每个用例的迭代号来计划项目团队的活动。

可选值的结构为 <字母>-<迭代号>,其中字母是 I、E、C 和 T,分别代表先启、精化、构造和移交。例如:

 E-1

安排在精化阶段的迭代 1

C-1

安排在构造阶段的迭代 1

C-2

安排在构造阶段的迭代 2

C-3

安排在构造阶段的迭代 3

分配给

会将用例分配给个人或开发团队,用于进一步分析、设计和实施。 使用简单的下拉列表帮助项目团队成员更好地了解其职责。

Rational Rose 模型

确定与用例需求关联的 Rose 用例模型。

3.3.2     测试用例的属性

测试状态

由测试负责人设置。 跟踪每个测试用例的状态。

未测试

还未执行测试用例。

已失败

已执行测试,但测试失败。

有条件通过

已经完成测试,但是存在问题。在某些操作已完成的条件下,指定测试的状态为“通过”。

通过

测试已经成功完成。

构建号

记录将验证特定测试用例的系统构建。

测试者

执行和验证测试用例的人员。这个简单的下拉列表将帮助项目团队成员更好地了解其职责。

测试日期

计划测试日期或实际测试日期。

测试注释

与计划或执行测试关联的任何注释。

3.4                报告和评估

TBD

3.5                需求变更管理

请参阅 Wylie College 配置管理计划。

3.6               规程和任务

请参阅 Wylie College 开发案例。

4.                  里程碑

这在每个项目的软件开发计划中描述。

5.                  培训和资源

这在每个项目的软件开发计划中描述。