Guide to Requirements Management

Many projects have a long list of requirements, from product features to design standards to quality metrics.  Each of these requirements originated from a stakeholder, manager, or company policy.  To make matters difficult, the stakeholder often can’t even articulate their requirements or how they would like it implemented into a solution, or company policies are outdated and change.

That’s why we have the subject of requirements management.  The Project Management Institute (PMI) publishes Requirements Management: a Practice Guide, to provide direction and vision to this sub-field.

A project requirement is a condition or capability that is required to be present in a product, service, or result to satisfy a contract or other formally imposed specification.

Project requirements management is the process of determining, agreeing on, analyzing, and implementing the requirements necessary for a successful product or result.  In the Project Management Body of Knowledge (PMBOK Guide) the project requirements are determined as part of the scope management knowledge area.

There are four steps to strong requirements management:

1. Determine project requirements
2. Requirements tracing
3. Implementing the requirements
4. Evaluating the solution

Determine Project Requirements

The first step in requirements management is to determine what the requirements are.  This takes the form of three steps:

1. Needs Assessment
   Prior to the determination of the project requirements, the needs assessment is performed to determine the business case and justification behind the project.  This establishes the underlying root causes behind the current situation and the desired future state.  A stakeholder analysis determines the people and/or organizations who have power over, or interest in, a project, so that project requirements can be accurately determined for each stakeholder.  Root cause analysis and SWOT analysis are used to understand the existing situation and cost benefit analysis is used to determine the desired future state.
2. Requirements management planning
   The requirements management plan contains all of the information necessary to define and manage the project requirements.  This includes:
   • Requirements development, tracking, and reporting
   • Roles and responsibilities
   • Prioritization of requirements
   • Requirements approval procedures and authority levels
   • Acceptance criteria (how to measure if the requirement has been fulfilled)
   • Requirements traceability methods
   • Documentation and communication of requirements to stakeholders
3. Requirements elicitation
   At this step the requirements are determined.  Requirements are mapped from the stakeholder analysis using the procedures within the requirements management plan.  Each stakeholder contributes one or more requirements to the project.  Requirements are elicited through brainstorming, observations, questionnaires and surveys, interviews, facilitated workshops, focus groups, document and interface analysis, and prototypes.  There are seven types of requirements:
   1. Business requirements are required to satisfy the policies, procedures, or culture of the parent organization.
   2. Stakeholder requirements communicate the needs of a specific stakeholder or group of stakeholders.  This may include executives, end users, suppliers, the project team, and anyone who has an interest in the project.
   3. Solution requirements denote particular behaviors and operations that the solution must be able to perform.
   4. Transition requirements describe the temporary capabilities that are necessary to migrate from the current state to the desired future state.
   5. Project requirements are the policies and procedures necessary to execute and manage the project.
   6. Quality requirements describe the quality standards necessary for the product, how they will be measured, and acceptance criteria.
   7. Program requirements describe the benefits targeted by the higher level program of which the project is a part.
4. Requirements analysis
   Analyzing the requirements is necessary to understand and prioritize them, as well as determining the product components that will satisfy them.  In agile project management, the product backlog which guides the iterative development process is determined from the prioritized requirements.

A well formed requirement statement contains the following information:

• Condition
• Subject
• Active verb
• Object
• Business rule (optional)
• Outcome (optional)

For example,

• When [condition], the [subject] [imperative] [active verb] on the [object] so that the [outcome]

Requirement statements should meet the following criteria:

• Unambiguous
  There should be no disagreement as to the meaning or interpretation of a requirement.
  Bad:  The app shall check the email address field
  Good:  The app shall verify that the email address has only one ‘@’ sign
• Precise
  The requirement should describe the solution to the business problem – no more and no less.
  Bad:  The app will display an error message
  Good:  If the email address is invalid, the app will display the message: ‘invalid email address’
• Consistent
  Each requirement should be addressed only once, to avoid contradictions and redundancy.
  Bad:  The new app will…  The restaurant app will…  The system will…
  Good:  The new restaurant app will…
• Correct
  The requirement statement should accurately describe the functionality being built.  The stakeholder can provide verification that the requirement is correct
  Bad:  The app will collect the birth date as a required field on the profile page
  Good:  The app will not collect the birth date as a required field on the profile page
• Complete
  The requirement should incorporate all the known information from stakeholders
  Bad:  The available payment types include Apple Pay, and others TBD
  Good:  The available payment types include Apple Pay, VISA, and Mastercard
• Measurable
  It should be clear whether or not the requirement has been satisfied.
  Bad:  The list of restaurants will be displayed
  Good:  The list of at least 6 restaurants will be displayed
• Feasible
  The requirement must be able to be implemented in a reasonable time at a reasonable cost
  Bad:  The app will allow delivery via a drone
  Good:  The app will allow delivery to any address via delivery personnel
• Traceable
  The requirement must be traceable both forward, to a product feature that satisfies it, or backward, to the stakeholder or business policy that it originates from.
  Bad:  The profile page will collect user data
  Good:  The settings page will collect customer emails for marketing purposes
• Testable
  A product tester should be able to approve the requirement as having be satisfied or not satisfied.
  Bad:  The Order History page will display past orders
  Good:  The Order History page will display past orders in chronological order, containing the amount, vendor, and date

Requirements Tracing

To manage complex product requirements, they are “traced” in two directions:

• Back, to the stakeholder who requested it, or organizational policy that specified it, and
• Forward, to the product features and functionality that addresses the requirement

This is accomplished via a Requirements Traceability Matrix which specifies each requirement and the important information with it.  The Requirements Traceability Matrix becomes the backbone which tracks the requirements and ensures that stakeholders are satisfied with the product feature that satisfies each requirement.

Requirements have attributes.  A typical attribute list looks something like this:

1. ID
2. Description
3. Source
4. Owner
5. Rationale for inclusion
6. Priority
7. Version
8. Current status (active, cancelled, deferred, added, approved, assigned, completed)
9. Date

The requirements traceability matrix tracks the attributes and provides the tracing mechanism for the stakeholder who requested it (back) and product feature that satisfies it (forward).

Implementing the Requirements

During the project’s execution phase, the requirements traceability matrix guides the primary monitoring and control function of the project.  That is, it is consulted regularly to ensure the product is being developed to satisfy the requirements, and that stakeholders are satisfied with the product.

The requirements are updated regularly, that is, they should be viewed as a dynamic and evolving feature that requires regular maintenance by the project manager.

Requirements can, and regularly do, change mid-project.  This leads to scope creep and potential budget and schedule overruns, hence the requirements must be actively managed by the project manager (or scrum master in the case of agile project management).  For this reason, project requirements management is intricately linked to project scope and change management.

Evaluate the Solution

Finally, the solution that was developed to satisfy the requirements must be evaluated to determine its adequacy in satisfying the requirements.  Acceptance criteria are consulted and product testing records are completed.  The stakeholders validate the product through demonstrations and user testing.