Requirements Management Process

The requirements management process provides a framework to ensure that software products
meet their requirements and provide value to the user.

The objectives of the requirements management process are:

To ensure that requirements for the software product are defined and understood.

To establish and maintain agreement on the requirements with the requestor (external
customer, marketing, or another internal organization)

To ensure that the requirements are met.

In addition, requirements shall be documented and controlled to establish a basis for software
development and for project management use. Changes to requirements shall be documented
and controlled to ensure plans, deliverables, and activities are consistent with requirements.

All technical and non-technical requirements must be documented. The Requirements

Document Template is used to record the requirements along with the corresponding acceptance
criteria. Requirements are managed throughout the software development lifecycle via the
Configuration Management Process, which serves to establish a baseline for the requirements
once they have been reviewed and agreed upon. Each projects Requirements Document is
subject to review and audit via the Software Quality Assurance Process. This ensures
compliance with the applicable requirements management processes and procedures.

Initial requirements definition is necessary to establish the scope and basic functionality of a
system. This preliminary requirements gathering and definition may differ by project. For
enhancement and maintenance projects, a formal Configuration Control Board may be in place to
review and approve the requirements. For new or replacement systems, customer
meetings/telecons are used to discuss and approve initial customer requirements. These
requirements serve as input to obtain initial approval to proceed with the project. Initial
requirements should be stored in a requirements log within the Project Management Workbook.
Once a project is formally initiated, these preliminary requirements will be transferred from the
requirements log and documented in greater detail using the Requirements Document Template.

ENTRANCE CRITERIA: Initial requirements have been defined, and approval has been
received from senior management and the customer to proceed with the project. Funding is
either approved for the entire project, or for the next phase of the lifecycle.

<insert document name> Page 1 <insert revision date>

ACTIVITIES:

Step 1 Step 2 Step 3 Step 4 Step 5 Step 6 Step 7 Step 8

Gather Documen Analyze Approve Trace Manage Validate Reqs.
Reqs. t Reqs. Reqs. Reqs. Reqs. Reqs. Reqs. Metrics

STEP ACTIVITY DESCRIPTION RESPONSIBLE

ROLE

<insert document name> Page 2 <insert revision date>

STEP 1 Assemble the preliminary system requirements Project Lead,
Gather Requirements from available sources including, but not limited Business Area
to: Analysts, Systems
Meeting Minutes from initial reviews with Analysts
the customer;
Requirements log;
Emails from the customer;
Business needs documents that explain
desired functionality;
Existing legacy systems and associated
documentation;
Customer policy or procedure documents,
change requests, problem reports; system
prototypes; or
Formal Requirements Specifications,
should they exist.
STEP 2 Document the requirements using the established Project Lead,
Document Requirements Requirements Document Template. The Systems Analysts
Requirements Document Template contains
embedded instructions to guide the
documentation procedure. The template allows
for increasing levels of detail to be captured as
the requirements are analyzed in step 3 below. It
also allows for versioning as the requirements are
reviewed and modified.
STEP 3 The goal of the requirements analysis process is Project Lead,
Analyze Requirements to ensure that the requirements are complete, Systems Analysts,
clearly and properly stated, consistent, and Technical Analysts
testable. This process includes analyzing:

Both functional and technical

requirements to understand scope;
Functional boundaries, inputs, outputs,
calculations, data transformations;
Computer resource thresholds including
expected response times, memory usage,
storage required, and equipment types.

The Requirements Document produced initially

in step 2 above, is revised as needed during the
requirements analysis phase, and a document
version date applied as needed.

Consider using the Requirements Management

Checklist as a tool during this phase to assist in
the assessment of the clarity, feasibility, and

<insert document name> Page 3 <insert revision date>

 thoroughness of the requirements.

<insert document name> Page 4 <insert revision date>

STEP 4 Gain approval of the Requirements Document via CCB Team
Approve Requirements formal review with the CCB per the
Configuration Management Process.
STEP 5 The goal of this process is to ensure that approved Project Lead,
Trace Requirements requirements are tracked throughout the Software
development phases so that the functionality of Development Team
all baselined requirements is included in the final
work products. Trace the requirements from the
software design phase through to the
development of test scripts.

Use the Requirements Document to

develop the software design.
Continue using the Requirements
Document and the technical design to
develop the test scripts.

Consider using a Requirements Traceability

Matrix to assist in this process.
STEP 6 Any modifications, additions, or deletions to the Project Lead, CCB
Manage Requirements approved requirements must be controlled. Team, Software
Changes to approved requirements require the Development Team
repetition of all prior steps in the requirements
management process documented above in order
to assess impact to all project work products.
Tools to consider using to manage changes to
requirements include SNAFU or the Project
Management Workbook. These activities include:
Gathering new, changed, and/or deleted
requirements;
Analyzing the new and changed
requirements;
Assessing the impact of these
requirements related to the other
requirements;
Assessing the impact to project
commitments;
Assessing the impact to the work
products;
Updating documents as required;
Gaining approval from the associated
team members, senior management, and
the client;
Updating the requirements management
log to indicate the allocation of
requirements to a specific baseline.

<insert document name> Page 5 <insert revision date>

STEP 7 Validate that the requirements have been fulfilled Project Lead, CCB
Validate Requirements through conducting System Testing, and Team, Software
Customer Acceptance Testing. Once testing has Development Team
been completed and all issues have been resolved,
obtain approval from the CCB to proceed to
production. Once the system goes into
production, a designated project representative
conducts a production verification to determine
whether the system is operating per the customer
requirements.
STEP 8 Process measurements must be made and used to Project Lead
Requirements Metrics determine the status and quality of the
requirements management activities. All projects
must collect the following metrics:

Actual versus planned effort and schedule

for Requirements Management activities;
Status of each requirement (allocated or
unallocated and the associated baseline, if
allocated);
Change activity for each requirement,
when requirements change, and the root
cause for the change.

Budget and schedule metrics will be

automatically obtained as part of the Project
Planning and Management Process. Status of
requirements and change activity should be
obtained as part of the Configuration
Management Process.

OUTPUTS:
Requirements Document
CCB Meeting Minutes

EXIT CRITERIA: The Requirements Document has been approved, baselines have been
established, and the requirements have been traced and validated through the testing and
acceptance phases of the software development life cycle. The production system has been
validated to determine that all customer requirements have been met and are operating as
expected.

<insert document name> Page 6 <insert revision date>