Requirements Management Plan

Version

Date Created: Date Updated:

Date Modified: Requirements Management Plan

4/2/2013

Revision History
Date 2/25/2008 03/25/2008 04/23/2008 Version 1.0 2.0 3.0 First Draft update Approval provided to add Use Cases by developers, and stakeholder request in the proposed state Updated TM records and CQTM records Description Author A. Kendrick A. Kendrick A. Kendrick

07/28/08

4.0

A. Kendrick

Page 2 of 39

Date Modified: Requirements Management Plan

4/2/2013

Table of Contents
1. Introduction 1.1 Purpose 1.2 Scope 1.3 Definitions, Acronyms, and Abbreviations 1.3.1 Product Feature 1.3.2 Stakeholder 1.3.3 Stakeholder Need 1.3.4 Baseline 1.3.5 Business Rule 1.3.6 Rational RequisitePro 1.3.7 Rational Software Architect 1.3.8 Rational SoDA 1.3.9 Use Case Specification 1.3.10 Business Use Case Specification 1.3.11 Actor 1.4 References 1.5 Overview 5 5 5 5 5 5 5 5 5 5 5 6 6 6 6 6 6

2. Requirements Management 7 2.1 Tools, Environment, and Infrastructure 7 2.2 Tool Integrations 7 2.3 Cross Repository Requirement Dependencies 10 2.4 Program Provisioning Options 12 2.4.1 Program Provisioning 12 2.4.2 The overall fundamentals of the RMP do not change; however the following provide guidance on how to utilize the tools to help manage these types of projects: 12 3. Requirements Artifacts 3.1 Artifact Description 3.1.1 Document Types 3.1.2 Requirement Types 3.1.3 Attributes 3.1.4 List Values 3.2 Traceability 3.2.1 Traceability Criteria for Requirements 3.2.2 Types 3.3 RequisitePro Requirement Structure Guidelines 3.3.1 Package Name: Dependent Application Proxy 3.3.2 Package Name: Functional Areas 3.3.3 Package Name: Functional Area 1 3.3.4 Package Name: Actors 3.3.5 Package Name: Supplementary Requirements 3.3.6 Package Name: Use Cases 3.3.7 Package Name: Use Case 1 3.3.8 Package Name: Glossary 3.3.9 Package Name: Project Specific Vision Document 3.3.10 Package Name: Project ID - Project Name 3.3.11 Package Name: Views 3.3.12 Package Name: Coverage Analysis 3.3.13 Package Name: Impact Analysis 13 13 13 14 16 20 24 24 25 27 27 28 28 28 28 28 28 28 28 28 28 28 28 Page 3 of 39

Date Modified: Requirements Management Plan 3.3.14 Package Name: Planning and Review 3.3.15 Package Name: Private Views 3.4 Reports and Measures 3.4.1 Views 3.4.2 Queries 4. Requirements Change Management

4/2/2013

29 29 29 29 38 39

Page 4 of 39

Date Modified: Requirements Management Plan

4/2/2013

Requirements Management Plan

1. Introduction
This document describes the guidelines used by a project to establish standard requirement documents, requirement types, requirement attributes, and traceability. It defines a strategy for managing requirements and serves as a resource for all persons participating in the project. 1.1 Purpose The purpose of this plan is to establish and document a systematic approach to organizing, and documenting the requirements of the system. This plan also establishes the process to maintain agreement between the customer and the project team on the evolving and changing requirements of the system. Scope This plan provides guidelines for the management of requirements for typical software projects at Definitions, Acronyms, and Abbreviations Product Feature A Product Feature is a capability or characteristic of a system that directly fulfills a Stakeholder Need, which is documented in a projects Vision document. A Feature is a summary of an entire set of behaviors, but does not describe those behaviors. Stakeholder A stakeholder is defined as anyone who is materially affected by the outcome of the project. Effectively solving any complex problem involves satisfying the needs of a diverse group of stakeholders. Stakeholders will typically have different perspectives on the problem, and different needs that must be addressed by the solution. Stakeholder Need The Stakeholder Needs is a business or operational problem (or opportunity) that must be fulfilled in order to justify purchase or use. This is the highest level of requirement, also known as a Need. Baseline A reviewed and approved release of artifacts that constitutes an agreed basis for further evolution or development and that can be changed only through a formal procedure, such as change management and configuration control. Business Rule A formal regulation or bylaw imposed by an organization or simply the standard practices of users governing the way the organization conducts its business. Rational RequisitePro Rational RequisitePro helps teams organize, prioritize, track and control changing requirements of a system or application. Rational Software Architect Rational Software Architect (RSA) is the newest modeling tool by IBM Rational.

1.2

1.3 1.3.1

1.3.2

1.3.3

1.3.4

1.3.5

1.3.6

1.3.7

Page 5 of 39

Date Modified: Requirements Management Plan 1.3.8

4/2/2013

Rational SoDA Rational SoDA provides automatic generation of software documentation by accessing the various Rational repositories directly. Use Case Specification A use case specification is a dialog between the system under development and one or more actors. Each use case is a logical piece of user functionality that can be initiated by an actor and described from the actors point of view in a technology-neutral manner. A use case shows how the primary actors goal is delivered or how the goal is not achieved. The use case provides scenarios related to the primary actors goal.

1.3.9

1.3.10 Business Use Case Specification A Business Use Case describes a business process from an external, value-added point of view. Business Use Cases are business processes that cross organization boundaries, possibly including partners and suppliers, in order to provide value to a stakeholder of the business, and meet specified performance goals of the business. Business Use Cases are useful for understanding what value the business provides and how it interacts with its environment. 1.3.11 Actor An actor is something, human or other system, with behavior that directly interacts with the system under development. Actors are external to the system. An actor is a stakeholder who requests that the system deliver a goal, and typically initiates the interaction with a use case. Sometimes, the scheduler (such as a clock), may initiate a use case on behalf of an actor for temporal use cases. 1.4 References Applicable references are: 1.5 Rational Unified Process 2003.16.13, Copyright 1987 2004 Rational Software Corporation Cockburn, Alistair. Writing Effective Use Cases, Copyright 2001 Addison-Wesley Bittner, Kurt. Use Case Modeling , Copyright 2004 Addison-Wesley

Overview This document contains specific details and strategies for managing the requirements of software projects at XYZA. The document details how requirements are organized and administrated within a project. It also describes how requirements will be identified, assigned attributes, traced, and modified. The document also describes the change management processes for requirements, including the workflows and activities associated with maintaining control of project requirements.

