BABOK® v3: Requirements and Designs Life Cycle Management

1. Introduction

Requirements and Designs Life Cycle Management is an important knowledge area in business analysis. It focuses on managing requirements and designs from the beginning of an initiative through implementation and beyond.

Business needs can change as a project develops. Stakeholders may identify new expectations, business priorities may shift, and technical or regulatory constraints may emerge. Business analysts must ensure that requirements and designs remain accurate, relevant, traceable, and aligned with business objectives.

The main activities covered in this topic are:

• Tracing requirements and designs.
• Maintaining requirements and designs.
• Prioritising requirements and designs.
• Assessing changes to requirements and designs.
• Approving requirements and designs.

The overall goal is to help the organisation deliver solutions that provide business value while keeping stakeholders informed and involved.

2. Understanding the Requirements and Designs Life Cycle

Requirements and designs do not remain fixed throughout a project. They evolve as the business analyst learns more about the business problem, gathers feedback, and works with stakeholders and the implementation team.

Life cycle management helps ensure that requirements and designs continue to reflect stakeholder needs and business objectives.

For example, a company may begin a project to introduce an online booking system. During development, customers may request appointment reminders. The business analyst must assess the request, determine its value, understand its impact on the existing design, and agree on whether it should be included.

This process is iterative. Requirements and designs may be reviewed and updated several times as more information becomes available.

Effective life cycle management helps business analysts:

• Keep requirements aligned with business goals.
• Understand relationships between requirements and designs.
• Manage changes in a controlled way.
• Prioritise work according to value and constraints.
• Obtain stakeholder agreement.
• Retire requirements that no longer provide sufficient value.

3. Tracing Requirements and Designs

What is traceability?

Traceability is the ability to follow the relationships between requirements, designs, business objectives, stakeholder needs, and solution components.

It helps a business analyst understand where a requirement came from, what it supports, and what may be affected if it changes.

Consider a requirement for an online payment system. It may be linked to a business goal of reducing manual payment processing. It may also be linked to a payment interface, security controls, testing activities, and training for staff.

If the payment requirement changes, traceability helps the team identify which other parts of the solution may need to change.

Key relationships in traceability

Relationship	Meaning
Derive	Shows that one requirement or design is derived from another requirement, need, or objective.
Depends	Shows that one requirement or design depends on another.
Satisfy	Shows how a solution component meets or fulfils a requirement.
Validate	Shows the relationship between a requirement and the business need or objective it is intended to support.

These relationships help business analysts understand how different parts of an initiative connect.

Why is traceability important?

Traceability supports change assessment, impact analysis, validation, and communication. It also helps prevent requirements from being overlooked during implementation.

The level of traceability required depends on factors such as:

• The number and complexity of requirements.
• The formality of the project.
• The need for audit evidence.
• The expected value of maintaining trace links.
• The organisation's governance requirements.

A small internal project may use a simple spreadsheet. A large or regulated project may require a dedicated requirements management application.

Tools for tracing requirements and designs

Common approaches include:

• Requirements traceability matrices.
• Spreadsheets.
• Requirements management software.
• Project management tools.
• Requirements repositories.

The tool should make it possible to identify relationships, track changes, and keep information accessible to the people who need it.

4. Maintaining Requirements and Designs

Maintaining requirements and designs means keeping them accurate, understandable, organised, and useful throughout their life cycle.

A requirement that was valid at the start of a project may become outdated when business processes, legislation, technology, or stakeholder expectations change.

Business analysts must therefore review and update requirements and designs when necessary.

Good practices for maintaining requirements

Use clear names and descriptions. Each requirement should be easy to identify and understand.

Keep relationships updated. If a requirement changes, its links to business objectives, other requirements, designs, and solution components may also need updating.

Use a consistent classification system. A requirements management taxonomy helps organise requirements into categories so that they can be found and managed more easily.

Store information appropriately. The information management approach should explain where requirements and designs are stored, who can access them, and how they are maintained.

Check whether information can be reused. Some requirements and designs may be useful in future projects. Before reusing them, the business analyst should confirm that they remain relevant to the new business context.

Reusing requirements and designs

Reusability depends partly on how a requirement is expressed and how closely it relates to a specific situation.

A general requirement, such as ensuring that users can securely access an application, may be reusable across several projects. A requirement tied to a particular department's workflow may need substantial modification before it can be reused elsewhere.

The business analyst should check whether the requirement still reflects the current business state and the needs of the new initiative.

The main output of maintenance is a set of requirements and designs that remain useful for the current initiative or potential future implementation.

5. Prioritising Requirements and Designs

Prioritisation determines which requirements and designs are most important and when they should be implemented.

Not every requirement can be delivered at the same time. Projects have limits on budget, time, people, technology, and other resources. Business analysts therefore work with stakeholders to establish priorities and negotiate trade-offs.

Factors to consider when prioritising

