6 Requirement Lifecycle Management
Requirements are not static artifacts that you create once and forget. They have a lifecycle that extends from the moment they are first conceived through their eventual retirement when they are no longer relevant. Managing this lifecycle well determines whether requirements serve their purpose or become obstacles to success.
This chapter addresses how Business Analysts manage requirements over time: tracking their relationships, maintaining their accuracy, prioritizing them appropriately, handling changes, and gaining approvals. These activities may seem administrative, but they are essential to project success.
6.1 What This Knowledge Area Covers
The Requirements Lifecycle Management knowledge area describes tasks that Business Analysts perform to manage and maintain requirements and design information from inception to retirement.
The primary tasks include establishing meaningful relationships between related requirements and designs, assessing changes when they are proposed, and analyzing changes to gain consensus.
The purpose is ensuring that business, stakeholder, and solution requirements remain aligned with one another and that the solution actually implements them. Supporting tasks include monitoring requirements and designs, directing how requirements will be implemented, and ensuring that Business Analysis information remains available for future use.
6.2 Tracing Requirements
Traceability means identifying and documenting the lineage of each requirement. This includes backward traceability, which tracks where requirements came from, forward traceability, which tracks where they lead, and relationships to other requirements.
Why does traceability matter? It helps ensure that the solution conforms to requirements. It assists in managing scope, change, risk, time, cost, and communication. It enables detection of missing functionality. It reveals when implemented functionality is not supported by any requirement.
Organizations without traceability often discover, late in projects, that critical needs were never addressed or that significant development effort went into features nobody requested. Traceability prevents these expensive surprises.
What does traceability enable? It supports more reliable discovery of inconsistencies and gaps in requirements. It provides deeper insights into the scope and complexity of proposed changes. It enables reliable assessment of which requirements have been addressed and which have not.
6.2.1 Types of Relationships
When defining your traceability approach, consider several types of relationships.
Derive relationships show when one requirement is derived from another. A detailed functional requirement might be derived from a higher-level business requirement.
Depends relationships indicate that one requirement cannot be implemented without another. This dependency might be based on necessity, where the second requirement is essential, or based on effort, where the second requirement significantly affects implementation complexity.
Satisfy relationships show that a solution component meets a particular requirement.
Validate relationships connect requirements to the test cases that prove they are implemented correctly.
6.3 Maintaining Requirements
Requirements must be maintained throughout their lifecycle to retain accuracy and consistency. Maintenance also supports reuse of requirements in other solutions.
Requirements representing ongoing needs must remain valid over time. This means they must be consistently represented using standard formats and terminology. They must be reviewed and approved through appropriate maintenance processes. They must remain easily accessible and understandable to those who need them.
Maintaining requirements includes conducting updates after approved changes and maintaining relationships among related requirements.
Maintaining attributes is equally important. Requirements attributes like source, priority, and complexity aid in management. An attribute may change even when the requirement itself does not. For example, a requirement’s priority might increase due to competitive pressure even though the requirement text remains unchanged.
6.3.1 Reusing Requirements
Some requirements are candidates for long-term use across multiple initiatives. These include regulatory requirements that persist regardless of individual projects, contractual obligations that govern multiple systems, quality standards that apply broadly, service level agreements, business rules, business processes, and requirements describing products the enterprise produces.
Requirements intended for reuse must be identified clearly, named consistently, defined precisely, and stored in ways that make them easily retrievable. They can then be reused within the current initiative, within similar initiatives, within similar departments, or throughout the entire organization.
6.4 Prioritizing Requirements
Organizations face a constant truth: there is always more to do than resources allow. Prioritization determines which requirements receive attention and in what order.
Prioritization ranks requirements by relative importance. Priority can refer to the value a requirement provides or to the sequence in which it will be implemented. This is not a one-time activity. Prioritization is ongoing throughout the project lifecycle.
6.4.1 Factors Influencing Priority
Many factors shape prioritization decisions.
Benefit considers what value the requirement provides if implemented.
Penalty considers what negative consequences occur if the requirement is not implemented.
Cost considers how expensive implementation will be.
Risk considers what could go wrong and how likely problems are.
Dependencies consider whether the requirement relies on other requirements that must be implemented first.
Time sensitivity considers whether deadlines affect when the requirement must be delivered.
Stability considers how likely the requirement is to change.
Regulatory or policy compliance considers whether the requirement is legally mandated.
6.4.2 The MoSCoW Method
One popular prioritization approach is MoSCoW (Figure 6.1), which categorizes requirements into four groups.
Must Have requirements are non-negotiable. The solution will not work without them. These are the absolute essentials that define minimum viability.
Should Have requirements are important but not vital. The solution can function without them, but their absence creates significant problems or limitations.
Could Have requirements are desirable. They add value and would be nice to include, but their absence does not seriously impair the solution.
Won’t Have requirements are explicitly excluded from the current scope. They might be addressed in future releases, but they are not priorities now.
The value of MoSCoW lies in forcing explicit decisions. When stakeholders must categorize requirements, they cannot avoid trade-offs. Everything cannot be a “must have.”
6.4.3 Challenges in Prioritization
Prioritization is difficult for several reasons.
Different stakeholders value different things, creating conflicts that must be resolved.
Stakeholders resist characterizing any of their requirements as lower priority. Everything feels important to the person who requested it.
Some stakeholders may game the system, inflating priority to influence results.
6.4.4 Continual Prioritization
Priorities shift as context evolves and information becomes available. What seemed essential early in a project may become less important as understanding develops. What seemed optional may become critical as competitive threats emerge.
The basis for prioritization may also change at different stages. Early prioritization might focus on risk reduction. Later prioritization might focus on value delivery. Business Analysts must remain flexible and help stakeholders reassess priorities as circumstances change.
6.5 Assessing Requirement Changes
Change is inevitable. Requirements that seemed complete will need modification. New requirements will emerge. Existing requirements will become obsolete. The question is not whether change will occur but how it will be managed.
Assessing requirement changes means evaluating the implications of proposed changes to requirements and designs.
When assessing changes, consider several factors. Does the change align with overall strategy? How does it affect value delivered to business or stakeholder groups? What impact does it have on time or resources required to deliver? Does it alter risks, opportunities, or constraints?
6.5.1 Impact Analysis
Impact analysis assesses the effect of proposed changes. Traceability is a valuable tool here because it reveals what else a change might affect.
Impact analysis considers benefit, meaning what value the change provides. It considers cost, meaning what implementation will require. It considers impact, meaning what else will be affected by the change. It considers schedule, meaning how timelines are affected. It considers urgency, meaning how quickly the change is needed.
6.6 Approving Requirements
At various points, requirements need approval. Approval obtains agreement so that Business Analysis work can continue or solution construction can proceed.
Approval may be formal with signatures and official documentation, or informal with verbal agreement and email confirmation. The appropriate level of formality depends on organizational culture, risk levels, and the nature of what is being approved.
Business Analysts work with key stakeholders to gain consensus on new and changed requirements. They communicate outcomes of discussions and track and manage the approval process.
6.7 Case Example: The Retail Inventory Disaster
FastRetail operated 200 stores nationwide. Their inventory system was adequate but aging. When a modernization project began, requirements seemed clear: faster processing, better reporting, integration with the new point-of-sale system.
The project team documented requirements carefully. They gained approval from stakeholders. Development proceeded on schedule. Testing found and fixed the expected bugs.
Then the system went live.
Within days, stores reported major problems. Some products showed as in-stock when shelves were empty. Other products showed as unavailable when warehouses were full. Managers could not trust the numbers.
Investigation revealed the cause. During the project, the company had changed its approach to handling returns. Returns now went to a central processing facility rather than back to selling stores. This created a new inventory status that neither the old system tracked nor the new requirements addressed.
The return policy change had been approved by a different department. Nobody connected that decision to the inventory system project. Traceability that might have flagged the impact did not exist. Requirements that might have captured the new status were never written because nobody knew to write them.
The fix took three months and cost more than the original project. Worse, stores operated with unreliable inventory data during peak season, leading to lost sales and frustrated customers.
The lesson is sobering. Requirements do not exist in isolation. They exist in a context that changes. Without traceability and ongoing maintenance, changes in that context slip through undetected until they cause damage.
Now that you understand how to manage requirements throughout their lifecycle, let us move on to analyzing and designing solutions based on those requirements.
6.8 Review Questions
Requirements traceability tracks all of the following EXCEPT:
- Where requirements came from
- Where requirements lead
- Individual contributor performance ratings
- Relationships to other requirements
In MoSCoW prioritization, “Should Have” requirements are:
- Absolutely essential for the solution to function
- Important but not vital; the solution can work without them
- Desirable nice-to-have features
- Explicitly excluded from current scope
Which relationship type indicates that one requirement cannot be implemented without another?
- Derive
- Depends
- Satisfy
- Validate
Impact analysis for proposed changes should consider:
- Only the direct cost of implementation
- Benefit, cost, impact on other items, schedule, and urgency
- Only whether stakeholders approve the change
- Only technical feasibility
Prioritization in Business Analysis is best described as:
- A one-time activity completed during planning
- An ongoing process throughout the project lifecycle
- Something only executives should perform
- Optional for small projects
1-c, 2-b, 3-b, 4-b, 5-b