Page 6 of 39

Date Modified: Requirements Management Plan

4/2/2013

2.
2.1

Requirements Management
Tools, Environment, and Infrastructure Tool Description Licens e Info Technical Support Website

2.2

Tool Integrations Use case diagrams will be developed and maintained in. Change requests and defects will be entered into Requirement Management Methodology (RMM)

The RMM provides a framework for the Business Analyst community to begin adoption of industry best practices. The Requirements Management Methodology (RMM) will be developed in-house.

Page 7 of 39

Date Modified: Requirements Management Plan

4/2/2013

The following is a use case diagram showing the primary activities of the identified actors who will interact with Requirements Management and Rational Tools.

Page 8 of 39

Date Modified: Requirements Management Plan

4/2/2013

The following is a diagram showing the structural relationship between key concepts discussed in this document.

Page 9 of 39

Date Modified: Requirements Management Plan 2.3

4/2/2013

Cross Repository Requirement Dependencies The following have been identified as best practices for projects involving multiple RequisitePro repositories. An analyst working on a project that has dependencies on one or more requirement repositories may need to collaborate with other analysts in order to ensure requirements are documented in RequisitePro. The analyst must take advantage of a feature in RequisitePro called cross-project traceability and a proxy requirement type. This allows analysts to use a placeholder for requirement dependencies on other repositories. In this scenario an analyst will set a cross project trace to a Dependent Application Proxy requirement contained in one of the other requirement repositories (a.k.a. RequisitePro Project). To do this, the analysts must complete the following steps: The analyst must first connect to the other requirements repository (File->Project Administration->External Projects) if not already connected The analyst must trace one or more of the requirements in the primary repository to the secondary repositorys DAP The analyst must then notify the other analyst of the need for a new requirement in the other repository The secondary analyst must then document the new or changed requirement and set the trace from to the primarys requirement (note: The primary analysts requirement can be determined by inspecting the trace to DAP view in the project) The secondary analyst must set the project identifier correctly The secondary analyst must then notify the primary analyst the new or changed requirement is complete The primary analyst can inspect the text of the requirement If the requirement is correct, the primary analyst must remove the trace to the secondary repositorys DAP

Page 10 of 39

Date Modified: Requirements Management Plan The following diagram illustrates this scenario:
Requirements Management Process Manage Cross Application Requirement Dependencies

4/2/2013

Application A : Business Analyst

Application B : Business Analyst

Document and Organize Use Cases [Dependent on another application]

Document and Organize Use Cases

[Source is from DAP]

Trace to DAP in another application

Set Trace from source of requirement

Notify analyst on the other application

Notify analyst the requirement is written

Remove trace to DAP

Page 11 of 39

Date Modified: Requirements Management Plan 2.4

4/2/2013

Program Provisioning Options The following have been identified as an options for documenting Programs and associated projects using the Rational tools. Program Provisioning

2.4.1

2.4.2 The overall fundamentals of the RMP do not change; however the following provide guidance on how to utilize the tools to help manage these types of projects: A vision document will be created at the program level and/or the repository level (note: a vision should always exist at the repository level) Needs and features will be tagged in RequisitePro at the repository level Business use cases will be created at the program and/or repository level A supplementary specification can be documented at the program and/or repository level (note: a supplementary specification should always exist at the repository level) All use cases which specify system requirements should be documented at the appropriate repository level All repository supplemental requirements should trace from a program or repository level feature (or business use case) or from a program or repository level supplementary specification. The diagram below illustrates this option :

Page 12 of 39

Date Modified: Requirements Management Plan

4/2/2013

3.
3.1 3.1.1

Requirements Artifacts
Artifact Description Document Types This table describes the document types included in this template, and the associated requirement types. Note that documents may contain more than one requirement type. Not all the requirement types must be associated with documents (some may be database only).

Document Type
Vision

Description
This document describes the business results desired of the system and forms the basis for understanding the problem to be solved. A Business Use Case describes a business process from an external, value-added point of view. This document contains the use case description, pre- and post-conditions, actors, basic and alternative flows, measures, and other functional details. Non-functional Requirements that are specific to the use case are included in the Use Case Non-functional Requirements section of the use case. This document type describes system requirements not readily captured by the use case or spans multiple use cases. Examples include: business rules, operational, usability, reliability, performance, and infrastructure requirements (see the Attributes section below for a full list). Also, Functional declarative requirements are captured in this document. This document. Documents the project terminology.

Requirement Type
Stakeholder Need: STQRProduct Feature: FEAT (default)

Business Use Case Specification Use Case Specification

BUC

Use Case Name or Step: FUNC (category = UC) (default) Supplemental Requirement: SUPL (optional)

Supplementary Specification

Supplemental Requirement: SUPL

Requirements Management Plan Project Glossary

NONE Terminology: TERM

Page 13 of 39

Date Modified: Requirements Management Plan 3.1.2 Requirement Types

4/2/2013

Requirement Type Quantifiable Business Objective(QBO)

Functional (FUNC)

Description

Attributes

Describes functional requirements that can be a use case name, use case steps, or other functional requirements not appropriately or easily documented in use cases. Describes the qualities or properties of the application. Examples include: business rules, operational, usability, reliability, performance, and infrastructure requirements (see the Attributes section below for a full list). Captures the project terminology. Captures a brief description the role with respect to the system of actors.

Project Priority, Category, Status, Difficulty, Stability, Assigned Analyst, Risk Identifier, Release, Project Identifier, Enhancement, Defect, Obsolete Project Priority, Status, Difficulty, Stability, Assigned Analyst, Risk Identifier, Release, Project Identifier, Obsolete

Supplemental (SUPL)

Terminology (TERM) Actor (ACT)

None. None. Note: The Requirement Name attribute is used for the actors name and the requirement text contains the actor description. Business Priority, Status, Difficulty, Stability, Release, Risk Identifier, Project Identifier None

Feature (FEAT)

Features are high level capabilities of the system that directly fulfill a Stakeholder Need. This requirement is a placeholder for a new or changed requirement as a result of the need of another application. It provides a mechanism to allow a process for an analyst on one application to monitor the documentation of a dependent requirement in another application. All application requirement repositories contain one and only one proxy requirement. Stakeholder Needs are a reflection of the business problem or opportunity that must be addressed. Needs are written in a solution independent manner. A Business Use Case describes a business process from an external, value-added point of view.

Dependent Application Proxy

Stakeholder Need (STQR)