Factor	Question to ask
Business benefit	How much value will this requirement deliver?
Cost	How much will it cost to implement and maintain?
Risk	What risks arise if it is implemented or delayed?
Dependencies	Does another requirement need to be completed first?
Urgency	How quickly is the requirement needed?
Regulatory compliance	Is the requirement necessary to meet legal or regulatory obligations?
Stakeholder importance	How important is it to the people affected by the solution?
Implementation constraints	Are the required people, skills, technology, and resources available?

Example of prioritisation

Imagine a company developing an online shopping platform. The proposed requirements include:

1. Secure customer payments.
2. A customer order history.
3. A personalised colour theme.
4. Promotional product recommendations.

Secure payments would normally receive a high priority because they are essential to safe transactions and the operation of the platform. The other requirements may be valuable, but their priority depends on business objectives, customer needs, cost, dependencies, and available resources.

The business analyst should not make prioritisation decisions in isolation. Stakeholders must understand the trade-offs and agree on what matters most.

Tools and techniques for prioritisation

Business analysts can use:

• Guidelines and agreed prioritisation criteria.
• Analysis of benefits, costs, risks, and dependencies.
• Group discussions and collaborative workshops.
• Stakeholder reviews.
• Business constraints, including regulatory requirements.
• Project and requirements management tools.

Relevant stakeholders may include subject matter experts, project managers, sponsors, customers, end users, and regulators.

Priorities can change as the initiative develops. A new risk, business need, or regulatory requirement may mean that an existing priority must be reconsidered.

The output is a prioritised set of requirements and designs that supports business goals and helps guide implementation.

6. Assessing Changes to Requirements and Designs

Changes are a normal part of business analysis. However, a proposed change should be assessed before the organisation commits to implementing it.

Change assessment helps determine whether a proposed change is worthwhile, feasible, urgent, and consistent with business objectives.

Inputs and outputs

Typical inputs include:

• The proposed change.
• Existing requirements.
• Existing designs.
• Relevant business information.
• The organisation's governance and information management approaches.

The assessment produces information about the likely impact of the change, helping decision-makers decide whether it should be accepted, rejected, deferred, or investigated further.

What should be assessed?

A business analyst should consider:

• Expected business benefits.
• Implementation and ongoing costs.
• Risks and potential consequences.
• Urgency and business priority.
• Project schedules and delivery commitments.
• Dependencies between requirements.
• Impacts on related designs and solution components.
• Legal and regulatory implications.
• Effects on stakeholders and operational processes.

Traceability is particularly useful because it helps identify related requirements and designs that may be affected.

Predictive and adaptive approaches

The way changes are assessed depends partly on the delivery approach.

Predictive approach	Adaptive approach
Changes are commonly assessed through a more formal process.	Changes are considered through ongoing collaboration and feedback.
Formal change requests and approvals may be required.	The team may regularly review and reprioritise requirements.
Schedule, scope, cost, and delivery baselines may need to be assessed.	Priorities may be updated as the team learns more about the solution.
Decisions are documented according to the governance process.	Decisions are communicated and recorded using the team's agreed approach.

Neither approach removes the need to understand the impact of a change. The difference is mainly in how the assessment and decision-making process is organised.

Tools and techniques for assessing changes

Business analysts may use:

Impact analysis: Identifies requirements, designs, processes, systems, and stakeholders that could be affected.

Business rules analysis: Checks whether the proposed change follows business rules and policies.

Financial analysis: Examines the costs, benefits, and financial consequences of the change.

Risk analysis: Identifies potential threats and uncertainties associated with the change.

Interface analysis: Examines how the change may affect connections and interactions between systems or components.

Governance processes: Define how changes are submitted, reviewed, authorised, and communicated.

The business analyst may also consult subject matter experts, project managers, sponsors, testers, customers, legal specialists, compliance teams, and regulators.

Example of change assessment

A retailer asks for an additional payment method to be added to its online store.

The business analyst should assess the expected customer benefit, implementation cost, security implications, integration requirements, regulatory obligations, testing effort, and effect on the delivery schedule.

The request should then be considered through the organisation's agreed decision-making process. If authorised, the relevant requirements and designs should be updated, and the decision communicated to affected stakeholders.

The important principle is that a change should be assessed in context, rather than accepted simply because someone has requested it.

7. Approving Requirements and Designs

Approval is the process of obtaining the appropriate agreement that requirements and designs are acceptable and can move forward.

Business analysts help facilitate this process by identifying decision-makers, supporting stakeholder consensus, coordinating reviews, and recording approval decisions.

Approval is important because implementation teams need a clear understanding of what has been agreed.

Verification and approval

Verification and approval are related, but they serve different purposes.

• Verification checks whether requirements and designs meet the expected quality standards and are sufficiently clear, complete, and consistent.
• Approval confirms that the appropriate stakeholders or authorised decision-makers agree to proceed with the requirements and designs.

Requirements and designs should be reviewed for quality and readiness before they are approved for further development.

Steps involved in approval

