Requirements Management
Procedure
OETI-PMP-07
Environmental Protection Agency
Office of Enterprise Technology and Innovation (OETI)
January 10, 2007 - Version 1.0
-------
Office of Enterprise Technology and Innovation
Requirements Management Procedure OETI-PMP-07
Document Change History
//
1/10/2007- Version 1.0
-------
Office of Enterprise Technology and Innovation
Requirements Management Procedure OETI-PMP-07
Contents
1. Introduction 1
1.1 Purpose 1
1.2 Background 1
2. Approach 3
2.1 Assumptions 3
2.2 Scalability 3
2.3 Best Practices 4
3. Roles and Responsibilities 5
4. Procedure 7
4.1 Process Flow Diagram 7
4.2 Steps 7
4.2.1 Develop Requirements Management Plan 7
4.2.2 Perform Requirements Identification and Analysis 9
4.2.3 Develop/Update the Requirements Traceability Matrix (RTM) and Related Documents. 11
4.2.4 Conduct Peer Reviews on Documentation 11
4.2.5 Obtain Appropriate Stakeholder Approval for Requirements Work Products 12
4.2.6 Place Requirements under Configuration Management Control 12
4.2.7 Manage Requirements Changes 12
5. Considerations 14
Appendix A Acronyms A-1
Appendix B Requirements Management Checklist B-1
Appendix C Additional Resources C-1
Appendix D Interface Requirements D-1
Appendix E Requirements Management Plan Template E-1
Appendix F Common Requirements Problems and Solutions F-1
Appendix G Requirements Traceability Matrix Template G-1
//
/
1/10/2007- Version 1.0
-------
Office of Enterprise Technology and Innovation
Requirements Management Procedure OETI-PMP-07
1. Introduction
This document defines the process by which staff within the Environmental Protection Agency
(EPA)'s Office of Enterprise Technology and Innovation (OETI) performs requirements management
(RM).
1.1 Purpose
This document defines the methodology, process flow, and relevant standards by which OETI project
staff performs RM activities and identifies participants and their responsibilities.
1.2 Background
A requirement is defined by the Project Management Institute (PMI) as "a condition or capability that
must be met or possessed by a system, product, service, result or component to satisfy a contract,
standard, specification or other formally imposed document."1 Requirements are the desired
characteristics of the deliverable being produced, whether it is a system, work product, or service. If
defined for a project, requirements form the basis for estimating all project activities, planning and
tracking those activities, and creating the work products and services. Requirements include the
quantified and documented needs, desires, and expectations of a project's customers and other
stakeholders. The RM process involves establishing and maintaining an understanding and
agreement between the project team and all relevant customers and stakeholders on the
requirements for a project throughout the project life cycle. The agreement includes technical and
non-technical requirements and forms the basis for estimating, planning, performing, and tracking the
project's activities throughout the project life cycle.
The development of business and functional requirements and RM begin during the planning process
of a project as described in PMP-02 Project Initiation and Planning Procedure and may be a driver for
initiating a new project. Although there is typically a specific requirements analysis phase within a
project, requirements are not static; the project team or customer may add, delete, or modify
requirements during the execution of the project. Therefore, RM is performed throughout the project
life cycle, from initial planning and identification to project close out. While changes to requirements
may be made at any point in the project's life cycle, any changes required once they are baselined are
managed through the Change Control Process (Refer to PMP-08 Change Control Procedure for
details on the process).
Business requirements list the features or specifications that the final solution should provide to meet
a project's business objectives. Types of business requirements may include but are not limited to the
following:
¦ Functionality
¦ Usability
¦ Reliability
¦ Performance
¦ Supportability.
1
Project Management Institute, The Project Management Body of Knowledge (PMBOK®), Third Edition. 2004
Glossary, p. 371.
1
1/10/2007- Version 1.0
-------
Office of Enterprise Technology and Innovation
Requirements Management Procedure OETI-PMP-07
Functional requirements should include information necessary to provide a complete representation of
the proposed product or service. These requirements could include narrative descriptions, screen
layouts, process flows, data flows, etc. Readers of functional requirements should be able to envision
how the new process, product, or system will work.
Scope describes the boundaries of the project. It defines what the project will deliver and what it will
not deliver. The boundaries of a project may be expressed in some combination of geography,
organization, applications, and/or business functions. For larger projects, it can include the
organizations affected, the transactions affected, the data types included, etc. The scope of a project
may contain many deliverables, each of which may have its own set of requirements.
2
1/10/2007- Version 1.0
-------
Office of Enterprise Technology and Innovation
Requirements Management Procedure OETI-PMP-07
2. Approach
This section explains the approach used to develop this RM procedure. It details the degree of
scalability of this procedure, and the industry standards, best practices, and EPA current practices
consulted in creating this procedure.
2.1 Assumptions
The following assumptions guide this RM procedure:
¦ A Requirements Manager will be appointed by the Project Manager who has familiarity with
requirements management practices. Requirements may or may not be the Requirement
Manager's only responsibility, depending on the size, scope, and complexity of the project.
¦ The Requirements Manager will maintain documents using the document management
procedures and tools defined for the project. (See PMP-12 Document Management
Procedure.)
¦ All OETI information technology (IT) projects are required to use and follow this procedure. In
addition, for agency system projects, the Office of Environmental Information (OEI) System
Life Cycle Management (SLCM) policy and procedures apply.
¦ Non-IT projects which require definition and management of requirements may adapt this
procedure based on what is described in the scalability section below.
2.2 Scalability
As part of the project initiation and planning activities defined in PMP-02 Project Initiation and
Planning Procedure, the Project Manager determines whether RM applies to the project and if so, the
extent to which the procedure should be implemented. The most significant factor used for
determining whether RM applies is whether a distinct set of requirements has been defined for the
project's outcome (deliverable, service, or product) by the customer or stakeholders. As detailed in
Table 2.1, the extent of RM procedures and the number of resources involved in the RM process is
determined by the size and complexity of the project. Therefore, projects with more requirements may
require greater management discipline to avoid unplanned scope changes. New or unique projects
may also require more effort. The criteria can be adjusted based on the unique project requirements,
especially for projects that are smaller or have lower complexity. The project team must evaluate
these unique characteristics of the project during the planning process for RM and determine how best
to adjust the procedure to address specific project risks and requirements.
Table 2.1. RM Procedure Scalability Guidelines
Procedure
Does the Procedure Apply?
Determining Procedure Scalability
OETI-PMP-07
Requirements
Management
Procedure
¦ Applies if project is an IT project
¦ Applies if a set of baseline
requirements is defined where
traceability is required
¦ Procedure is scaled based on the type of
project, whether the project is new for the
organization, the number and type of
stakeholders, and whether or not the
stakeholders are responsible for defining "what'
the project should achieve
This procedure describes the RM process and components of the process, which are flexible and can
be modified based on project size and resource constraints. The basic procedure remains the same;
however, the resources allocated and the documentation produced may increase or decrease
3
1/10/2007- Version 1.0
-------
Office of Enterprise Technology and Innovation
Requirements Management Procedure OETI-PMP-07
depending on the project's assigned complexity. The roles and responsibilities may also be modified
and be performed by more than one person.
2.3 Best Practices
The OETI vision includes the employment of best practices from both industry and the EPA. This
procedure incorporates the following best practices and existing regulations and policies:
¦ EPA regulations and standards
- EPA Directive 2100.5, System Life Cycle Management Policy. Available at:
http://intranet.epa.qov/oei/imitpolicv/qic/ciopolicv/2100.5.pdf
- The EPA Interim Agency System Life Cycle Management Procedures. Available at:
http://intranet.epa.gov/otop/policies/Extended lnterimProcedures.pdf
¦ Federal regulations, industry standards, and best practices
- Software Engineering Institute (SEI) Capability Maturity Model Integration (CMMI), CMMI
for Systems Engineering, Software Engineering, Integrated Product and Process
Development, and Supplier Sourcing, Version 1.1, CMMI-SE/SW/IPPD/SS, March 2002.
- Project Management Institute, The Project Management Body of Knowledge (PMBOK®),
Third Edition. 2004.
4
1/10/2007- Version 1.0
-------
Office of Enterprise Technology and Innovation
Requirements Management Procedure OETI-PMP-07
3. Roles and Responsibilities
Table 3-1 presents the roles and responsibilities for OETI project staff involved in requirements
management activities. This table lists functions or tasks that each project role performs. While each
role will be assigned to an individual staff member, an individual may perform multiple roles for a
project.
Table 3.1. RM Roles and Responsibilities
Role
Responsibilities
Project Manager
¦ Works with the Requirements Manager, stakeholders, and contractors, as
necessary, on requirements planning, reviewing, validating, and monitoring
¦ Works with appropriate project stakeholders to define scope of release (for
systems projects)
¦ Reviews and approves requirements artifacts
¦ Communicates requirements activities with senior project management
¦ Reviews and confirms requirement changes for scope, cost, and schedule impact
as a result of approved Change Control Board (CCB) activities
¦ Evaluates requirement changes for scope impact as part of CCB activities
Project Team Lead
¦ Works with the Requirements Manager, stakeholders, and contractors, as
necessary, on requirements planning, reviewing, validating, and monitoring
¦ Reviews requirements documentation and provides comments
¦ Reviews Requirements Traceability Matrix (RTM) and provides comments
¦ Evaluates requirement changes for scope impact as part of CCB activities
Requirements Manager
¦ Participates in capturing, defining, and documenting requirements in requirements
documentation and RTM
¦ Manages and coordinates requirements activities
¦ Manages and allocates requirements by maintaining the RTM
¦ Develops requirements specifications
¦ Captures and documents requirements measurements
¦ Participates in requirements estimation activities
¦ Reviews requirements specifications, test plans, test scenarios and high-level
design deliverables for accuracy, completeness, and thoroughness
¦ Provides input to project plans and procedures
¦ Identifies risks related to the requirements process
¦ Participates in Quality Assurance (QA) reviews and audits of project activities and
work products to ensure compliance with documented plans, procedures, and
standards
¦ Reports RM activities and status periodically to the Project Manager
Test Manager
¦ Ensures changes to requirements can be implemented and tested as stated
¦ Validates delivery of requirements by conducting relevant tests
Configuration Management
Manager
¦ Baselines the approved documents
¦ Manages changes to configurable items, including requirements
Quality Manager
¦ Reviews Requirements Document, RTM, and other documents supporting RM, as
defined in requirements planning documentation
¦ Conducts audits on RM processes and products
5
1/10/2007- Version 1.0
-------
Office of Enterprise Technology and Innovation
Requirements Management Procedure OETI-PMP-07
Role
Responsibilities
Project Team Member
¦ Participates in requirements gathering activities
¦ Communicates requirements to the Requirements Manager and participates in
documenting requirements
¦ Documents reported Change Requests (CRs) for CCB review
¦ Conducts peer review of Requirements Document and RTM
Project Stakeholders
¦ Provides input on requirements
¦ Defines project requirements
¦ Participates in user acceptance testing of releases (if system/software that
requires testing), to validate appropriate delivery against requirements
¦ Participates in acceptance of requirements
NOTE: Reviewers and appropriate stakeholders are identified by the CCB Chair,
based on the changes to the product that is under development for a particular release.
6
1/10/2007- Version 1.0
-------
Office of Enterprise Technology and Innovation
Requirements Management Procedure OETI-PMP-07
4. Procedure
This section presents the process flow for performing requirements management.
4.1 Process Flow Diagram
Figure 4-1 describes the process for RM, which originates with the development of the Requirements
Management Plan. The RM process is similar for both new and maintenance tasks. For new tasks,
the project should closely follow the RM process to ensure that the requirements baseline is adequate
to serve as the basis for the work performed during the project's life cycle. For maintenance updates
to work-products, even if the project requirements are already documented, the project should
carefully consider each step in the process, even if it does not require significant action.
Figure 4-1. RM Process
4.2 Steps
The following sections describe the steps of the requirements management process shown in Figure
4-1 and the roles involved in its execution.
4.2.1 Develop Requirements Management Plan
The purpose of the Requirements Management Plan is to describe the steps the project will follow to
define, establish and manage the requirement artifacts (Requirements Documents, Functional
Requirements Specifications [FRS], Use Cases, Concept of Operations [CONOPS], etc.,), associated
requirement types (User, System, Performance, etc.,), and their respective requirement attributes (ID,
/
1/10/2007- Version 1.0
-------
Office of Enterprise Technology and Innovation
Requirements Management Procedure OETI-PMP-07
Status, Version, etc.). A Requirements Management Plan also addresses how bidirectional
traceability will be managed. See Appendix E for a sample Requirements Management Plan
template.
Using the information available in project-defining documents created in the planning phase of the
project (see PMP-02 Project Initiation and Planning Procedure), the Project Team Lead, the
Requirements Manager, and Project Team Members identify the business objectives, scope, and
constraints for the project and generate the tasks and estimates associated with the requirements
phase. This information serves as the basis for the project and requirements planning and for
stakeholder discussions. The Requirements Management Plan also documents assumptions, known
risks, and mitigation strategies. For systems projects, the Requirements Management Plan is
developed in accordance with OEI's System Life Cycle Management (SLCM) policy and procedures
and is incorporated in the System Management Plan (SMP), a document similar to the Project
Management Plan.
4.2.1.1 Identify or Revise Requirements Sources
Preparing for the requirements collection process includes identifying individuals with a vested interest
in the outcome of the product design (stakeholders) and individuals who can provide insight into
potential deliverable uses or development methods (experts or Subject Matter Experts [SMEs]).
Legacy systems, policies, and legislation may also serve as requirements sources.
To ensure that the project collects and analyzes the full universe of potential requirements, the
Requirements Manager and Project Team Members should collect requirements from a cross-section
of stakeholders (i.e., functional users, input providers, output recipients, project officers, and software
and system engineers) assigned to implement the requirements. It is also critical to solicit input from a
cross-section of geographical locations of both senior and junior staff, as well as customers with
different skill levels.
4.2.1.2 Identify the Best Requirement-Gathering Technique
Facilitated workshops, face-to-face interviews, telephone interviews and surveys, mail surveys, screen
mock-ups, and prototypes are all useful techniques for collecting requirements. Each technique has
its strengths and weaknesses, depending on the specific project. Table 4-1 provides guidance on
selecting the appropriate technique(s) for a project environment. Systems projects can employ screen
mock up and prototype efforts as appropriate in addition to these other techniques. Employing several
data collection techniques allows project teams to balance the weaknesses and strengths of individual
techniques and take into account any cost, resource, or schedule constraints. The left column of the
table lists factors to consider when selecting a data collection technique. Each row in the table
compares and contrasts a factor across different data collection techniques. The Requirements
Manager and Project Team Members should gather data in a consistent, thorough, and efficient
manner to facilitate the acceptance of customer requirements at the end of the requirements gathering
process.
8
1/10/2007- Version 1.0
-------
Office of Enterprise Technology and Innovation
Requirements Management Procedure OETI-PMP-07
Table 4.1. Examples of Data Collection Techniques
Factor
Facilitated Workshop
Face-to-Face
Interview
Telephone
Interview/Survey
Mail Survey
Level of
Participant
Commitment
High
¦ Most effective with
small, dedicated
teams
representative of
the user
environment
Moderate
¦ Most effective
when interview
notes are validated
in a follow-up
session
Moderate to Low
¦ Most effective when
interview notes and
survey responses
are validated before
use
Low
¦ Careful selection
of participants is
a critical
success factor
Must Reach
Consensus
¦ Most effective since
consensus is the
goal of the
session(s)
¦ Relies on continuity
of workshop
members
¦ Effective when
followed by
facilitated
workshop to
resolve obstacles
to consensus
¦ Analysis required
¦ Effective when
followed by
facilitated workshop
to resolve obstacles
to consensus
¦ Analysis required
¦ Not suggested
when consensus
is required
¦ Best used to
solicit opinion
where decisions
are made
centrally
Must Integrate
Different
Perspectives
¦ Most effective
opportunity for
integration by
participants
¦ Integration
performed by
project analysts
¦ Integration
performed by
project analysts
¦ Integration
performed by
project analysts
Project Skills
Required
¦ Workshop
facilitation
¦ Data gathering
¦ Interview
¦ Communication
¦ Document
management
¦ Survey design
¦ Administration
Schedule
Considerations
¦ Elicit requirements
from the most
people in the
shortest time frame
¦ Cancellations and
changes to
interview schedule
can impact project
schedule
¦ Unpredictable
schedule due to
stakeholder
availability (e.g.,
telephone tag)
¦ Unpredictable
because it
depends on
timely response
Travel
Considerations
¦ Geographically
diverse
stakeholders may
involve travel by the
stakeholders
¦ Geographically
diverse
stakeholders may
involve travel by
the team
¦ Follow-up workshop
may require travel
by stakeholders
¦ None
Quality of
Information
High
High to Moderate
Moderate to Low
Low
Level of Detail
Low
Moderate
Moderate
High
4.2.2 Perform Requirements Identification and Analysis
The Requirements Manager and Project Team Members create and/or update requirements
documentation as requirements are identified or gathered, to include high-level models (node tree,
context, and entity relationship diagrams, etc., used in IT-projects), interview notes, workshop and
meeting minutes, and survey results. These documents provide the basis for understanding the
expectations of the project's requirements and help in the process of achieving clarification,
consensus, and commitment on requirements among Project Stakeholders and the project team.
After gathering requirements from stakeholders, SMEs, and any other potential sources, including any
legacy system re-engineering (for IT projects), analysis of these customer requirements allows the
9
1/10/2007- Version 1.0
-------
Office of Enterprise Technology and Innovation
Requirements Management Procedure OETI-PMP-07
Requirements Manager to evaluate and refine them against the project's business objectives, scope,
and constraints. This analysis may uncover requirements that do not fit within the intended scope of
the work product being created or that are incomplete or missing. Such issues require resolution at
this early stage, as these requirements form the basis for all subsequent software development or
project delivery activities and may affect stakeholders' acceptance of the product.
Note: The Requirements Manager and the appropriate Project Team Members expected to build the
final product or deliver services should participate in the requirements definition and validation
with the appropriate stakeholders to ensure requirements are clear and concise, measurable,
achievable, realistic, consistent with the other requirements, and testable.
The Requirements Manager and the Project Team Members then categorize the requirements and for
IT projects, allocate them to systems (e.g., functional, interface, performance) and non-systems
components (e.g., manual component, policy). The following is a descriptive list of some possible
categories and supporting sub-categories of IT requirements:
¦ Feature Requirements: Indicates all feature requirements for the project. Keyword:
customer, provide, prevent, publish, prompt, and limit.
¦ Reporting Requirements: Describes the characteristics of each standard report, including
the report title, purpose, format, data attributes, sorts, filters, calculations, and targeted
audience.
¦ System Requirements. Indicates all system requirements for the project. Keyword:
determine, display, allow, accept, and verify.
¦ Human Engineering (Ergonomic) Requirements: Describes the system specifications that
support the ease of operation, in particular a uniform operating environment for all tools and
products.
¦ Data Requirements: Describes the business information needed, including data elements by
name, type, and format. This results in a high-level data model, which outlines dictionaries,
tables, and reference files.
¦ Hardware Requirements: Describes hardware requirements.
¦ Capacity Requirements: Describes the hardware infrastructure and includes computer
memory, disk storage space, and printer throughput.
¦ Technical Architecture Requirements: Describes the minimum configuration and
capabilities required, categorized by headquarter workstations, remote workstations, printers,
and database, Web, and remote access servers.
¦ Special Requirements: Describes requirements that support the project's mission including
training, transition processing, data conversion, and testing.
¦ Performance Requirements: Describes performance issues such as sizing, backing up,
restarting, restoring, accuracy, transaction volumes and timing, flexibility, reliability,
availability, and maintainability.
¦ Security Requirements: Describes the measures that must be taken to protect system
configuration and data.
The Requirements Manager along with appropriate Project Team Members must ensure requirements
are:
¦ Clear and concise
¦ Feasible and appropriate to implement for development
10
1/10/2007- Version 1.0
-------
Office of Enterprise Technology and Innovation
Requirements Management Procedure OETI-PMP-07
¦ Consistent with the other requirements and non-redundant
¦ Testable
¦ Complete
¦ Unambiguous.
Requirements identification and analysis are important activities that are often difficult to implement
effectively. Appendix C provides resources to consult when developing requirements. Appendix F
provides a list of common problems detected during the requirements analysis phase and ways to
solve them or minimize their impact.
4.2.3 Develop/Update the Requirements Traceability Matrix (RTM) and Related
Documents
After the team assembles and categorizes the requirements, the Requirements Manager creates the
RTM. The RTM serves as the basis for all project RM activities. Project teams use an RTM
(automated or manual) to record the traceability of each requirement. Every item in the RTM must first
be uniquely identified. During the early stages of a project, the Requirements Manager works with the
Project Manager, Team Lead, and Configuration Manager to define the items the project RTM will
track. Traceability analysis should be repeated throughout the product life cycle. The goals of
traceability analysis are to validate that the design meets the requirements, to verify that the
requirements are tested, and to ensure that the project addresses all requirements. Refer to Appendix
G for an RTM template and sample.
In addition to the RTM, the Requirements Manager ensures other related documents are also created
and updated, as specified in the Requirements Management Plan. These additional documents
describe requirements in further detail to allow for a greater understanding of the requirements by all
relevant stakeholders, to include contractors and quality control activities.
For system projects, the requirements documents must provide the stakeholders and the Project
Team with adequate detail in the description of requirements to be approved/rejected, implemented,
and to support requirements traceability through the design, development, and testing phases.
The Project Team Lead reviews the project's Requirements Document and works with the Project
Team and the Project Manager to ensure that it will meet the project's specific needs.
4.2.4 Conduct Peer Reviews on Documentation
Peer reviews of requirements work products should include, when possible, representation from the
functional analysts and testers (for IT projects) to ensure that all affected groups are able to provide
feedback regarding the Requirements Document and RTM. Other groups should be included as
necessary. Feedback from the peer review should be incorporated.
Four types of requirements reviews should occur during the course of a project:
¦ Peer Reviews - Participants in these peer reviews include functional analysts, developers,
testers, process area leads, and technical managers where appropriate (for IT projects).
¦ Project Manager - The Project Manager reviews the activities associated with RM on both a
periodic and event-driven basis.
¦ Quality Manager - The Quality Manager reviews and/or audits the activities and work
products for managing the allocated requirements and reports the results, according to the
project's Quality Assurance Plan or contractor's Quality Assurance Surveillance Plan (QASP).
11
1/10/2007- Version 1.0
-------
Office of Enterprise Technology and Innovation
Requirements Management Procedure OETI-PMP-07
See PMP-09 Quality Management Procedure for more information about development of the
Quality Assurance Plan, quality assurance reviews, and audits.
¦ CCB Reviews - This established forum conducts reviews for new requirement acceptance or
modifications to requirements. See PMP-08 Change Control Procedure for more information
about the operation of the CCB.
Once the project's requirements documents are updated as a result of peer reviews, the
Requirements Manager provides the document(s) to the Project Team Leads and Project Manager for
approval prior to obtaining customer approval.
4.2.5 Obtain Appropriate Stakeholder Approval for Requirements Work Products
Successful RM includes approval and baselining of the requirements. Requirements approval refers
to the customer's acceptance of the list of requirements. Methods used to obtain customer approval
include:
¦ Customer signatures
¦ CCB meetings
¦ E-mail notification.
Requirements baselining occurs after customer approval. Baselining refers to the point in time after
which the project team may not incorporate any requirement change without going through the
project's change control process (See OETI-PMP 08 Change Control Procedure for details).
Each Project Team is responsible for the formal documentation of the acceptance process.
4.2.6 Place Requirements under Configuration Management Control
The Requirements Manager works with the project's Configuration Management Team to ensure that
the baselined requirements work products are placed under appropriate configuration control for the
duration of the project.
4.2.7 Manage Requirements Changes
Prior to the establishment of the requirements baseline, the Requirements Manager manages
changes to the requirements, updating the RTM and any other requirements documentation as
changes occur. After requirements are baselined, the Requirements Manager participates in on-going
requirements analysis and product design meetings to identify and collect potential changes to the
requirements baseline. Changes to an approved requirements baseline are initiated via a Change
Request (CR), which is a part of the Change Control process (see PMP-08 Change Control
Procedure). In proposing changes to the requirements baseline, three types of changes are possible:
¦ Requirement Addition: Indicates that the project develops a new feature to support a
business process or address an area that is not currently in scope or supported. It could also
indicate the addition of new functionality to an existing application. The customer community
initiates requirements for new system or product development and passes them to the
development team via the customer or CCB.
¦ Requirement Modification: Specifies either modifications of or corrections to existing
functionality or data. Internal testing, customer/user requests, or CCB decisions may initiate
these modifications.
12
1/10/2007- Version 1.0
-------
Office of Enterprise Technology and Innovation
Requirements Management Procedure OETI-PMP-07
¦ Requirement Deletion: Indicates that the requirement is no longer essential to the product.
Based on the Team Lead or the customer's request, the CCB reviews the requirement that
may be nonessential and decides whether to delete the requirement.
The Requirements Manager enters approved changes into the RTM to maintain a history of
requirement changes. Refer to the PMP-08 Change Control Procedure for a description of change
control, determining the impact of a potential requirements change, and the role of the CCB in
addressing CRs.
13
1/10/2007- Version 1.0
-------
Office of Enterprise Technology and Innovation
Requirements Management Procedure OETI-PMP-07
5. Considerations
The following provides a list of general best practices that should be considered when conducting
requirements management activities:
¦ The involved participation of stakeholders is critical to successful requirements management.
Depending on the nature of the project, they should be active partners in identifying,
discussing, and documenting the requirements.
¦ Approach requirements management as a negotiation process. It is very unlikely that the
project team and the stakeholders will agree on all requirements. However, to keep the
process collaborative and manageable, seemingly unreasonable requirements should be
neither accepted nor rejected outright by the project team.
¦ Prioritizing requirements allows for more efficient application of project resources. This should
be done by the stakeholders, as they will be most affected by the outcome.
¦ While it is important to baseline requirements early in the project, ensure that stakeholders are
not prevented from suggesting necessary requirements changes by a cumbersome change
control process. This can also prevent the inclusion of gratuitous requirements in the initial
baseline, as stakeholders who believe they cannot make changes later on will often err on the
side of excess in the initial phase.
¦ Documentation of requirements is essential, but remember that the goal is, ultimately, to
implement them. Try to create a documentation process that balances the benefits of both
traceability and flexibility.
14
1/10/2007- Version 1.0
-------
Office of Enterprise Technology and Innovation
Requirements Management Procedure OETI-PMP-07
Appendix A Acronyms
The following acronyms shown below are referenced in this document.
Abbreviation
Description
BFM
Budget Formulation
BRM
Business Reference Model
BXC
Budget Execution
CCB
Change Control Board
CMMI
Capability Maturity Model Integration
CONOPS
Concepts of Operation
CR
Change Request
DO
Delivery Order
EPA
Environmental Protection Agency
FRS
Functional Requirements Specification
FSIO
Financial Systems Integration Office
ID
Identification
IT
Information Technology
OEI
Office of Environmental Information
OETI
Office of Enterprise Technology and Innovation
PAY
Payment Management
PMBOK®
Project Management Body of Knowledge
PMI
Project Management Institute
OA
Quality Assurance
QASP
Quality Assurance Surveillance Plan
RM
Requirements Management
RTM
Requirements Traceability Matrix
SEI
Software Engineering Institute
SLCM
System Life Cycle Management
SME
Subject Matter Expert
SMP
System Management Plan
TO
Task Order
WA
Work Authorization
A-1
1/10/2007- Version 1.0
-------
Office of Enterprise Technology and Innovation
Requirements Management Procedure OETI-PMP-07
Appendix B Requirements Management Checklist
The following provides a checklist for the key activities associated with each step of this RM procedure.
Activities
Responsible Parties
4.2.1 Develop Requirements Management Plan
~ Description of how requirements artifacts (requirements documents, Use Cases,
Concept of Operations, etc.) will be developed and managed during the project life
cycle is provided
Requirements Manager
~ Description of how requirement identification and analysis will be accomplished
(e.g., sources, types, attributes, techniques, tools, etc.) is provided
~ The method by which bi-directional traceability will be established and maintained is
described
~ RM template is leveraged/referenced
~ Tasks and estimates are planned for the requirements phase
Project Manager, Requirements
~ Business objectives, scope, and constraints are described for the project
Manager
~ Assumptions, known risks, and mitigation strategies are identified and addressed, if
appropriate
4.2.2 Perform Requirements Identification and Analysis
~ Requirements gathering, identification, and analysis activities are done according to
what is stated in the Requirements Management Plan
Requirements Manager
~ Documentation is created and/or updated according to Requirements Management
Plan
~ Requirements are identified, gathered, defined, and validated with the appropriate
stakeholders to ensure they are clear and concise, measurable, achievable,
realistic, consistent with the other requirements, and testable
Requirements Manager, Project
Team
~ Requirements are categorized and, for IT projects, are allocated to systems (e.g.,
functional, interface, performance), and non-systems components (e.g., manual
component, policy)
4.2.3 Develop/Update the RTM and Related Documents
~ The RTM is developed/updated with the newly created/modified requirements
Requirements Manager
~ Related requirements documents are developed/updated with the newly
created/modified requirements and detailed descriptions, including any additional
analysis
~ Traceability is conducted throughout the life cycle
Requirements Manager, Project
Team Leads, Project Team
~ Requirements documents contain enough information for the stakeholder to
understand, approve, or reject the documented requirements
Requirements Manager, Project
Manager, Project Team Leads
~ Requirements documents are developed sufficiently to meet the project's specific
needs
4.2.4 Conduct Peer Reviews on Documentation
~ Requirements documents/artifacts (e.g., RTM) are reviewed and modified as
necessary before being sharing with project stakeholders
Requirements Manager, Project
Team Leads, Project Team, QA
Manager, Project Manager, Test
Team
4.2.5 Obtain Appropriate Stakeholder Approval for Requirements Work Products
B-1
1/10/2007- Version 1.0
-------
Office of Enterprise Technology and Innovation
Requirements Management Procedure OETI-PMP-07
Activities
Responsible Parties
~ Approval solicitation method is employed (i.e., CCB, facilitated walk through, etc.)
~ Stakeholder approval is obtained for requirements work products (RTM and
Requirements Document, in most cases)
Project Stakeholders
4.2.6 Place Requirements under Configuration Management Control
~ Approved requirements work products are placed under Configuration Management
control
Configuration Management
Team, Requirements Manager
4.2.7 Manage Requirements Changes
~ Changes to the requirements baseline have gone through the Change Control
process (Refer to OETI-PMP08 Change Control Procedure^ a description of
change control)
Project Manager, Project
Stakeholders, Requirements
Manager, Configuration
Management Team
~ Requirements documentation (e.g., RTM) is updated to reflect approved changes
Requirements Manager
B-2
1/10/2007- Version 1.0
-------
Office of Enterprise Technology and Innovation
Requirements Management Procedure OETI-PMP-07
Appendix C Additional Resources
The following provides a list of key resources and references associated with the requirements
management procedure that can be used to assist in completion of the activities.
Form/ Guidance
Source
Website
1.
Guidance for Management of
Center for Systems Management. Course:
NA
Systems Projects
Requirements Development. Virginia: Center
for Systems Management, Inc., 2004.
Andrew Stellman and Jennifer Greene
http://www.stellman-
(2005). Applied Software Proiect
areene.com/asom/
ManaaementCaxvtoMQe. MA: O'Reilly Media.
ISBN 0-596-00948-8.
McConnell, Steve (1996). Rapid
htto://www. stevemcconnel I. com/
Development: Tamina Wild Software
Schedules, 1st ed., Redmond, WA: Microsoft
Press.
2.
Guidance for Systems
Eisner, Howard. Essentials of Project and
NA
Engineering Activities
Systems Engineering Management Second
Edition. New York: John Wiley & Sons, Inc.,
2002.
Stevens, Richard; Brook, Peter; Jackson,
NA
Ken; Arnold, Stuart. Systems Engineering
Coping with Complexity. Great Britain:
Pearson Education, Limited, 1998.
3.
Guidance on Writing
Le Vie, Jr., Donn. Writina Software
htto://www.techwr-
Requirements
Requirements.
l.com/techwhirl/maaazine/writina/so
ftwarereauirementsoecs.html
IEEE Std 830-1993, Recommended Practice
NA
for Software Requirements Specifications,
December 2,1993.
4.
Guidance on Effective
Gause, Donald C., and Weinberg, Gerald M.,
NA
Requirements Management
Exploring Requirements Quality Before
Design, Dorset House Publishing, NY, NY,
1989.
Wieaers. Karl E. (2003). Software
htto://www. orocessi moact. com/
Reauirements 2: Practical techniaues for
aatherina andmanaaina reauirements
throuahout the product development cvcle
2nd ed., Redmond: Microsoft Press. ISBN 0-
7356-1879-8.
Wiegers, Karl E. Software Requirements,
NA
Microsoft Press, Redmond, WA, 1999.
C-1
1/10/2007- Version 1.0
-------
Office of Enterprise Technology and Innovation
Requirements Management Procedure OETI-PMP-07
Appendix D Interface Requirements
The purpose of this appendix is to provide general guidelines for collecting the appropriate information
from contractors to ensure seamless integration of project data and promote efficient monitoring of the
overall project. Frequently, data is needed by support contractors to enable the Project Manager to
accurately assess real-time status against overall performance, schedule and cost objectives. In
addition, the interface points among the different parties, both government and contractor, need to be
fully delineated with regard to requirements management to ensure that each party understands their
specific role and responsibility in data management and reporting and that the information can be
efficiently captured utilizing the project's established management processes and tools. As a result
these data, reporting, and interface requirements need to be well defined early in the process in order to
ensure that they are fully delineated in the awarded contract, Work Authorization (WA), Delivery Order
(DO), and/or Task Order (TO). In addition, the frequency, format, and mode of submission for the
different reporting requirements also need to be defined within the contract or WA, DO, or TO.
The following series of questions is provided to help determine the data, reporting and interface
requirements that may be required for requirements management activities for a specific project.
Requirements may vary significantly depending on the scope, complexity, size, duration and of the
project and type of contracts awarded. Overall the questions are designed to help refine what kind of
information will be needed to ensure effective management of the requirements process, the project and
the correlating responsibilities of the contractor.
¦ Wll the contractor be involved in gathering or analyzing requirements?
- What level of detail is needed for capturing requirements?
- What types of requirements will be captured?
- Which groups of customers or stakeholders will the contractor need to work with in order to
gather/define requirements?
- What kind of format will the contractor need to properly document requirements?
- What tools (if any) will the contractor be required to interface with or provide data to for the
documentation of requirements?
- Wll the contractor be performing a fit-gap analysis or some other type of evaluation to
determine how requirements will be met by the product or deliverable?
¦ Wll the contractor be responsible for maintaining or demonstrating requirements traceability?
- Wll the contractor need access to the baselined requirements to perform other work (such
as design or testing)?
- Wll contractor deliverables need to reflect requirements traceability?
- Are performance measures defined for the contractor based on how well their product or
deliverable meets defined requirements?
¦ Wll the contractor be allowed or required to identify new requirements through the change
control process?
D-1
1/10/2007- Version 1.0
-------
Office of Enterprise Technology and Innovation
Requirements Management Procedure OETI-PMP-07
Appendix E Requirements Management Plan Template
This appendix provides a sample Requirements Management Plan template that may be used and/or
tailored as appropriate according to project needs.
Requirements Management Plan Template
Acceptance/Approval Page
DOCUMENT CHANGE HISTORY - Complete the version, date, author and description column to
accurately describe the modifications made to this document.
Version Date Author Description of Changes
vx.x
1.0 INTRODUCTION
[This section introduces the document. Additional information may be added that describes the project
background or description, and any specific policies or procedures. Example: This RM Plan is the
controlling document for developing and managing the requirements for the project.]
1.1 PURPOSE
[This section defines the purpose of the plan. Additional information may be added to further clarify the
purpose of the document. Example: This document describes the guidelines used by the project for establishing the requirement document, requirement types, requirement attributes,
and traceability in order to manage their software project requirements.]
1.2 SCOPE
[This section defines the parameters of the requirements management plan. Add any text necessary to
define what is included and what is excluded as part of the scope of the plan. This text may:
¦ Name the specific entity, product, project team, and/ or component for which requirements
management activities are performed and those that are expressly excluded
¦ Define whether this plan will document creation of an initial baseline of requirements for new
development, or whether it will define requirements management for maintenance of existing
requirements
¦ Identify if contractor support is used on the project and if they will be the subject of quality
assurance activities
¦ Describe other boundaries for the plan]
1.3 REFERENCE DOCUMENTATION
[This section identifies the references, standards, procedures and other documents used to develop the
RM activities for the project. This list may include:
¦ Project Management Plan
¦ Project Schedule
¦ Configuration Management Plan
¦ Configuration Item/Configuration Data List
E-1 1/10/2007-Version 1.0
-------
Office of Enterprise Technology and Innovation
Requirements Management Procedure OETI-PMP-07
¦ Risk Management Plan
¦ Statement of Work and/or Contract and/or Applicable Contractual
Requirements
¦ Other project documentation, as necessary
¦ Internal or external requirements management resources or standards, as applicable. For
system projects, the Requirements Manager should refer to the Office of Environmental
Information's System Life Cycle Management Policy and corresponding procedures when
developing the requirements management plan.]
1.4 PLAN MAINTENANCE
[This section identifies the office or group responsible for developing, maintaining, and distributing this
plan. It also establishes how often the plan is reviewed, typically by organizational directives. Updates
are prepared as required.]
2.0 REQUIREMENTS MANAGEMENT
[This section is used to document some overview information about the requirements management
process.]
2.1 ROLES & RESPONSIBILITIES
[This section is used to describe the Requirements Management (RM) group, their responsibilities, and
interfaces with other groups. Enter the responsibilities of the RM group members. Refer to or insert an
Organization Chart and any inter-group interfaces. Example: The RM group consists of the project's
RM Manager and the RM Analyst(s), if assigned. Responsibilities for the RM group are defined in Table
2-1 (insert table with detailed responsibilities).]
2.2 TOOLS, ENVIRONMENT AND INFRASTRUCTURE
[This section is used to document appropriate RM tool information. Add additional sentences or
paragraphs, as needed, to further clarify the tools, environment, and infrastructure for RM.]
3.0 THE REQUIREMENTS MANAGEMENT PROGRAM
3.1 REQUIREMENTS IDENTIFICATION
[Every item in a requirement traceability matrix must be uniquely identified. This section defines how
items are identified. Requirements gathering techniques that will be used on the project are identified
here. Requirements providers are also identified here.]
3.1.1 ATTRIBUTES
[This section is used to list and describe attributes which will be associated with each requirement.
Attributes may be useful in tracking requirements through the life cycle of a project. Examples of
attributes include: Title, Description, Status, Category, Priority, Assigned To, Type, Impact, Release,
Reported By, etc.]
3.2 REQUIREMENTS ANALYSIS
E-2
1/10/2007- Version 1.0
-------
Office of Enterprise Technology and Innovation
Requirements Management Procedure OETI-PMP-07
[This section is used to describe how a project will analyze and categorize requirements once they have
been gathered. Document the requirements analysis procedures and methods the project follows to
determine if the requirements are sufficient to meet the project stakeholder objectives for the product.
Some examples of possible requirements analysis activities to describe are: the process for analyzing
stakeholder needs and expectations, review and analysis of functional groupings of requirements, the
utilization of use case diagrams or activity flows. Be sure to address stakeholder needs and constraints
such as cost, schedule, performance, maintainability, or risk during requirements analysis.
Requirements (and changes to requirements) should be analyzed in the context of the constraints
imposed by project costs, schedule, performance parameters and goals, and risks. Technical and
considerations such as functionality, reusable components, and maintainability should also be
considered when analyzing requirements as well.]
3.3 REQUIREMENTS TRACKING & TRACEABILITY
[This section is used to describe bidirectional traceability and use of a Requirements Traceability Matrix.
The RTM cross references the change requests, design document, test scripts, and other meaningful
data.]
3.4 REPORTS AND MEASURES (if applicable)
[This section is used to document reporting activities for RM, as well as information regarding the
collection and analysis of RM measures. If the information is already contained in other documents,
those documents can be referenced, instead of repeating the information.]
3.5 REQUIREMENTS VALIDATION
[This section is used to document the Validation Requirements process for analysis as requirements
may need to be modified. The requirement(s) must be validated to ensure that the correct product is
being produced to meet the stakeholders' needs. Examples of validation include prototyping,
requirements documents, and meeting minutes. The requirement(s) for validation must be prepared.
This preparation may include any supporting work products or activities such as review meetings with
the client, prototyping, etc. Stakeholder feedback is to be collected and documented. An analysis of
the collected feedback is completed, and requirements are to be modified based on the analysis of the
validation feedback. Formal requirements validation processes can be further documented in the Test
Plan, if in fact the Test Plan is applicable and more appropriate.]
3.6 REQUIREMENTS CHANGE CONTROL
[This section should reference the project's Change Control process or charter. Add additional
sentences or paragraphs, as needed, to describe the change control process.]
3.7 WORKFLOW AND ACTIVITIES
[This section is used to describe the requirements management workflow and activities.]
4.0 MILESTONES
[This section is used to identify the internal and customer milestones related to the RM effort. This
section should also include details on when the RM Plan itself is to be updated.]
5.0 TRAINING AND RESOURCES
E-3
1/10/2007- Version 1.0
-------
Office of Enterprise Technology and Innovation
Requirements Management Procedure OETI-PMP-07
[This section should be used to describe the software tools, personnel, and training required to
implement the specified RM activities.]
APPENDIX A - ACRONYMS
APPENDIX B - DEFINITIONS
E-4
1/10/2007- Version 1.0
-------
Office of Enterprise Technology and Innovation
Requirements Management Procedure OETI-PMP-07
Appendix F Common Requirements Problems and Solutions
Table F-1 provides a list of common problems detected during the requirements analysis phase and
ways to solve them or minimize their impact.
Table F-1. Common Requirements Problems and Potential Solutions
Problem
Potential Solution
Frequently changing requirements and/or difficulty in
getting the appropriate stakeholders approval and
sign-off
¦ Implement prototyping and Joint Application Development
sessions to assist the appropriate stakeholders in finalizing
the requirements
¦ Describe the impact of a changed or added requirement to the
project
Some requirements remain difficult to define or are
initially unknown
¦ Select a more flexible life cycle model that supports changing
requirements.
The feasibility of one or more individual requirements
may be in question
¦ Implement prototyping, involve experts to perform a feasibility
analysis, or require approval for alternative requirements if the
original is not feasible
Typical end-users are not involved - Users need to be
involved in defining, reviewing, and approving the
requirements. If this critical step is missing, there is a
high risk that the product will not meet their needs and
expectations
¦ Good sources of user input include user groups, advisory
councils, and specific engineers at customer facilities who
may later participate in acceptance testing
Usability attributes are not defined
Identify potential usability attributes, which may include:
¦ Easy installation
¦ Consistent and logical user interface
¦ Use of standard Windows user interface conventions
¦ Complete and accurate documentation
¦ Useful on-line help
¦ Clear error messages that direct the user to a solution
¦ Performance requirements (system response times)
¦ Adequate technical support
F-1
1/10/2007- Version 1.0
-------
Office of Enterprise Technology and Innovation
Requirements Management Procedure OETI-PMP-07
Appendix G Requirements Traceability Matrix Template
This appendix provides a sample RTM template that may be used and/or tailored as appropriate
according to project needs. A sample RTM used for an OETI systems project is also provided.
G.1 RTM Template
Below is a generic RTM template which covers the basic elements of tracing requirements throughout
a project's life cycle. This would be the minimum set of criteria an RTM should have; however, more
columns may be added provided they match the attributes specified in the RM Plan. All RTMs should
have an explanation of the table headers at the beginning of the document so an understanding can
be developed between the author and the reader. Bi-directional traceability should also be explained
suggesting that traceability will not only be demonstrated here but in the work products that are a
result of these requirements.
Traceability is a key activity in the system life cycle to ensure that requirements have been addressed
in the various work products produced by the life cycle phases. The RTM is the tool used in
maintaining traceability for the project. It shows traceability from the initial change request all the way
through implementation. To ensure accurate and complete development of the change requests,
requirements are traced through all phases of the life cycle. The artifacts produced by the life cycle
phases must also trace back to the requirements by including the requirements ID in the comments or
text. The RTM is also an important tool as it tracks which requirements are addressed in the initial
implementation and which will be deferred to a later release.
There are ten columns in the RTM, which are described as follows:
¦ Requirement ID - Displays the historical ID number for each requirement
¦ CR - Indicates any associated CR initially assigned to each requirement
¦ Requirement Name- Provides a brief title for the requirement
¦ Requirement Description - Contains a brief description of the requirement
¦ Status - Identifies the status of the requirement as it relates to the development phase
¦ Requirement Type - Identifies the type (i.e., Business, Functional, Ergonomic, Software, User,
System) of requirement in the implementation process
¦ Version - Identifies the version release in which the requirement was incorporated. A blank
space suggests that the requirement has not been satisfied in the software to date.
¦ Trace to Design - Indicates the design document that contains design information for the
requirement
¦ Trace to Develop - Indicates the code/product where the requirement is implemented
¦ Trace to Test - Indicates the test script used to test the requirement.
G-1
1/10/2007- Version 1.0
-------
Office of Enterprise Technology and Innovation
Requirements Management Procedure OETI-PMP-07
Requirement
ID
CR
Requirement
Name
Requirement Description
Status
Requirement
Type
Version
Trace to Design
Trace to
Develop
Trace
to Test
Requirement
ID#
Detailed Requirement
Name of Design
Document
Name of
Code/Product
Name
of Test
Script
G.2 Sample RTM
This section provides an example of an RTM used for an OETI systems project. The project team tailored the template from section G.1 in order
to best meet project needs.
The following spreadsheets provide additional details regarding the requirements. These spreadsheets will facilitate review and research by
providing users with the ability to filter, sort, and manipulate fields as required.
The following information is provided:
¦ Type - The type of function the requirement refers to (e.g., BXC is Budget Execution, PAY is Payment Management, etc)
¦ Requirement Number (Req. No.) - Provides a unique identifier for each requirement. Requirement numbers with a Financial Systems
Integration Office (FSIO) designation refer to FSIO mandatory requirements; those with an EPA designation refer to FSIO value-added
requirements or EPA-originating requirements
¦ Source - Identifies the original source of the requirement
¦ Requirement Description - Provides the original wording of the requirement as was presented in the Focus Group read-ahead packet
¦ Priority - Provides the priority designation of Mandatory, High Value Added, Medium Value Added and Low Value Added. At this time
priorities have only been assigned for FSIO mandatory requirements and a few requirements for which the focus group specified priority.
Analysis will be conducted to determine the range of priority numbers that will comprise the priority designations (e.g., 3.4 - 4.0 indicates
Mandatory). Once the analysis has been performed, priorities will be assigned to each requirement.
¦ Related FSIO Number - Provides the associated FSIO requirement number
¦ BRM Ref # (Main) - Indicates the main business reference model number that the requirement is associated with. This field can be used
for sorting and formatting
¦ BRM Ref# (All)- Indicates all of the business reference model numbers that the requirement is associated with
¦ BRM Ref Name - Indicates the name of the business reference model grouping that the requirement is associated with.
¦ FSIO Class. Name - Indicates the classification of the requirement as designated by FSIO
G-2
1/10/2007- Version 1.0
-------
Office of Enterprise Technology and Innovation
Requirements Management Procedure OETI-PMP-07
¦ Rationale - Indicates the justification for the requested requirement. Rationales for functional requirements include Supports EPA Strategic
Plan, Core Business Function, Government Regulation, Political Requirement, Stakeholder Requirement or Not Relevant. Rationales for
technical requirements include EPA IT Strategic Standards, Government Regulations, Technology Developments, Pending Legislation or
Court Decisions
¦ Relevance - For FSIO mandatory requirements, identifies the level of relevance to EPA's business as High, Medium or Low.
Req. No.
Source
Requirement Description
Priority
Related FSIO
Number
BRM Ref#
(Main)
BRM Ref#
(AH)
BRM Ref
Name
FSIO Class.
Name
Rationale
Relevance
BFM
BFM-
EPA-001
EPA
Define and maintain relationships
between budgetary structures,
accounting structures, and
organizational structures
Mandatory
N/A
3.8.1.1
3.8.1.1
Issue
Guidance
Annual
Resource
Planning
Core
Business
Function
N/A
BFM
BFM-
EPA-002
EPA
Capture and maintain validation tables
for any budget line item or data element
in the budget structure
Mandatory
N/A
3.8.1.1
3.8.1.1
Issue
Guidance
Annual
Resource
Planning
Core
Business
Function
N/A
BFM
BFM-
EPA-003
EPA
Provide access to electronically linked
budget guidance and narrative (EPA
Budget Manuals and Directives, budget
call, strategic plans and guidance, etc.,)
without audit trails for budget-related
electronic documents.
Value
Added
High
N/A
3.8.1.1
3.8.1.1
Issue
Guidance
Annual
Resource
Planning
Core
Business
Function
N/A
BFM
BFM-
EPA-004
EPA
Ability to relate "metadata" (e.g.,
congressional mandates, regulatory
requirements, etc.,) to any level of the
strategic plan
Value
Added
High
N/A
3.8.1.1
3.8.1.1
Issue
Guidance
Strategic Perf.
Planning
Core
Business
Function
N/A
G-3
1/10/2007- Version 1.0
------- |