Business Priority, Category, Status, Difficulty, Stability, Assigned Analyst, Risk Identifier, Release, Project Identifier, Enhancement, Defect, Obsolete Business Priority, Category, Status, Difficulty, Stability, Assigned Analyst, Risk Identifier, Release, Project Identifier, Enhancement, Page 14 of 39

Business Use Case (BUC)

Date Modified: Requirements Management Plan Defect, Obsolete Business Rules(BR) A business rules describes the detail business rules for a requirement

4/2/2013

Business Priority, Category, Status, Difficulty, Stability, Assigned Analyst, Risk Identifier, Release, Project Identifier, Enhancement, Defect, Obsolete Business Priority, Enhancement

NONE

A item has been requested but not classified

Page 15 of 39

Date Modified: Requirements Management Plan

4/2/2013

3.1.3

Attributes

Attribute

Description
Establishes the importance of this requirement from a business perspective. Establishes the importance of this requirement from a project perspective. This allows the team the ability to roughly assign project priorities when specific iterations are unknown. Determines where this requirement is with respect to the stage of the software development process.

Type

List Values
Low Medium High Low Medium

Requirement Type

Business Priority

List

STQR, FEAT

Project Priority

List

FUNC, SUPL

High Proposed Under Review List Approved Incorporated FEAT, FUNC, SUPL

Status

Production Determines the relative amount of effort involved in designing, implementing, and testing this requirement. The production release that includes, or is planned to include, this requirement. This is a multiselect list because the requirement may change over time. The level of agreement that all stakeholders have Low Medium List High Unknown Set during project initiation Multi-list FEAT, FUNC, SUPL, STQR FEAT, FUNC, SUPL

Difficulty

Release

Stability

List

Low Medium

FEAT, FUNC, SUPL

Page 16 of 39

Date Modified: Requirements Management Plan

4/2/2013

Attribute

Description
regarding a requirement.

Type

List Values
High CQ Integration

Requirement Type

Defect

This attributes is integrated with the Project Asset DB This attribute is integrated with the Project Asset TM Test Plan Record This attribute is integrated with the Project Asset TM Test Case Record This attribute is integrated with the Project Asset TM Configured Test Case Record

This allows you to submit defects from CQTM or REQPRO

TM Test Plan

CQ Integration

TM Test Case

CQ Integration

TM Configured Test Case

CQ Integration

Page 17 of 39

Date Modified: Requirements Management Plan

4/2/2013

Attribute

Description
The analyst in charge of eliciting, organizing, documenting, and managing this requirement. This could also be set to indicate a vendors responsibility. Additional information that helps describe the type or category of a supplemental requirement. Business Rule is the default setting for this attribute.

Type

List Values
Set during project initiation

Requirement Type

Assigned to

List

FUNC, SUPL

Business Rule Usability Reliability Performance Supportability Application Infrastructure

Category

List

Integration / Interface Operational Regulatory / Legal Technical Constraint Security Testing Training

SUPL

Enhancement

Associated ClearQuest Enhancement Record Associated ClearQuest Defect Record Requirement has been removed from the system. The Project ID or name that is

ClearQuest

FEAT, FUNC, SUPL

Defect

ClearQuest

FEAT, FUNC, SUPL

Obsolete Project Identifier

T/F Multi-List Set during project

FUNC, SUPL FEAT, FUNC, SUPL

Page 18 of 39

Date Modified: Requirements Management Plan

4/2/2013

Attribute

Description
modifying this requirement.

Type

List Values
initiation

Requirement Type

Page 19 of 39

Date Modified: Requirements Management Plan

4/2/2013

Attribute

Description
Determine if a requirement is critical to quality. The measure is included as part of the requirement or set of requirements. Free form text field Free form text field Free form text field

Type

List Values
Set during Discovery

Requirement Type

CTQ (Critical to Quality)

T/F

FEAT, FUNC, SUPL, STQR

Notes Requirement Source Impacted Area 3.1.4 List Values

n/a n/a n/a

STQR, FEAT, FUNC, SUPL STQR, FEAT, FUNC, SUPL STQR, FEAT, FUNC, SUPL

Attribute

Value
Low

Description
Nice to have, could have, negotiable. Important but not urgent. Should have. Used in support of additional functionality surrounding high priority requirements. Project would not exist without it. Can be designed, developed, and tested later in the project Not important as to when it is designed, developed, and tested Should be designed, developed, and tested early in the project Select Test Plan to integrate a requirement with Select Test case to integrate a requirement with. Select the Configured Test case to integrate a requirement with Not important as to when it is designed, developed, and tested Should be designed, developed, and tested early in the project Requirement has been reviewed and is approved for this release. Incorporated and tested in a build in one of the development or test environments

Business Priority Medium High Low Project Priority Medium High TM Test Plan TM TestCase TM Configured Test Case Selection Selection Selection

Medium High Baselined Incorporate d

Page 20 of 39

Date Modified: Requirements Management Plan

4/2/2013

Attribute

Value
Production High

Description
Reflects the current state of the requirement it is in production Affects many components and interfaces and involves significant engineering effort. High technical risk. Affects a few components and a few interfaces. May involve much coding, but in familiar areas of the application. Not much risk. Affects just one component and only one interface. For example, a change to a report or a new report on existing data. Minimal risk. Functional requirements that are either a use case name or use case steps Functional requirement that is not expressed in a use case, but is required for the project. The following is a classification of business rules that help understand the description of a business rule and are not intended to be a fixed grouping. This classification of business rules is practical when explaining what business rules are, how to find them, and how to work with them. Constraint rules specify policies or conditions that restrict object structure and behavior. Constraint rules may always apply, or may apply only under certain conditions. Constraints that always apply are referred to as invariants. Stimulus and response rules constrain behavior by specifying when and if conditions must be true in order for behavior to be triggered. Operation constraint rules specify those conditions that must hold true before and after an operation to ensure that the operation performs correctly. Structure constraint rules specify policies or conditions about classes, objects, and corresponding relationships that should not be violated. Derivation rules specify policies or conditions for inferring or computing facts from other facts. Inference rules specify that if certain facts are true, a conclusion can be inferred. Computation rules derive results by way of processing algorithms, a more sophisticated variant of inference rules. Usability requirements: User Interface Requirements System Help Requirements Understandability

Difficulty

Medium

Low Use Case Category - FUNC Category - SUPL Other Business Rule

Usability

Page 21 of 39

Date Modified: Requirements Management Plan

4/2/2013

Attribute

Value
Reliability

Description
Reliability requirements to be considered are: Mean Time Between Failure (MTBF) Accuracy Predictability Disaster Recovery Business Recovery Failover Availability