1. Identify the stakeholders and decision-makers who have authority to approve.
2. Confirm the applicable governance rules and approval criteria.
3. Arrange reviews, workshops, or other suitable approval activities.
4. Resolve questions, disagreements, and outstanding issues.
5. Record the decision and approval status.
6. Communicate the outcome to relevant stakeholders.
7. Store the approved information and supporting records in the appropriate repository.
8. Maintain an audit history of decisions and subsequent changes.

The exact process depends on the organisation, the delivery approach, and any legal or regulatory requirements.

Tools and techniques for approval

Technique	Purpose
Decision analysis	Supports structured evaluation of options and decisions.
Acceptance criteria	Defines the conditions that must be met for a requirement or solution to be accepted.
Item tracking	Records the status of requirements, issues, decisions, and approval actions.
Reviews	Allows stakeholders and implementation team members to examine requirements and designs.
Workshops	Bring stakeholders together to discuss requirements, resolve disagreements, and reach agreement.

Stakeholders involved may include subject matter experts, operational support teams, project managers, sponsors, testers, customers, end users, and regulators.

Why approval records matter

Recording approval decisions creates clarity and accountability. It helps the team understand which version of a requirement was approved, who authorised it, and what changes occurred afterwards.

These records can also support later activities, including user acceptance testing. If a requirement changes after approval, the organisation can review the change history and understand why the decision was made.

The expected output is a set of agreed and approved requirements and designs that are ready to support solution development.

8. How the Activities Work Together

The activities in Requirements and Designs Life Cycle Management are connected. They should not be treated as isolated tasks.

Consider a project to introduce a new customer service system.

First, the business analyst identifies the requirements and links them to business objectives through traceability. The requirements are then maintained so that they remain accurate and accessible.

The analyst works with stakeholders to prioritise the requirements according to value, risk, dependencies, and constraints. If a new request appears, the analyst assesses its impact on the existing requirements, designs, costs, schedule, and delivery commitments.

If the change is considered worthwhile, the appropriate decision-makers authorise it according to the governance process. The requirements and designs are updated, relevant stakeholders are informed, and the decision is recorded.

This creates a continuous cycle of tracking, maintenance, prioritisation, change assessment, and approval.

9. Quick Comparison Table

Activity	Main purpose	Key question
Trace requirements and designs	Understand relationships and dependencies.	What does this requirement support, and what will it affect?
Maintain requirements and designs	Keep information accurate, relevant, organised, and reusable.	Is this information still correct and useful?
Prioritise requirements and designs	Decide importance and implementation order.	What should be delivered first, and why?
Assess changes	Understand the impact and value of a proposed change.	What are the benefits, costs, risks, and consequences?
Approve requirements and designs	Obtain authorised agreement to proceed.	Who needs to agree, and has approval been recorded?

10. Practical Business Analyst Scenario

A hospital plans to introduce an appointment management system. During the project, staff request text message reminders for patients.

A business analyst could manage this request as follows:

Trace: Link the request to the business objective of improving appointment attendance. Identify related patient contact details, communication interfaces, privacy requirements, and testing needs.

Maintain: Record the requirement clearly and update related information where necessary.

Prioritise: Compare the expected benefit with the cost, urgency, risks, dependencies, and other requirements competing for resources.

Assess the change: Examine the technical impact, delivery schedule, financial implications, privacy considerations, and effect on existing designs.

Approve: Obtain agreement from the appropriate decision-makers, record the outcome, update the requirements repository, and communicate the decision to the team.

This example shows how a business analyst manages a requirement throughout its life cycle rather than simply documenting it and moving on.

11. Key Points to Remember for the Course Test

• Requirements and designs evolve as business needs and stakeholder expectations change.
• Life cycle management keeps requirements and designs aligned with business objectives.
• Traceability helps identify relationships, dependencies, and the impact of changes.
• The key traceability relationships covered in the course are derive, depends, satisfy, and validate.
• Maintenance keeps requirements accurate, relevant, organised, and potentially reusable.
• Prioritisation considers business value, cost, risk, dependencies, urgency, compliance, and implementation constraints.
• Change assessment considers benefits, costs, risks, schedules, delivery commitments, and affected requirements.
• Predictive approaches commonly use more formal change assessment and approval processes.
• Adaptive approaches commonly use ongoing collaboration and reprioritisation.
• Approval requires agreement from the appropriate decision-makers.
• Verification checks the quality and readiness of requirements and designs. Approval confirms authorised agreement to proceed.
• Approval decisions, change history, and supporting documents should be recorded and communicated.
• Stakeholder communication and governance are important throughout the life cycle.

12. Conclusion

Requirements and Designs Life Cycle Management helps business analysts keep requirements and designs useful throughout an initiative. The work involves tracing relationships, maintaining information, prioritising according to business value, assessing proposed changes, and securing approval.

The key lesson is that requirements management does not end when requirements are first documented. Requirements and designs must continue to evolve in a controlled way as the business learns more and its needs change. By managing this process effectively, business analysts help teams make informed decisions and deliver solutions that remain aligned with business objectives.