Requirement Management Plan

Requirements Management Plan Version

Date Created: Date Updated:

Date Date Mod Modif ifie ied: d:

4/2/ 4/2/20 2013 13

Requirements Management Plan

Revision History Date

Version

Description

Author

2/25/2008

1.0

First Draft

A. Kendrick

03/25/2008

2.0

update

A. Kendrick

04/23/2008

3.0

Approval provided to add Use Cases by developers, and stakeholder request in the proposed state

A. Kendrick

07/28/08

4.0

Updated TM records and CQTM records

A. Kendrick

Page 2 of 39

Date Date Mod Modif ifie ied: d:

4/2/ 4/2/20 2013 13


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 2. Requirements Management

5 5 5 5 5 5 5 5 5 5 5 6 6 6 6 6 6 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 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:

4/2/2013

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

29 29 29 29 38 39

Page 4 of 39

Date Modified:

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, an d 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.

1.2

Scope This plan provides guidelines for the management of requirements for typical software projects at

1.3

Definitions, Acronyms, and Abbreviations

1.3.1

Product Feature A Product Feature is a capability or characteristic of a system that directly fulfills a Stakeholder Need, which is documented in a project’s Vision document. A Feature is a summary of an entire set of behaviors, but does not describe those behaviors.

1.3.2

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.

1.3.3

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”.

1.3.4

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.

1.3.5

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.

1.3.6

Rational RequisitePro® Rational RequisitePro helps teams organize, prioritize, track and control changing requirements of a system or application.

1.3.7

Rational Software Architect Rational Software Architect (RSA) is the newest modeling tool by IBM Rational.

Page 5 of 39

Date Modified:

4/2/2013


1.3.8

Rational SoDA® Rational SoDA provides automatic generation of software documentation by accessing the various Rational repositories directly.

1.3.9

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 actor’s point of view in a technology-neutral manner. A use case shows how the primary actor’s goal is delivered or how the goal is not achieved. The use case provides scenarios related to the primary actor’s goal.

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

•

Cockburn, Alistair. Writing Effective Use Cases, Copyright

•

Bittner, Kurt. Use Case Modeling , Copyright

©

©

1987 – 2004 Rational Software Corporation ©

2001 Addison-Wesley

2004 Addison-Wesley

Overview This document contains specific details and strategies for manag ing 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:

4/2/2013


2.

Requirements Management

2.1

Tools, Environment, and Infrastructure

Tool

2.2

Description

Licens e Info

Technical Support

Website

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:

4/2/2013

Requirements Management Plan 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:

4/2/2013

Requirements Management Plan The following is a diagram showing t he structural relationship between key concepts discussed in this document.

Page 9 of 39

Date Modified:

4/2/2013


2.3

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 repository’s 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 primary’s requirement (note: The primary analyst’s 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 repository’s DAP

Page 10 of 39

Date Modified:

4/2/2013

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

Application A : Business Analyst

Document and Organize Use Cases [Dependent on another application]

Trace to DAP in another application

Notify analyst on the other application

Application B : Business Analyst

Document and Organize Use Cases

[Source is from DAP]

Set Trace from source of requirement

Notify analyst the requirement is written

Remove trace to DAP

Page 11 of 39

Date Modified:

4/2/2013


2.4

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

2.4.1

Program Provisioning

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 a nd/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 approp riate 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:

4/2/2013


3.

Requirements Artifacts

3.1

Artifact Description

3.1.1

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

Description

Requirement Type

Vision

This document describes the business results desired of the system and forms the basis for understanding the problem to be solved.

Stakeholder Need: STQRProduct Feature: FEAT (default)

Business Use Case Specification

A Business Use Case describes a business process from an external, value-added point of view.

BUC

Use Case Specification

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.

Use Case Name or Step: FUNC (category = UC) (default)

Supplementary Specification

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.

Supplemental Requirement: SUPL


This document.

NONE

Project Glossary

Documents the project terminology.

Terminology: TERM

Supplemental Requirement: SUPL (optional)

Page 13 of 39

Date Modified:

4/2/2013


3.1.2

Requirement Types

Requirement Type

Description

Attributes

Quantifiable Business Objective(QBO) Functional (FUNC)

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.

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

Supplemental (SUPL)

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).

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