Issue

High Medium Low

Page 22 of 39

Date Modified: Requirements Management Plan

4/2/2013

Attribute

Value
Performanc e

Description
A performance requirement imposes conditions on functional requirements. For example, for a given action, it may specify performance parameters for: Efficiency Throughput Response Time System Management Supportability requirements may include: Scalability Adaptability Maintainability Compatibility Configurability Serviceability Portability Ease of Installation A technical (design) requirement that specifies or constrains the design of a system. Design/System constraint Implementation Application-specific requirements, including: General application Vendor application Consider: Data storage Data volume Data retention Data replication Data conversion Desktop Network Additional environments An integration/interface requirement specifies: Software Integration/Interfaces Hardware Integration/Interfaces Requirements dictated by Regulators or Legal entities. Specifies any training requirements for the project. Specifies any training requirements for the project. Specifies any training requirements for the project. Specifies any Operational area requirements for the project.

Category SUPL(continued)

Supportabil ity

Technical Constraint

Application

Data

Infrastructu re Integration/ Interface Regulatory/ Legal Security Testing Training Operational

Page 23 of 39

Date Modified: Requirements Management Plan

4/2/2013

Attribute

Value
Vendor Base Out of the Box Low Medium

Description
A functional requirement which is provided directly without customization by the vendor. There is no work required to implement this requirement; however, to ensure coverage during testing it may be documented. Requirement is not well understood or is likely to change before the end of the project. These should not be approved. Requirement is well understood, but may change once a user sees the systems. These are typically candidates for UI prototypes. Requirement is well understood by the assigned analyst. However, it may still not be documented sufficiently to be approved.

Stability High

3.2

Traceability This diagram shows how the different requirements are related with trace relationships. The arrows depict the direction of the trace. Traceability Criteria for Requirements

3.2.1

TERM

NEED

BUC BR

FEAT

DAP

FUNC: UC

SUPL + FUNC: Other

ACT

Page 24 of 39

Date Modified: Requirements Management Plan 3.2.2 Types

4/2/2013

Requirement Type
STQR: Stakeholder Need

Trace Guidelines
Trace to: FEAT, DAP Trace from: none

Reason
Features are the high-level capabilities of the system that help fulfill the stakeholder needs. Therefore; a trace relationship to features ensures that system requirements are always linked to a stakeholder need therefore focusing the team on the most important work. See also DAP trace requirements. FEAT to SUPL and FUNC (UC): tracing FEAT to the more detailed requirements provides coverage reporting and scope management relative to the agreed upon features in the Vision. Only trace to the highest level detailed requirements such as use case names. FEAT from NEED: Features fulfill a NEED and should be derived from one or more needs. (see DAP trace requirements)

FEAT: Product Feature

Trace to: FUNC (UC), SUPL, DAP Trace from: FEAT

UseCase: Use Case Name or Use Case Steps

Trace to: SUPL Trace from: FEAT, ACT

FUNC (UC) from SUPL: FUNC (UC) will be used for planning purposes along with the transactions and needs that relate to the bulk of the work involved which is captured in the SUPL. This will help prevent SUPL, in particular business rules, from falling through the cracks during scenario implementation. FUNC (UC) to SUPL: Architects and testers need to know which functionality will drive the nonfunctional requirements. FUNC (UC) from ACT: Establishing this relationship is largely for reporting purposes use case model survey. The Actor section of the use case should contain the name of the actors but not a brief description. See also DAP trace requirements.

FUNC (Other)

Trace to: SUPL

Page 25 of 39

Date Modified: Requirements Management Plan Trace from: FEAT, ACT

4/2/2013

Page 26 of 39

Date Modified: Requirements Management Plan

4/2/2013

Requirement Type
SUPL: Supplemental Requirement

Trace Guidelines
Trace to: SUPL, DAP Trace from: FUNC (UC), FEAT, SUPL, FUNC (Other)

Reason
SUPL to SUPL: A supplementary requirement may have a dependency on another SUPL. SUPL from FEAT: Features are a primary source of high level supplementary requirements. SUPL to FUNC (UC): see above FUNC (UC) from SUPL description. SUPL to FUNC (Other): see above FUNC (Other) from SUPL description. See also DAP trace requirements.

TERM: Glossary item

Trace to: none Trace from: none

Terms should be in bold any where referenced for the project. Tracing to or from TERM requirements would not add sufficient value; therefore, no tracing is required. ACT to FUNC (UC)/FUNC (Other): Establishing this relationship is largely for reporting purposes use case model survey. The Actor section of the use case should contain the name of the actors but not a brief description DAP from NEED, FEAT, UC, SUPL: Other applications will trace to this requirement when there is a need for this application to write a new requirement. This trace will be replaced with a trace to the real requirement once it is written.

ACT: Actor

Trace to: FUNC (UC), FUNC (Other) Trace from: none

DAP: Dependent Application Proxy

Trace to: none Trace From: NEED, FEAT, FUNC (UC), FUNC (Other), SUPL (from an external application requirement repository)

3.3

RequisitePro Requirement Structure Guidelines

3.3.1

Package Name: Dependent Application Proxy Description: This package contains the dependent application proxy requirement. Other applications will trace to this requirement when there is a need for this application to write a new requirement. There is only one requirement in this package.

Page 27 of 39

Date Modified: Requirements Management Plan 3.3.2

4/2/2013

Package Name: Functional Areas Description: This contains all the high level functional areas of an application. An application may have one or more functional areas depending on its size and complexity. Each functional area contains use cases and supplemental requirements that are unique to it. Package Name: Functional Area 1 Description: Replace the name of this package with the name of the first functional area of the application. The analyst should still use this structure even if the application has only one functional area. Only very large applications should have more than one functional area. Package Name: Actors Description: List of actors for this functional area Package Name: Supplementary Requirements Description: This package contains supplementary requirements (a.k.a. business rules and non-functional requirements) and related information. For a very large application, the analyst may have multiple supplementary requirements for each functional area. Package Name: Use Cases Description: This package contains all use cases and use case documents for this functional area. Each use case should be placed in a package having the same name as the use case. Package Name: Use Case 1 Description: Replace the name of this folder with the name of the first use case. Place the use case document and all its contained requirements in this package. Package Name: Glossary Description: This package contains glossary information for the project. Package Name: Project Specific Vision Document Description: This package contains the vision document, stakeholder needs and product features. There may be several vision documents over time contained in this package. Therefore, each vision document should be in a package indicating the project to which it pertains. Package Name: Project ID - Project Name Description: Replace this package name with the project identifier and name. Create the project's vision document in this package. Package Name: Views Description: All views should be created in this package. Package Name: Coverage Analysis Description: This package stores views that report on requirement coverage. The analyst can use these as examples or basis for private views. Package Name: Impact Analysis Description: This package stores views that report on the impact of requirement changes. The analyst can use these as examples or basis for private views.

