Requirements Management

Capture Requirements

Capture the requirements to manage them throughout the project lifecycle and for re-use into the future. The level of a requirement may identify the appropriate attributes that should be captured. For example, associated costs may not be a realistic attribute for a detailed system requirements, but support prioritization for a high-level Business requirement. For each requirement, identify and record information (attributes) about the requirement that is relevant to the project. The List of Commonly Used Requirements Attributes at right lists some common attributes that are often included in a requirements repository and include the appropriate requirement level where it makes sense to capture the attribute. Please note that these attributes represent general guidelines and should be adjusted for the project scope.

Attribute

Description

High-

Level

Mid-

Level

Detail

(Testable)

Unique ID

A unique identifier for the requirement

X

X

X

Date Created

Date the requirement was first captured

X

X

X

Source/Ownership

Name of the person, organizational division, or change request where the requirement came

X

X

 

Functionality

Functional capability or constraint (Non-Functional category)

 

X

X

Requirement Type

Functional/Business, Non-Functional/Technical,Transition, Stakeholder,...

X

X

X

Requirement

Concise description of requirements expressed in business terminology to ensure common understanding

X

X

X

Status

Reflects the current state of the requirement. Examples: Proposed, In Review. Approved, Denied. Verified. Implemented

X

X

 

Priority

Indicates the importance of the requirement (Critical, High, Medium. Low)

X

X

 

Rationale/Origin

Reflects backward (originating source) traceability and justifies the requirement

X

X

X

Difficulty/Complexity

Qualitative measure of how difficult the requirement is to implement

 

X

 

Stability

Indicates how mature the requirement is - can it be worked on?

X

X

 

Test Case ID

Reflects forward traceability to validation test case used during the Acceptance phase of

 

 

X

Assigned to

The person responsible for completing the requirement

 

X

 

Risk

Assigned based on the expected associated level of effort and/or complexity/difficulty

 

X

 

Impact

Business or technical effect of implementing this requirement

X

X

 

Due Dote

Target date for the deliverable associated with the requirement

 

X

 

Stakeholders

Identified business staff responsible for approving changes that impact the requirement

 

X

 

Approved By

Person who approved this requirement

 

X

 

Approval Dote

Date the requirement was approved

 

X

 

Release Number/Build

Application release number targeted for the implementation of this requirement

 

X

X

Dependencies

Identification of other system elements and/or requirements that may be impacted by changes to this requirement

 

X

 

Comments

Text field available for analyst, approver, etc. notes related to this requirement

X

X

 

Verification

Specification of how this requirement will be tested (e.g., demo, analysis, inspection, walkthrough, QA test scripts/test cases)

 

X

 

Subsystem(s)

Applications/systems where this requirement will be implemented

X

X

 

Actual Iteration

Identifies the Actual, rather than the Planned iteration (Release Number/Build) where the requirement was implemented

 

 

 

Revision Number

Used to track different versions of the requirement

 

X

 

Cost

Quantified cost attributable to this requirement

X

X

 

Defect

ID(s) of any associated defect(s)

 

 

X

Obsolete

Indicates that the requirement has been removed/is no longer active

X

X

X

Benefit

Need or gaol that this requirement supports

X

 

 

ROI/ROE

Associated return on investment/effort/... that may be expected when this requirement is implemented

X

 

 

List of commonly used Requirements Attributes



Word processing documents are often good vehicles for communicating requirements across the project's stakeholder groups. But using a document-based approach to managing requirements introduces issues that can be avoided by storing requirements, and requirement attributes, in a spreadsheet, simple database, or other requirements management tool. These issues include:

  • Documents are difficult to keep current
  • Changes to requirements become hard to communicate
  • Information needed to manage requirements is difficult to store and use
  • It is difficult to trace the requirements to other project artifacts


What should be the extent and level of requirements captured? This is generally determined on a case-by-case basis. It depends on various factors, including the nature of the business, the stakeholders who are involved, the complexity/scope of the deliverables, and the project management methodology. A project that involves implementing an off-the-shelf application, for example, would generally not document all requirements as extensively as a project that is charged with integrating the information from multiple databases. Each project must determine the appropriate level of requirements definition based on the project deliverables.

The level at which requirements are captured should be driven by the project complexity and environment. At a minimum, the high-level business requirements must be captured. These requirements clearly and concisely state the needs and goals of the solution, providing a common understanding across stakeholder groups. They represent the foundation for validation of the solution during the quality assurance activities performed before release. They provide the source for 'backward traceability' of the detailed requirements that are implemented.

During the requirements definition phase of a project, the Functional and Non-Functional, or Business and Technical, requirements are identified and refined. These types of requirements may be captured at a very detailed level (e.g., UI, User, Stakeholder, etc.) or at a higher level which only encapsulates the 'why' and 'what' of the solution. Each lower-level requirement should be directly associated with the high-level business requirement that it supports. This ensures complete validation of the solution.

Transitional requirements may also be needed to cover the cut-over from the existing processes/applications to the new solution that the project will deliver.

Functional/Business define the behavior and capabilities of an application, the information that the application will manage, and the required inputs/outputs. These requirements must take into account how a business operates, the improvements and changes necessary to support the project goals and needs, and incorporate any existing constraints that must be supported.
Non-Functional/Technical must support, and be supported by the environmental conditions under which the application must remain effective. They include the qualities that the application must have. They encompass criteria related to performance, scalability, security, usability, system availability, and the underlying information architecture.
Transitional exist only during the transition from the 'As-Is' state to the 'To-Be' state of the project deliverables and are not identified until the system is designed. They include data transformation, user training, and other transition needs that must be supported during the implementation of the solution.