Terminology (TERM)

Captures the project terminology.

None.

Actor (ACT)

Captures a brief description – the role with respect to the system – of actors.

None. Note: The “Requirement Name” attribute is used for the actor’s name and the requirement text contains the actor description.

Feature (FEAT)

Features are high level capabilities of Business Priority, Status, Difficulty, the system that directly fulfill a Stability, Release, Risk Identifier, Stakeholder Need. Project Identifier

Dependent Application Proxy

This requirement is a placeholder for None 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 Need (STQR)

Stakeholder Needs are a reflection of the business problem or opportunity that must be addressed. Needs are written in a solution independent manner.

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

Business Use Case (BUC)

A Business Use Case describes a business process from an external, value-added point of view.

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

Page 14 of 39

Date Modified:

4/2/2013

Requirements Management Plan Defect, Obsolete Business Rules(BR)

A business rules describes the detail business rules for a requirement

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

NONE

A item has been requested but not classified

Business Priority, Enhancement

Page 15 of 39

Date Modified:

4/2/2013


3.1.3

Attributes

Attribute

Business Priority

Project Priority

Status

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

Requirement Type

Low List

Medium

STQR, FEAT

High Low Medium List

FUNC, SUPL

High Proposed Under Review List

Approved

FEAT, FUNC, SUPL

Incorporated

Production

Difficulty

Release

Stability

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

FEAT, FUNC, SUPL

Unknown Set during project initiation FEAT, FUNC, SUPL, STQR

Multi-list

List

Low

FEAT, FUNC, SUPL

Medium

Page 16 of 39

Date Modified:

4/2/2013


Attribute

Description regarding a requirement.

Type

List Values

Requirement Type

High

Defect

This attributes is integrated with the Project Asset DB

CQ Integration

TM Test Plan

This attribute is integrated with the Project Asset TM Test Plan Record

CQ Integration

TM Test Case

This attribute is integrated with the Project Asset TM Test Case Record

CQ Integration

TM Configured Test Case

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

CQ Integration

This allows you to submit defects from CQTM or REQPRO

Page 17 of 39

Date Modified:

4/2/2013


Attribute

Assigned to

Description The analyst in charge of eliciting, organizing, documenting, and managing this requirement. This could also be set to indicate a vendor’s responsibility.

Type

List Values

Requirement Type

Set during project initiation List

Additional information that helps describe the type or category of a supplemental requirement. Business Rule is the default setting for this attribute.

FUNC, SUPL

Business Rule Usability Reliability Performance Supportability Application Infrastructure

Category

List

Integration / Interface

SUPL

Operational Regulatory / Legal Technical Constraint Security Testing Training

Enhancement

Associated ClearQuest Enhancement Record

ClearQuest

FEAT, FUNC, SUPL

Defect

Associated ClearQuest Defect Record

ClearQuest

FEAT, FUNC, SUPL

Obsolete

Requirement has been removed from the system.

T/F

FUNC, SUPL

Project Identifier

The Project ID or name that is

Multi-List

Set during project

FEAT, FUNC, SUPL

Page 18 of 39

Date Modified:

4/2/2013


Attribute

Description modifying this requirement.

Type

List Values

Requirement Type

initiation

Page 19 of 39

Date Modified:

4/2/2013


Attribute

CTQ (Critical to Quality)

Notes Requirement Source Impacted Area

3.1.4

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

Requirement Type

Set during Discovery FEAT, FUNC, SUPL,

T/F

STQR

n/a

STQR, FEAT, FUNC, SUPL

n/a


n/a


List Values

Attribute

Value

Description

Low

Nice to have, could have, negotiable.