3.3.3

3.3.4

3.3.5

3.3.6

3.3.7

3.3.8

3.3.9

3.3.10

3.3.11

3.3.12

3.3.13

Page 28 of 39

Date Modified: Requirements Management Plan 3.3.14

4/2/2013

Package Name: Planning and Review Description: This package stores views that are useful for planning and reviews. The analyst can use these as examples or basis for private views. Package Name: Private Views Description: Put any private views in this package (e.g. all requirements for the project). Reports and Measures For reports and measures on this project, use the Requirement Metrics tool, which is available from the Tool menu. In Requirement Metrics, create reports based on requirement types or saved views and query on the following filters: Requirement Creation: The Requirement Creation filter returns all requirements of the specified requirement type. Typically, this filter is used with the Time Period option to determine which requirements have been created in a specified time period. Requirement Text Change: A Requirement Text Change filter returns the requirements whose text has changed the number of times specified. The filter allows the analyst to choose comparison operators, such as "equal to" (=), "greater than" (>), etc., when specifying the number of times that the text has changed. Requirement Attribute: A Requirement Attribute Change filter returns the number of requirements by Status attribute.

3.3.15

3.4

3.4.1 Views

The following are views available ::

View Name All Stakeholder Needs (STQR) Description Displays the various attributes associated with all Stakeholder Needs Displays the various attributes associated with all Features Displays the various attributes associated with all Functional Requirements Displays the various attributes associated with all Functional Requirements filtered by Category: Use Case Displays the various attributes associated with all Functional Requirements filtered by Category: Other Displays the various attributes associated with all Supplemental Requirements Requirement Type(s) STQR View Type(s) Attribute Matrix Location Views Attribute Matrices Attributes

All Features (FEAT)

FEAT

Attribute Matrix

Views Attribute Matrices

All Functional Requirements (FUNC) All Functional Requirements: Use Cases (FUNC: UC)

FUNC

Attribute Matrix

Views Attribute Matrices

FUNC: UC

Attribute Matrix

Views Attribute Matrices

Category = Use Case

All Functional Requirements: Other (FUNC: Other) All Supplemental Requirements (SUPL)

FUNC: Other

Attribute Matrix

Views Attribute Matrices

Category = Other

SUPL

Attribute Matrix

Views Attribute Matrices

Page 29 of 39

Date Modified: Requirements Management Plan

All Supplemental Requirements: Business Rules (BR) All Business Use Cases (BUC) All Terminology (TERM) All Actors (ACT) Displays the various attributes associated with all Supplemental Requirements filtered by Category: Business Rule Displays the various attributes associated with all Business Use Cases Displays the various attributes associated with all project terminology Displays the various attributes associated with all Actors Displays the various attributes associated with all Dependent Application Proxies Stakeholder Needs traced to Features BR Attribute Matrix Views Attribute Matrices

4/2/2013

Category = Business Rule

BUC

Attribute Matrix

Views Attribute Matrices

TERM

Attribute Matrix

Views Attribute Matrices

ACT

Attribute Matrix

Views Attribute Matrices

All Dependent Application Proxies (DAP) NEEDs traced to FEATs

DAP

Attribute Matrix

Views Attribute Matrices

NEED FEAT

Traceability Matrix Traceability Tree Traceability Matrix Traceability Tree Traceability Matrix

Views Coverage Analysis Coverage Analysis Matrices / Coverage Analysis Trees Views Coverage Analysis Coverage Analysis Matrices / Coverage Analysis Trees Views Coverage Analysis Coverage Analysis Matrices Views Coverage Analysis Coverage Analysis Matrices / Coverage Analysis Trees Views Coverage Analysis Coverage Analysis Matrices Category = Use Case

NEEDs not traced to FEATs

Stakeholder Needs not traced to Features

NEED FEAT

NEEDs traced to DAPs

Stakeholder Needs traced to Dependent Application Proxies Features traced to Functional Requirements filtered by Category: Use Case Features not traced to Functional Requirements filtered by Category: Use Case Features traced to Functional Requirements filtered by Category: Other Features not traced to Functional Requirements filtered by Category: Other Features traced to Supplemental Requirements

NEED DAP

FEATs traced to FUNC: UC

FEAT FUNC: UC

Traceability Matrix Traceability Tree Traceability Matrix

FEATs not traced to FUNC: UC

FEAT FUNC: UC

Category = Use Case

FEATs traced to FUNC: Other

FEAT FUNC: Other

Traceability Matrix Traceability Tree Traceability Matrix

Views Coverage Analysis Coverage Analysis Matrices / Coverage Analysis Trees Views Coverage Analysis Coverage Analysis Matrices Views Coverage Analysis Coverage Analysis Matrices / Coverage Analysis Trees

Category = Other

FEATs not traced to FUNC: Other FEATs traced to SUPLs

FEAT FUNC: Other

Category = Other

FEAT SUPL

Traceability Matrix Traceability Tree

Page 30 of 39

Date Modified: Requirements Management Plan

FEATs not traced to SUPLs Features not traced to Supplemental Requirements FEAT SUPL Traceability Matrix Traceability Tree Traceability Matrix Traceability Tree Traceability Matrix Views Coverage Analysis Coverage Analysis Matrices / Coverage Analysis Trees Views Coverage Analysis Coverage Analysis Matrices / Coverage Analysis Trees Views Coverage Analysis Coverage Analysis Matrices Views Coverage Analysis Coverage Analysis Trees

4/2/2013

FEATs traced to FEATs

Features traced to Features

FEAT FEAT

FEATs traced to DAPs

Features traced to Dependent Application Proxies Features not traced to Business Use Cases, Functional Requirements (Use Cases and/or Other), Supplemental Requirements, or Dependent Application Proxies Functional Requirements filtered by Category: Use Case traced to Supplemental Requirements Functional Requirements filtered by Category: Use Case not traced to Supplemental Requirements Functional Requirements filtered by Category: Other not traced to Supplemental Requirements Functional Requirements filtered by Category: Other not traced to Supplemental Requirements Functional Requirements filtered by Category: Use Case traced to Dependent Application Proxies Functional Requirements filtered by Category: Other traced to Dependent Application Proxies Supplemental Requirements traced to Supplemental Requirements

