Wylie College

Requirements Management Plan

Version 2.0

Revision History

Table of Contents

1.     Introduction  

1.1      Purpose  

1.2      Scope  

1.3      Definitions, Acronyms, and Abbreviations  

1.4      References  

2.     Requirements Management

2.1      Organization, Responsibilities, and Interfaces  

2.2      Tools, Environment, and Infrastructure  

3.     The Requirements Management Program   

3.1      Requirements Identification  

3.2      Traceability  

3.2.1     Criteria for Product Requirements

3.2.2     Criteria for Use Case Requirements

3.2.3     Criteria for Test Cases

3.3      Attributes  

3.3.1      Attributes for Use Case Requirements

3.3.2     Attributes for Test Cases

3.4      Reports and Measures  

3.5      Requirements Change Management

3.6      Disciplines and Tasks  

4.     Milestones  

5.     Training and Resources  

Requirements Management Plan

1.                  Introduction

1.1               Purpose

The Requirements Attributes Guidelines identifies and describes the attributes that will be used for managing the requirements for all software projects at Wylie College. In addition, this document outlines the requirements traceability that will be maintained on projects during development.

The attributes assigned to each requirement will be used to manage the software development and to prioritize the features for each release.

The objective of requirements traceability is to reduce the number of defects found late in the development cycle. Ensuring all product requirements are captured in the software requirements, design, and test cases improves the quality of the product.

1.2            Scope

The attribute and traceability guidelines in this document apply to the product requirements, software requirements, and test requirements for all Wylie College software projects.

1.3                Definitions, Acronyms, and Abbreviations

We use terms as defined in the Rational Unified Process and in Rational RequisitePro documentation.

1.4                References

The following references may be found on or from the Wylie College Software Process web site.

1. Wylie College Configuration Management Plan.
2. Rational Unified Process.
3. Wylie College Development Case

2.                  Requirements Management

2.1                Organization, Responsibilities, and Interfaces

Covered by the individual project's Software Development Plan.

2.2                Tools, Environment, and Infrastructure

Rational RequisitePro will be used to manage requirements attributes and traceability.  Other infrastructure details are covered on the Wylie College Software Process Website.

3.                  The Requirements Management Program

3.1                Requirements Identification

Each project will identify and manage the following requirement types:

3.2                Traceability

3.2.1     Criteria for Product Requirements

The product requirements defined in the Vision Document  will be traced to the corresponding use case or supplementary requirements in the Use Case Specifications, and the Supplementary Specification.

Each product requirement traces to 1 or more use case requirements and supplementary requirements.

Each product requirement traces to 1 or more use case requirements and supplementary requirements.

3.2.2     Criteria for Use Case Requirements

The use case requirements defined in the Use Case Specifications  and the Supplementary Specification will be traced to the corresponding test cases specified in the Test Plan.

Each use case requirement traces to 1 or more system test cases.

3.2.3     Criteria for Test Cases

The test cases specified in the Test Plan are traced back to the product requirements (from the Vision) and use case requirements which are being verified by the particular test case.

A test case may trace back to 1 or more product and use case requirements. In the case where the test case is verifying a derived requirement or the design, the test case may have no traceability back to the original product requirements or use case requirements.

3.3                Attributes

3.3.1      Attributes for Use Case Requirements

The use case requirements and the Supplementary Specification will be managed using the attributes defined in this section. These attributes are useful for managing the development effort, determining iteration content, and for associating use cases with their specific Rose models.

Status

Set after the analysis has drafted the use cases. Tracks progress of the development of the use case from initial drafting of the use case through to final validation of the use case.

Priority

Set by the Project Manager. Determines the priority of the use case in terms of the importance of assigning development resources to the use case and monitoring the progress of the use case development. Priority is typically based upon the perceived benefit to the user, the planned release, the planned iteration, complexity of the use case (risk), and effort to implement the use case.

Effort Estimate

Set by the development team. Because some use cases require more time and resources than others, estimating the number of team or person-weeks, lines of code required or function points, for example, is the best way to gauge complexity and set expectations of what can and cannot be accomplished in a given time frame. Used in managing scope and determining development priority. The Project Manager uses these effort estimates to determine the project schedule and to effectively plan the resourcing of the tasks.

EEstimate effort in Person Days (assume 7.5 hours in a workday).

Technical Risk

Set by development team based on the probability the use case will experience undesirable events, such as effort overruns, design flaws, high number of defects, poor quality, poor performance, etc. Undesirable events such as these are often the result of poorly understood or defined requirements, insufficient knowledge, lack of resources, technical complexity, new technology, new tools, or new equipment.

Wylie College projects will categorize the technical risks of each use case as high, medium, or low.

Target Development Iteration

Records the development iteration in which the use case will be implemented. It is anticipated that the development for each release will be performed over several development iterations during the Construction Phase of the project.

The iteration number assigned to each use case is used by the Project Manager to plan the activities of the project team.

The possible values will be of the form <letter>-<iteration number> where the letter is I, E, C, T for inception, elaboration, construction and transition respectively.  For example:

Assigned To

Use cases are assigned to either individuals or development teams for further analysis, design, and implementation. A simple pull down list will help everyone on the project team better understand responsibilities.

Rational Rose Model

Identifies the Rose use case model associated with the use case requirement.

3.3.2     Attributes for Test Cases

Test Status

Set by the Test Lead. Tracks status of each test case.

Build Number

Records the system build in which the specific test case will be verified.

Tested By

Individual assigned to perform and verify the test case. This simple pull down list will help everyone on the project team better understand responsibilities.

Date Tested

Planned test date or actual test date.

Test Notes

Any notes associated with planning or executing the test.

3.4                Reports and Measures

TBD

3.5                Requirements Change Management

See the Wylie College Configuration Management Plan.

3.6               Disciplines and Tasks

See the Wylie College Development Case.

4.                  Milestones

This is described in each project's Software Development Plan.

5.                  Training and Resources

This is described in each project's Software Development Plan.