Medium

Important but not urgent. Should have. Used in support of additional functionality surrounding high priority requirements.

High

Project would not exist without it.

Low

Can be designed, developed, and tested later in the project

Medium

Not important as to when it is designed, developed, and tested

High

Should be designed, developed, and tested early in the project

TM Test Plan

Selection

Select Test Plan to integrate a requirement with

TM TestCase

Selection

Select Test case to integrate a requirement with.

TM Configured Test Case

Selection

Select the Configured Test case to integrate a requirement with

Business Priority

Project Priority

Medium

Not important as to when it is designed, developed, and tested

High

Should be designed, developed, and tested early in the project

Baselined

Requirement has been reviewed and is approved for this release.

Incorporate d

Incorporated and tested in a build in one of the development or test environments

Page 20 of 39

Date Modified:

4/2/2013


Attribute

Value

Description

Production

Reflects the current state of the requirement – it is in production

High

Affects many components and interfaces and involves significant engineering effort. High technical risk.

Medium

Affects a few components and a few interfaces. May involve much coding, but in familiar areas of the application. Not much risk.

Low

Affects just one component and only one interface. For example, a change to a report or a new report on existing data. Minimal risk.

Use Case

Functional requirements that are either a use case name or use case steps

Category - FUNC

Other

Functional requirement that is not expressed in a use case, but is required for the project.

Category - SUPL

Business Rule

Difficulty

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 ru les 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: •

Usability

• • •

User Interface Requirements System Help Requirements Understandability

Page 21 of 39

Date Modified:

4/2/2013


Attribute

Value Reliability

Description Reliability requirements to be considered are: • • • • • • •

Issue

Mean Time Between Failure (MTBF) Accuracy Predictability Disaster Recovery Business Recovery Failover Availability

High Medium Low

Page 22 of 39

Date Modified:

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: • • • •

Category – SUPL(continued)

Supportabil ity

Supportability requirements may include: • • • • • • • •

Technical Constraint

Application

Efficiency Throughput Response Time System Management

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 • •

Data

Consider: Data storage • Data volume • • Data retention Data replication • • Data conversion

Infrastructu re

• • •

Desktop Network Additional environments

Integration/ Interface

An integration/interface requirement specifies: • Software Integration/Interfaces • Hardware Integration/Interfaces

Regulatory/ Legal Security Testing

Requirements dictated by Regulators or Legal entities. Specifies any training requirements for the project. Specifies any training requirements for the project.

Training

Specifies any training requirements for the project.

Operational

Specifies any Operational area requirements for the project.

Page 23 of 39

Date Modified:

4/2/2013


Attribute

Value Vendor Base – Out of the Box

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.

Low

Requirement is not well understood or is likely to change before the end of the project. These should not be approved.

Medium

Requirement is well understood, but may change once a user sees the systems. These are typically candidates for UI prototypes.

High

Requirement is well understood by the assigned analyst. However, it may still not be documented sufficiently to be approved.

Stability

3.2

Description

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

3.2.1

Traceability Criteria for Requirements

TERM

NEED

BUC BR

FEAT

DAP

FUNC: UC

SUPL + FUNC: Other

ACT

Page 24 of 39

Date Modified:

4/2/2013


3.2.2

Types

Requirement Type

Trace Guidelines

STQR: Stakeholder Need

Trace to: FEAT, DAP

FEAT: Product Feature

Trace to: FUNC (UC), SUPL, DAP

Trace from: none

Trace from: FEAT

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)

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:

4/2/2013

Requirements Management Plan Trace from: FEAT, ACT

Page 26 of 39

Date Modified:

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

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

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.

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:

4/2/2013


3.3.2

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.

3.3.3

Package Name: Functional Area 1 Description: Replace the name of this package with the n ame 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.

3.3.4

Package Name: Actors Description: List of actors for this functional area

3.3.5

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.

3.3.6

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.

3.3.7

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.

3.3.8