FEAT DAP

FEATs not traced to BUC / FUNC: UC / FUNC: Other / SUPL / DAP

FEAT BUC FUNC SUPL DAP FUNC: UC SUPL

Traceability Tree

FUNC: UC traced to SUPLs

Traceability Matrix Traceability Tree Traceability Matrix Traceability Tree Traceability Matrix Traceability Tree Traceability Matrix Traceability Tree Traceability Matrix

Views Coverage Analysis Coverage Analysis Matrices / Coverage Analysis Trees Views Coverage Analysis Coverage Analysis Matrices / Coverage Analysis Trees Views Coverage Analysis Coverage Analysis Matrices / Coverage Analysis Trees Views Coverage Analysis Coverage Analysis Matrices / Coverage Analysis Trees Views Coverage Analysis Coverage Analysis Matrices

Category = Use Case

FUNC: UC not traced to SUPLs

FUNC: UC SUPL

Category = Use Case

FUNC: Other traced to SUPLs

FUNC: Other SUPL

Category = Other

FUNC: Other not traced to SUPLs

FUNC: Other SUPL

Category = Other

FUNC: UC traced to DAPs

FUNC: UC DAP

Category = Use Case

FUNC: Other traced to DAPs

FUNC: Other DAP

Traceability Matrix

Views Coverage Analysis Coverage Analysis Matrices

Category = Other

SUPLs traced to SUPLs

SUPL SUPL

Traceability Matrix Traceability Tree

Views Coverage Analysis Coverage Analysis Matrices / Coverage Analysis Trees

Page 31 of 39

Date Modified: Requirements Management Plan

SUPLs traced to DAPs Supplemental Requirements traced to Dependent Application Proxies Business Use Cases traced to Functional Requirements filtered by Category: Use Case Business Use Cases not traced to Functional Requirements filtered by Category: Use Case Actors traced to Functional Requirements filtered by Category: Use Case Actors not traced to Functional Requirements filtered by Category: Use Case Features traced from Stakeholder Needs SUPL DAP Traceability Matrix Views Coverage Analysis Coverage Analysis Matrices Views Coverage Analysis Coverage Analysis Matrices / Coverage Analysis Trees Views Coverage Analysis Coverage Analysis Matrices

4/2/2013

BUCs traced to FUNC: UC

BUC FUNC: UC

Traceability Matrix Traceability Tree Traceability Matrix

Category = Use Case

BUCs not traced to FUNC: UC

BUC FUNC: UC

Category = Use Case

ACTs traced to FUNC: UC

ACT FUNC: UC

Traceability Matrix Traceability Tree Traceability Matrix

Views Coverage Analysis Coverage Analysis Matrices / Coverage Analysis Trees Views Coverage Analysis Coverage Analysis Matrices

Category = Use Case

ACTs not traced to FUNC: UC

ACT FUNC: UC

Category = Use Case

FEATs traced from NEEDs

FEAT NEED

Traceability Matrix Traceability Tree Traceability Matrix Traceability Tree Traceability Matrix Traceability Tree Traceability Matrix Traceability Tree Traceability Matrix Traceability Tree Traceability Matrix Traceability Tree Traceability Matrix Traceability Tree

Views Traceability Analysis Traceability Analysis Matrices / Traceability Analysis Trees Views Traceability Analysis Traceability Analysis Matrices / Traceability Analysis Trees Views Traceability Analysis Traceability Analysis Matrices / Traceability Analysis Trees Views Traceability Analysis Traceability Analysis Matrices / Traceability Analysis Trees Views Traceability Analysis Traceability Analysis Matrices / Traceability Analysis Trees Views Traceability Analysis Traceability Analysis Matrices / Traceability Analysis Trees Views Traceability Analysis Traceability Analysis Matrices / Traceability Analysis Trees Category = Use Case

FEATs not traced from NEEDs

Features not traced from Stakeholder Needs

FEAT NEED

FEATs traced from FEATs

Features traced from Features

FEAT FEAT

FUNC: UC traced from FEATs

Functional Requirements filtered by Category: Use Case traced from Features Functional Requirements filtered by Category: Use Case not traced from Features Functional Requirements filtered by Category: Other traced from Features Functional Requirements filtered by Category: Other not traced from Features

FUNC: UC FEAT

FUNC: UC not traced from FEATs

FUNC: UC FEAT

Category = Use Case

FUNC: Other traced from FEATs

FUNC: Other FEAT

Category = Other

FUNC: Other not traced from FEATs

FUNC: Other FEAT

Category = Other

Page 32 of 39

Date Modified: Requirements Management Plan

FUNC: UC traced from ACTs Functional Requirements filtered by Category: Use Case traced from Actors Functional Requirements filtered by Category: Use Case not traced from Actors Functional Requirements filtered by Category: Use Case traced from Business Use Cases Functional Requirements filtered by Category: Use Case not traced from Business Use Cases Functional Requirements filtered by Category: Use Case not traced from Business Use Cases, Features, or Actors Functional Requirements filtered by Category: Other not traced from Functional Requirements (Use Case and/or Other), Supplemental Requirements, or Features Supplemental Requirements traced from Features FUNC: UC ACT Traceability Matrix Traceability Tree Traceability Matrix Traceability Tree Traceability Matrix Traceability Tree Traceability Matrix Traceability Tree Traceability Tree Views Traceability Analysis Traceability Analysis Matrices / Traceability Analysis Trees Views Traceability Analysis Traceability Analysis Matrices / Traceability Analysis Trees Views Traceability Analysis Traceability Analysis Matrices / Traceability Analysis Trees Views Traceability Analysis Traceability Analysis Matrices / Traceability Analysis Trees Views Traceability Analysis Traceability Analysis Trees

4/2/2013

Category = Use Case

FUNC: UC not traced from ACTs

FUNC: UC ACT

Category = Use Case

FUNC: UC traced from BUCs

FUNC: UC BUC

Category = Use Case

FUNC: UC not traced from BUCs

FUNC: UC BUC

Category = Use Case

FUNC: UC not traced from BUC / FEAT / ACT

FUNC: UC BUC FEAT ACT FUNC FUNC SUPL FEAT

Category = Use Case

FUNC: Other not traced from FUNC: UC / FUNC: Other SUPL / FEAT

Traceability Tree

Views Traceability Analysis Traceability Analysis Trees

Category = Other

SUPLs traced from FEATs

SUPL FEAT