Package Name: Glossary Description: This package contains glossary information for the project.

3.3.9

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.

3.3.10

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.

3.3.11

Package Name: Views Description: All views should be created in this package.

3.3.12

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.

3.3.13

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.

Page 28 of 39

Date Modified:

4/2/2013


3.3.14

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.

3.3.15

Package Name: Private Views Description: Put any private views in this package (e.g. all requirements for the project).

3.4

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: •

•

•

3.4.1

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.

Views

The following are views available :: View Name

Description

Requirement Type(s)

View Type(s)

Location

Attributes

All Stakeholder Needs (STQR)

Displays the various attributes associated with all Stakeholder Needs

STQR

Attribute Matrix

Views  Attribute Matrices

All Features (FEAT)

Displays the various attributes associated with all Features

FEAT

Attribute Matrix


All Functional Requirements (FUNC)

Displays the various attributes associated with all Functional Requirements

FUNC

Attribute Matrix


All Functional Requirements: Use Cases (FUNC: UC)

Displays the various attributes associated with all Functional Requirements filtered by Category: Use Case

FUNC: UC

Attribute Matrix


Category = Use Case

All Functional Requirements: Other (FUNC: Other)

Displays the various attributes associated with all Functional Requirements filtered by Category: Other

FUNC: Other

Attribute Matrix


Category = Other

All Supplemental Requirements (SUPL)

Displays the various attributes associated with all Supplemental Requirements

SUPL

Attribute Matrix


Page 29 of 39

Date Modified:

4/2/2013

Requirements Management Plan All Supplemental Requirements: Business Rules (BR)

Displays the various attributes associated with all Supplemental Requirements filtered by Category: Business Rule

BR

Attribute Matrix


All Business Use Cases (BUC)

Displays the various attributes associated with all Business Use Cases

BUC

Attribute Matrix


All Terminology (TERM)

Displays the various attributes associated with all project terminology

TERM

Attribute Matrix


All Actors (ACT)

Displays the various attributes associated with all Actors

ACT

Attribute Matrix


All Dependent Application Proxies (DAP)

Displays the various attributes associated with all Dependent Application Proxies

DAP

Attribute Matrix


NEEDs traced to FEATs

Stakeholder Needs traced to Features

NEED

Traceability Matrix

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

FEAT

Traceability Tree NEEDs not traced to FEATs

Stakeholder Needs not traced to Features

NEED FEAT

Traceability Matrix Traceability Tree

NEEDs traced to DAPs

Stakeholder Needs traced to Dependent Application Proxies

NEED

FEATs traced to FUNC: UC

Features traced to Functional Requirements filtered by Category: Use Case

FEAT

FEATs not traced to FUNC: UC

Features not traced to Functional Requirements filtered by Category: Use Case

FEAT

FEATs traced to FUNC: Other

Features traced to Functional Requirements filtered by Category: Other

FEAT

FEATs not traced to FUNC: Other

Features not traced to Functional Requirements filtered by Category: Other

FEAT

FEATs traced to SUPLs

Features traced to Supplemental Requirements

FEAT

DAP

FUNC: UC

FUNC: Other

Views  Coverage Analysis  Coverage Analysis Matrices

Traceability Matrix


Category = Use Case

Traceability Matrix


Category = Use Case

Traceability Matrix


Category = Other

Traceability Matrix


Category = Other

Traceability Matrix


Traceability Tree

FUNC: Other

SUPL


Traceability Matrix

Traceability Tree

FUNC: UC

Category = Business Rule

Traceability Tree

Page 30 of 39

Date Modified:

4/2/2013

Requirements Management Plan FEATs not traced to SUPLs

FEATs traced to FEATs

Features not traced to Supplemental Requirements

FEAT

Features traced to Features

FEAT

SUPL


FEAT


FEATs traced to DAPs

Features traced to Dependent Application Proxies

FEAT

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

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

FEAT

Functional Requirements filtered by Category: Use Case traced to Supplemental Requirements