Traceability Matrix Traceability Tree Traceability Matrix Traceability Tree Traceability Matrix Traceability Tree Traceability Matrix

Views Traceability Analysis Traceability Analysis Matrices / Traceability Analysis Trees Views Traceability Analysis Traceability Analysis Matrices / Traceability Analysis Trees Views Traceability Analysis Traceability Analysis Matrices / Traceability Analysis Trees Views Traceability Analysis Traceability Analysis Matrices Category = Use Case

SUPLs not traced from FEATs

Supplemental Requirements not traced from Features

SUPL FEAT

SUPLs traced from FUNC: UC

Supplemental Requirements traced from Functional Requirements filtered by Category: Use Case Supplemental Requirements not traced from Functional Requirements filtered by Category: Use Case Supplemental Requirements traced from Functional Requirements filtered by Category: Other

SUPL FUNC: UC

SUPLs not traced from FUNC: UC

SUPL FUNC: UC

Category = Use Case

SUPLs traced from FUNC: Other

SUPL FUNC: Other

Traceability Matrix Traceability Tree

Views Traceability Analysis Traceability Analysis Matrices / Traceability Analysis Trees

Category = Other

Page 33 of 39

Date Modified: Requirements Management Plan

SUPLs not traced from FUNC: Other Supplemental Requirements not traced from Functional Requirements filtered by Category: Other Supplemental Requirements traced from Supplemental Requirements Supplemental Requirements not traced from Supplemental Requirements, Functional Requirements (Use Case and/or Other), or Features Dependent Application Proxies traced from Stakeholder Needs Dependent Application Proxies traced from Features Dependent Application Proxies traced from Functional Requirements filtered by Category: Use Case Dependent Application Proxies traced from Functional Requirements filtered by Category: Other Dependent Application Proxies traced from Supplemental Requirements Features traced to Features SUPL FUNC: Other Traceability Matrix Views Traceability Analysis Traceability Analysis Matrices

4/2/2013

Category = Other

SUPLs traced from SUPLs

SUPL SUPL

Traceability Matrix Traceability Tree Traceability Tree

Views Traceability Analysis Traceability Analysis Matrices / Traceability Analysis Trees Views Traceability Analysis Traceability Analysis Trees

SUPLs not traced from SUPL / FUNC: UC / FUNC: Other / FEAT

SUPL SUPL FUNC FEAT

DAPs traced from NEEDs

DAP NEED

Traceability Matrix

Views Traceability Analysis Traceability Analysis Matrices Views Traceability Analysis Traceability Analysis Matrices Views Traceability Analysis Traceability Analysis Matrices Category = Use Case

DAPs traced from FEATs

DAP FEAT

Traceability Matrix

DAPs traced from FUNC:UC

DAP FUNC: UC

Traceability Matrix

DAPs traced from FUNC: Other

DAP FUNC: Other

Traceability Matrix

Views Traceability Analysis Traceability Analysis Matrices

Category = Other

DAPs traced from SUPLs

DAP SUPL

Traceability Matrix

Views Traceability Analysis Traceability Analysis Matrices

FEATs traced to FEATs

FEAT FEAT

Traceability Matrix Traceability Tree Traceability Matrix

Views Coverage Analysis Coverage Analysis Matrices / Coverage Analysis Trees Views Coverage Analysis Coverage Analysis Matrices Views Coverage Analysis Coverage Analysis Trees

FEATs traced to DAPs

Features traced to Dependent Application Proxies Features not traced to Business Use Cases, Functional Requirements, Supplemental Requirements, or Dependent Application Proxies

FEAT DAP

FEATs not traced to BUC / FUNC / SUPL / DAP

FEAT BUC FUNC SUPL DAP

Traceability Tree

Page 34 of 39

Date Modified: Requirements Management Plan

FUNCs traced to SUPLs Functional Requirements traced to Supplemental Requirements Functional Requirements not traced to Supplemental Requirements Functional Requirements not traced to Dependent Application Proxies Supplemental Requirements traced to Supplemental Requirements Supplemental Requirements traced to Dependent Application Proxies Business Use Cases traced to Functional Requirements filtered by Category: Use Case Business Use Cases not traced to Functional Requirements filtered by Category: Use Case Actors traced to Functional Requirements FUNC SUPL Traceability Matrix Traceability Tree Traceability Matrix Traceability Tree Traceability Matrix Views Coverage Analysis Coverage Analysis Matrices / Coverage Analysis Trees Views Coverage Analysis Coverage Analysis Matrices / Coverage Analysis Trees Views Coverage Analysis Coverage Analysis Matrices Views Coverage Analysis Coverage Analysis Matrices / Coverage Analysis Trees Views Coverage Analysis Coverage Analysis Matrices Views Coverage Analysis Coverage Analysis Matrices / Coverage Analysis Trees Views Coverage Analysis Coverage Analysis Matrices / Coverage Analysis Trees Views Coverage Analysis Coverage Analysis Matrices / Coverage Analysis Trees Views Coverage Analysis Coverage Analysis Matrices / Coverage Analysis Trees

4/2/2013

FUNCs not traced to SUPLs

FUNC SUPL

FUNCs traced to DAPs

FUNC DAP

SUPLs traced to SUPLs

SUPL SUPL

Traceability Matrix Traceability Tree Traceability Matrix

SUPLs traced to DAPs

SUPL DAP

BUCs traced to FUNC: UC

BUC FUNC: UC

Traceability Matrix Traceability Tree Traceability Matrix Traceability Tree Traceability Matrix Traceability Tree Traceability Matrix Traceability Tree

Category = Use Case

BUCs not traced to FUNC: UC

BUC FUNC: UC

Category = Use Case

ACTs traced to FUNCs

ACT FUNC

ACTs not traced to FUNCs

Actors not traced to Functional Requirements

ACT FUNC

Page 35 of 39

Date Modified: Requirements Management Plan

4/2/2013

View Name FEATs traced from NEEDs

Description Features traced from Stakeholder Needs

Requirement Type(s) FEAT NEED

View Type(s) Traceability Matrix Traceability Tree Traceability Matrix Traceability Tree Traceability Matrix Traceability Tree Traceability Matrix Traceability Tree Traceability Matrix Traceability Tree Traceability Matrix Traceability Tree Traceability Matrix Traceability Tree Traceability Matrix Traceability Tree Traceability Matrix Traceability Tree Traceability Matrix Traceability Tree Traceability Matrix Traceability Tree View Type(s)

Location Views Traceability Analysis Traceability Analysis Matrices / Traceability Analysis Trees Views Traceability Analysis Traceability Analysis Matrices / Traceability Analysis Trees Views Traceability Analysis Traceability Analysis Matrices / Traceability Analysis Trees Views Traceability Analysis Traceability Analysis Matrices / Traceability Analysis Trees Views Traceability Analysis Traceability Analysis Matrices / Traceability Analysis Trees Views Traceability Analysis Traceability Analysis Matrices / Traceability Analysis Trees Views Traceability Analysis Traceability Analysis Matrices / Traceability Analysis Trees Views Traceability Analysis Traceability Analysis Matrices / Traceability Analysis Trees Views Traceability Analysis Traceability Analysis Matrices / Traceability Analysis Trees Views Traceability Analysis Traceability Analysis Matrices / Traceability Analysis Trees Views Traceability Analysis Traceability Analysis Matrices / Traceability Analysis Trees Location

Attributes

FEATs not traced from NEEDs

Features not traced from Stakeholder Needs

FEAT NEED

FEATs traced from FEATs

Features traced from Features

FEAT FEAT

FUNCs traced from FEATs

Functional Requirements traced from Features

FUNC FEAT

FUNCs not traced from FEATs

Functional Requirements not traced from Features

FUNC FEAT

FUNCs traced from ACTs

Functional Requirements traced from Actors

FUNC ACT

FUNCs not traced from ACTs

Functional Requirements not traced from Actors

FUNC ACT

FUNC: UC traced from FEATs

Functional Requirements filtered by Category: Use Case traced from Features Functional Requirements filtered by Category: Use Case not traced from Features Functional Requirements filtered by Category: Use Case traced from Business Use Cases Functional Requirements filtered by Category: Use Case not traced from Business Use Cases Description

FUNC: UC FEAT

Category = Use Case

FUNC: UC not traced from FEATs

FUNC: UC FEAT

Category = Use Case

FUNC: UC traced from BUCs

FUNC: UC BUC

Category = Use Case

FUNC: UC not traced from BUCs

FUNC: UC BUC

Category = Use Case

View Name

Requirement Type(s)

Attributes

Page 36 of 39

Date Modified: Requirements Management Plan

FUNC: UC not traced from BUC / FEAT / ACT Functional Requirements filtered by Category: Use Case not traced from Business Use Cases, Features, or Actors Functional Requirements filtered by Category: Other traced from Features Functional Requirements filtered by Category: Other not traced from Features Functional Requirements filtered by Category: Other not traced from Functional Requirements, Supplemental Requirements, or Features Supplemental Requirements traced from Features FUNC: UC BUC FEAT ACT FUNC: Other FEAT Traceability Matrix Traceability Tree Traceability Matrix Traceability Tree Traceability Tree Views Traceability Analysis Traceability Analysis Matrices / Traceability Analysis Trees Views Traceability Analysis Traceability Analysis Matrices / Traceability Analysis Trees Views Traceability Analysis Traceability Analysis Trees Traceability Tree Views Traceability Analysis Traceability Analysis Trees

4/2/2013

Category = Use Case

FUNC: Other traced from FEATs

Category = Other

FUNC: Other not traced from FEATs

FUNC: Other FEAT

Category = Other

FUNC: Other not traced from FUNC / SUPL / FEAT

FUNC: Other FUNC SUPL FEAT

Category = Other

SUPLs traced from FEATs

SUPL FEAT

Traceability Matrix Traceability Tree Traceability Matrix Traceability Tree Traceability Matrix Traceability Tree Traceability Matrix Traceability Tree Traceability Matrix Traceability Tree

Views Traceability Analysis Traceability Analysis Matrices / Traceability Analysis Trees Views Traceability Analysis Traceability Analysis Matrices / Traceability Analysis Trees Views Traceability Analysis Traceability Analysis Matrices / Traceability Analysis Trees Views Traceability Analysis Traceability Analysis Matrices / Traceability Analysis Trees Views Traceability Analysis Traceability Analysis Matrices / Traceability Analysis Trees

SUPLs not traced from FEATs

Supplemental Requirements not traced from Features

SUPL FEAT

SUPLs traced from FUNCs

Supplemental Requirements traced from Functional Requirements Supplemental Requirements not traced from Functional Requirements Supplemental Requirements traced from Supplemental Requirements

SUPL FUNC

SUPLs not traced from FUNCs

SUPL FUNC

SUPLs traced from SUPLs

SUPL SUPL

Page 37 of 39

Date Modified: Requirements Management Plan

4/2/2013

View Name SUPLs not traced from SUPL / FUNC / FEAT

Description Supplemental Requirements not traced from Supplemental Requirements, Functional Requirements, or Features Dependent Application Proxies traced from Stakeholder Needs Dependent Application Proxies traced from Features Dependent Application Proxies traced from Functional Requirements Dependent Application Proxies traced from Supplemental Requirements

Requirement Type(s) SUPL SUPL FUNC FEAT

View Type(s) Traceability Tree

Location Views Traceability Analysis Traceability Analysis Trees

Attributes

DAPs traced from NEEDs

DAP NEED

Traceability Matrix

Views Traceability Analysis Traceability Analysis Matrices Views Traceability Analysis Traceability Analysis Matrices Views Traceability Analysis Traceability Analysis Matrices

DAPs traced from FEATs

DAP FEAT

Traceability Matrix

DAPs traced from FUNCs

DAP FUNC

Traceability Matrix

DAPs traced from SUPLs

DAP SUPL

Traceability Matrix

Views Traceability Analysis Traceability Analysis Matrices

3.4.2 Queries The following are queries available in the Rational tools: Query Name UC sorted or filtered by Status attribute Others can be defined as ad-hoc Description Requirement Type Attributes Example: Status = incorporated, approved Attribute Value Range Obsolete = False

Obsolete = False

Page 38 of 39

Date Modified: Requirements Management Plan

4/2/2013

4.

Requirements Change Management

Change to requirement text and requirement attributes will be controlled according to standards specified in the XYZA software process Quality Gates. Requirements are defined as baselined (approved by the stakeholders) when the requirement status attribute is set to Approved. This should occur after the final requirements review with the stakeholders. Please refer to the XYZA IT Solutions Management Tool as to when this activity occurs. The RequisitePro system administrator will be notified by the quality consultant to create a Requisite Pro baseline of the repository at that point in time. From that point, throughout the duration of the project, any changes to requirements associated with that projects project identifier require either a ClearQuest defect or Enhancement (change control) be associated with that requirement. This process is not enforced by the tool, but can be audited for compliance.

Page 39 of 39