FUNC: UC

Functional Requirements filtered by Category: Use Case not traced to Supplemental Requirements

FUNC: UC

Functional Requirements filtered by Category: Other not traced to Supplemental Requirements

FUNC: Other

FUNC: Other not traced to SUPLs

Functional Requirements filtered by Category: Other not traced to Supplemental Requirements

FUNC: Other

FUNC: UC traced to DAPs

Functional Requirements filtered by Category: Use Case traced to Dependent Application Proxies

FUNC: UC

FUNC: Other traced to DAPs

Functional Requirements filtered by Category: Other traced to Dependent Application Proxies

FUNC: Other

SUPLs traced to SUPLs

Supplemental Requirements traced to Supplemental Requirements

SUPL

FUNC: UC traced to SUPLs

FUNC: UC not traced to SUPLs

FUNC: Other traced to SUPLs

DAP

BUC

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

Traceability Matrix


Traceability Tree

Views  Coverage Analysis  Coverage Analysis Trees

Traceability Matrix


Category = Use Case


Category = Use Case


Category = Other


Category = Other

Traceability Matrix


Category = Use Case

Traceability Matrix


Category = Other

Traceability Matrix


FUNC SUPL DAP

SUPL

Traceability Tree

SUPL


SUPL


SUPL


DAP

DAP

SUPL

Traceability Tree

Page 31 of 39

Date Modified:

4/2/2013

Requirements Management Plan SUPLs traced to DAPs

Supplemental Requirements traced to Dependent Application Proxies

SUPL

BUCs traced to FUNC: UC

Business Use Cases traced to Functional Requirements filtered by Category: Use Case

BUC

BUCs not traced to FUNC: UC

Business Use Cases not traced to Functional Requirements filtered by Category: Use Case

BUC

ACTs traced to FUNC: UC

Actors traced to Functional Requirements filtered by Category: Use Case

ACT

ACTs not traced to FUNC: UC

Actors not traced to Functional Requirements filtered by Category: Use Case

ACT

FEATs traced from NEEDs

Features traced from Stakeholder Needs

FEAT

DAP

FUNC: UC

Traceability Matrix


Traceability Matrix


Category = Use Case

Traceability Matrix


Category = Use Case

Traceability Matrix


Category = Use Case

Traceability Matrix


Category = Use Case

Traceability Matrix

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

Traceability Tree

FUNC: UC

FUNC: UC

Traceability Tree

FUNC: UC

NEED

Traceability Tree FEATs not traced from NEEDs

Features not traced from Stakeholder Needs

FEATs traced from FEATs

Features traced from Features

FEAT NEED


FEAT FEAT


FUNC: UC traced from FEATs

Functional Requirements filtered by Category: Use Case traced from Features

FUNC: UC

FUNC: UC not traced from FEATs

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

FUNC: UC

FUNC: Other traced from FEATs

Functional Requirements filtered by Category: Other traced from Features

FUNC: Other

FUNC: Other not traced from FEATs

Functional Requirements filtered by Category: Other not traced from Features

FUNC: Other

FEAT


FEAT


FEAT


FEAT


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


Category = Use Case


Category = Other


Category = Other

Page 32 of 39

Date Modified:

4/2/2013

Requirements Management Plan FUNC: UC traced from ACTs

Functional Requirements filtered by Category: Use Case traced from Actors

FUNC: UC

FUNC: UC not traced from ACTs

Functional Requirements filtered by Category: Use Case not traced from Actors

FUNC: UC

FUNC: UC traced from BUCs

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

FUNC: UC

FUNC: UC not traced from BUCs

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

FUNC: UC

FUNC: UC not traced from BUC / FEAT / ACT

Functional Requirements filtered by Category: Use Case not traced from Business Use Cases, Features, or Actors

FUNC: UC

Functional Requirements filtered by Category: Other not traced from Functional Requirements (Use Case and/or Other), Supplemental Requirements, or Features

FUNC

Supplemental Requirements traced from Features

SUPL

SUPLs not traced from FEATs

Supplemental Requirements not traced from Features

SUPL

SUPLs traced from FUNC: UC

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

SUPL

SUPLs not traced from FUNC: UC

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

SUPL

SUPLs traced from FUNC: Other

Supplemental Requirements traced from Functional Requirements filtered by Category: Other

SUPL

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

SUPLs traced from FEATs

ACT


Category = Use Case


Category = Use Case


Category = Use Case


Category = Use Case

Traceability Tree

Views  Traceability Analysis  Traceability Analysis Trees

Category = Use Case

Traceability Tree


Category = Other

Traceability Matrix



ACT


BUC


BUC


BUC FEAT ACT

FUNC SUPL FEAT

FEAT

Traceability Tree

FEAT


FUNC: UC


Category = Use Case

Traceability Matrix

Views  Traceability Analysis  Traceability Analysis Matrices

Category = Use Case

Traceability Matrix


Category = Other


FUNC: UC

FUNC: Other


Traceability Tree

Page 33 of 39

Date Modified:

4/2/2013

Requirements Management Plan SUPLs not traced from FUNC: Other

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

SUPL

SUPLs traced from SUPLs

Supplemental Requirements traced from Supplemental Requirements

SUPL

Supplemental Requirements not traced from Supplemental Requirements, Functional Requirements (Use Case and/or Other), or Features

SUPL

DAPs traced from NEEDs

Dependent Application Proxies traced from Stakeholder Needs

DAP

DAPs traced from FEATs

Dependent Application Proxies traced from Features

DAP

DAPs traced from FUNC:UC

Dependent Application Proxies traced from Functional Requirements filtered by Category: Use Case

DAP

DAPs traced from FUNC: Other

Dependent Application Proxies traced from Functional Requirements filtered by Category: Other

DAP

DAPs traced from SUPLs

Dependent Application Proxies traced from Supplemental Requirements

DAP

FEATs traced to FEATs

Features traced to Features

FEAT

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

FUNC: Other

SUPL

Traceability Matrix


Traceability Matrix


Traceability Tree

SUPL

Category = Other

Traceability Tree


Traceability Matrix


Traceability Matrix


Traceability Matrix


Category = Use Case

Traceability Matrix


Category = Other

Traceability Matrix


Traceability Matrix


FUNC FEAT

NEED

FEAT

FUNC: UC

FUNC: Other

SUPL

FEAT

Traceability Tree FEATs traced to DAPs

Features traced to Dependent Application Proxies

FEAT

FEATs not traced to BUC / FUNC / SUPL / DAP

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

FEAT

DAP

BUC

Traceability Matrix


Traceability Tree

Views  Coverage Analysis  Coverage Analysis Trees

FUNC SUPL DAP

Page 34 of 39

Date Modified:

4/2/2013

Requirements Management Plan FUNCs traced to SUPLs

Functional Requirements traced to Supplemental Requirements

FUNC

Functional Requirements not traced to Supplemental Requirements

FUNC

FUNCs traced to DAPs

Functional Requirements not traced to Dependent Application Proxies

FUNC

SUPLs traced to SUPLs

Supplemental Requirements traced to Supplemental Requirements

SUPL

SUPLs traced to DAPs

Supplemental Requirements traced to Dependent Application Proxies

SUPL

BUCs traced to FUNC: UC

Business Use Cases traced to Functional Requirements filtered by Category: Use Case

BUC

Business Use Cases not traced to Functional Requirements filtered by Category: Use Case

BUC

Actors traced to Functional Requirements

ACT

Actors not traced to Functional Requirements

ACT

FUNCs not traced to SUPLs

BUCs not traced to FUNC: UC

ACTs traced to FUNCs

ACTs not traced to FUNCs

SUPL


SUPL


DAP

SUPL

FUNC: UC


Traceability Matrix


Traceability Matrix


Traceability Matrix


Category = Use Case


Category = Use Case

Traceability Tree

FUNC: UC


FUNC


FUNC


Traceability Matrix

Traceability Tree

DAP



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

Page 35 of 39

Date Modified:

4/2/2013


View Name

Description

Requirement Type(s)

View Type(s)

Location

FEATs traced from NEEDs

Features traced from Stakeholder Needs

FEAT

Traceability Matrix


NEED

Traceability Tree FEATs not traced from NEEDs

Features not traced from Stakeholder Needs

FEATs traced from FEATs

Features traced from Features

FEAT NEED


FEAT FEAT


FUNCs traced from FEATs

Functional Requirements traced from Features

FUNC

FUNCs not traced from FEATs

Functional Requirements not traced from Features

FUNC

FUNCs traced from ACTs

Functional Requirements traced from Actors

FUNC

FUNCs not traced from ACTs

Functional Requirements not traced from Actors

FUNC

FUNC: UC traced from FEATs

Functional Requirements filtered by Category: Use Case traced from Features

FUNC: UC

FUNC: UC not traced from FEATs

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

FUNC: UC

FUNC: UC traced from BUCs

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

FUNC: UC

FUNC: UC not traced from BUCs

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

FUNC: UC

View Name

Description

Requirement Type(s)

FEAT


FEAT


ACT


ACT


FEAT

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


Category = Use Case

Category = Use Case

Traceability Tree


View Type(s)

Location

Attributes

Traceability Matrix


BUC


Category = Use Case

Traceability Tree

BUC




FEAT

Attributes

Traceability Matrix

Page 36 of 39

Date Modified:

4/2/2013

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

FUNC: UC

FUNC: Other traced from FEATs

Functional Requirements filtered by Category: Other traced from Features

FUNC: Other

FUNC: Other not traced from FEATs

Functional Requirements filtered by Category: Other not traced from Features

FUNC: Other

FUNC: Other not traced from FUNC / SUPL / FEAT

Functional Requirements filtered by Category: Other not traced from Functional Requirements, Supplemental Requirements, or Features

FUNC: Other

Supplemental Requirements traced from Features

SUPL

SUPLs not traced from FEATs

Supplemental Requirements not traced from Features

SUPL

SUPLs traced from FUNCs

Supplemental Requirements traced from Functional Requirements

SUPL

SUPLs not traced from FUNCs

Supplemental Requirements not traced from Functional Requirements

SUPL

SUPLs traced from SUPLs

Supplemental Requirements traced from Supplemental Requirements

SUPL

SUPLs traced from FEATs

BUC

Traceability Tree


Category = Use Case

Traceability Matrix


Category = Other


Category = Other

Traceability Tree


Category = Other

Traceability Matrix


FEAT ACT

FEAT

Traceability Tree

FEAT


FUNC SUPL FEAT

FEAT

Traceability Tree

FEAT


FUNC


FUNC


SUPL


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

Page 37 of 39

Date Modified:

4/2/2013


3.4.2

View Name

Description

Requirement Type(s)

View Type(s)

Location

SUPLs not traced from SUPL / FUNC / FEAT

Supplemental Requirements not traced from Supplemental Requirements, Functional Requirements, or Features

SUPL

Traceability Tree


DAPs traced from NEEDs

Dependent Application Proxies traced from Stakeholder Needs

DAP

Traceability Matrix


DAPs traced from FEATs

Dependent Application Proxies traced from Features

DAP

Traceability Matrix


DAPs traced from FUNCs

Dependent Application Proxies traced from Functional Requirements

DAP

Traceability Matrix


DAPs traced from SUPLs

Dependent Application Proxies traced from Supplemental Requirements

DAP

Traceability Matrix


SUPL

Attributes

FUNC FEAT

NEED

FEAT

FUNC

SUPL

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

Attribute Value Range

Example: Status = incorporated, approved

Obsolete = False

Obsolete = False

Page 38 of 39

Requirement Management Plan

Recommend Documents