4.2 Maintain Requirements (Task 5.2)

CCBA Certification of Capability in Business Analysis Exam

Track your progress as you read

Finished sections get a check mark.

1 Chapter 1: Introduction & CCBA Exam Foundation

1.1 CCBA Exam Structure, Eligibility & IIBA Framework 1.2 The Business Analysis Core Concept Model (BACCM™) 1.3 Requirements Classification Schema & Architecture 1.4 CCBA Competency & Proficiency Levels (Level 2 — Skilled)

2 Chapter 2: Business Analysis Planning and Monitoring

2.1 Plan Business Analysis Approach (Task 3.1) 2.2 Plan Stakeholder Engagement (Task 3.2) 2.3 Plan Business Analysis Governance (Task 3.3) 2.4 Plan Business Analysis Information Management (Task 3.4) 2.5 Identify BA Performance Improvements (Task 3.5)

3 Chapter 3: Elicitation and Collaboration

3.1 Prepare for Elicitation (Task 4.1) 3.2 Conduct Elicitation (Task 4.2) 3.3 Confirm Elicitation Results (Task 4.3) 3.4 Communicate Business Analysis Information (Task 4.4) 3.5 Manage Stakeholder Collaboration (Task 4.5)

4 Chapter 4: Requirements Life Cycle Management

4.1 Trace Requirements (Task 5.1) 4.2 Maintain Requirements (Task 5.2) 4.3 Prioritize Requirements (Task 5.3) 4.4 Assess Requirements Changes (Task 5.4) 4.5 Approve Requirements (Task 5.5)

5 Chapter 5: Strategy Analysis

5.1 Analyze Current State (Task 6.1) 5.2 Define Future State (Task 6.2) 5.3 Assess Risks (Task 6.3) 5.4 Define Change Strategy (Task 6.4)

6 Chapter 6: Requirements Analysis and Design Definition — Modeling & Architecture

6.1 Specify and Model Requirements (Task 7.1) 6.2 Verify Requirements (Task 7.2) 6.3 Validate Requirements (Task 7.3) 6.4 Define Requirements Architecture (Task 7.4)

7 Chapter 7: Requirements Analysis and Design Definition — Design & Value

7.1 Define Design Options (Task 7.5) 7.2 Analyze Potential Value and Recommend Solution (Task 7.6) 7.3 Estimation Techniques & Solution Trade-Offs 7.4 Acceptance and Evaluation Criteria Definition

8 Chapter 8: Solution Evaluation

8.1 Measure Solution Performance (Task 8.1) 8.2 Analyze Performance Measures (Task 8.2) 8.3 Assess Solution Limitations (Task 8.3) 8.4 Assess Enterprise Limitations (Task 8.4) 8.5 Recommend Actions to Increase Solution Value (Task 8.5)

9 Chapter 9: Essential BABOK Techniques

9.1 Core Elicitation & Analysis Techniques 9.2 Process, Data & Non-Functional Requirements Modeling 9.3 Financial Analysis & Business Case Techniques 9.4 Prioritization & Scope Techniques 9.5 Root Cause & Decision Analysis Techniques

10 Chapter 10: Underlying Competencies & Perspectives

10.1 Analytical Thinking, Problem Solving & Systems Thinking 10.2 Behavioral Characteristics, Communication & Interaction Skills 10.3 Business Acumen, Solution Knowledge & BA Tooling 10.4 The Five BABOK Perspectives in Practice

11 Chapter 11: CCBA Exam Mastery & Scenario Strategy

11.1 Deconstructing CCBA Scenario Questions & BABOK Logic 11.2 Common Traps, Distractors & Subtle BABOK Distinctions 11.3 Comprehensive 8-Week Study Plan & Exam Day Strategy

4.2 Maintain Requirements (Task 5.2)

Key Takeaways Explain This Topic AI

Task 5.2 ensures requirements and designs remain accurate, consistent, and current throughout the initiative and throughout the operational life of the solution post-deployment.

Maintaining requirements for reuse across multiple systems, projects, or business units reduces operational costs and prevents duplicate discovery work.

Essential requirement attributes—such as Absolute ID, Owner, Status, Stability, Priority, Complexity, and Source—must be systematically recorded and updated to support ongoing governance.

Requirements Baselining establishes an immutable, approved snapshot of requirements at a specific milestone, against which all future modifications are formally managed.

Candidate requirements for long-term enterprise reuse include business processes, compliance rules, security and non-functional requirements, and standard data definitions.

Last updated: August 2026

4.2 Maintain Requirements (Task 5.2)

Quick Summary: BABOK v3 Task 5.2 ( Maintain Requirements ) ensures that requirements and designs retain their accuracy, consistency, and currency throughout their operational life cycle—both during project execution and long after the solution is deployed. It establishes mechanisms for requirements reuse across the enterprise, manages requirement metadata attributes, and governs formal baselining.

Purpose and Strategic Role of Task 5.2

The purpose of Maintain Requirements is to retain requirement accuracy and consistency throughout and beyond the change during the entire lifecycle, and to support the reuse of requirements in other solutions. Requirements are not ephemeral project artifacts that are discarded once code is deployed. High-value requirements represent vital organizational assets: business rules, operational workflows, regulatory compliance parameters, and data models that define how the enterprise operates.

When requirements are properly maintained:

Future Projects Start Faster: Initiatives do not need to re-elicit established enterprise business rules from scratch.

Knowledge Transfer is Streamlined: Operational teams understand the exact business logic underpinning existing software.

Continuous Improvement is Supported: Ongoing enhancements, bug fixes, and patch releases build upon a verified, current source of truth. +-----------------------------------------------------------------------------------+

• | BABOK Task 5.2 Structure |
• +-----------------------------------------------------------------------------------+
• | INPUTS: |
• | * Requirements (Verified and documented) |
• | * Designs (Documented solution architecture and models) |
• | |
• | ELEMENTS: |
• | 1. Maintain Requirements (Accuracy, consistency, currency) |
• | 2. Maintain Attributes (Status, priority, stability, ownership, etc.) |
• | 3. Reusing Requirements (Enterprise repositories, standardization) |
• | |
• | OUTPUTS: |
• | * Requirements (Maintained) |
• | * Designs (Maintained) |
• +-----------------------------------------------------------------------------------+
• Core Elements of Requirement Maintenance
• 1. Maintain Requirements (Currency, Consistency, and Accuracy)

Requirements must reflect the current state of the business and technical domain at all times. When software changes during a maintenance release or production patch, the corresponding requirements documentation must be updated concurrently. If requirements drift from the physical system, documentation becomes obsolete ("shelfware"), introducing technical debt and operational risk.

2. Maintain Requirement Attributes

Requirement attributes provide vital metadata that allows business analysts, project managers, and product owners to categorize, query, filter, and govern large volumes of requirements. BABOK v3 defines essential attributes that must be tracked throughout the life cycle. +-----------------------------------------------------------------------------------+

• | Standard BABOK v3 Requirement Attributes |
• +-----------------------------------------------------------------------------------+
• | [ Absolute Reference ] Unique identifier (e.g., REQ-FIN-204) |
• | [ Author / Owner ] Person who authored or has domain accountability |
• | [ Complexity ] High / Medium / Low technical or analytical effort |
• | [ Ownership ] Business unit or stakeholder group holding the need |
• | [ Priority ] Relative importance (Must, Should, High, Med, Low) |
• | [ Risks ] Uncertainties or technical hazards associated with req |
• | [ Source ] Originating SME, regulatory statute, or document |
• | [ Stability ] Likelihood that the requirement will change or evolve |
• | [ Status ] Current state (Proposed, Approved, Verified, Retired) |
• | [ Urgency ] How quickly the requirement must be satisfied |
• +-----------------------------------------------------------------------------------+
• Requirement Attributes Taxonomy Table

Attribute Definition Practical Usage / Exam Clue

Absolute Reference Unique, immutable identifier assigned to the requirement. Never reused even if the requirement is deleted (e.g., FR-104 ).

Author The business analyst or specialist who wrote the requirement specification. Point of contact for clarification during refinement.

Complexity Assessment of how difficult the requirement is to analyze, design, or implement. Informs story point sizing and technical resource allocation.

Ownership The business stakeholder or operational department accountable for the business need. The entity that must approve changes or retire the requirement.

Priority Relative ranking of importance and value compared to other requirements. Governs release sequence and backlog ranking (Task 5.3).

Risks Identified technical, business, or operational uncertainties tied to the requirement. Tracked in risk register; triggers proof-of-concept testing.

Source The originating stakeholder, external law, industry standard, or customer feedback. Used during backward traceability and derivation analysis.

Stability The maturity of the requirement and the likelihood that it will change. Low stability signals volatility; requires agile prototyping.

Status The current stage in the requirement's lifecycle (e.g., Draft, In Review, Baselined). Tracks lifecycle progression and governance readiness.

Urgency Time-sensitivity indicating how immediately the solution must be deployed. Independent of priority; a low-value item may have high urgency.

Requirements Reuse: Enterprise Assets & Repositories

Requirements reuse is the practice of capturing requirements in such a way that they can be leveraged across multiple projects, product lines, business units, or subsequent software versions without repeating the elicitation and modeling effort.

Candidates for Requirements Reuse

Enterprise Business Processes: Standardized corporate workflows (e.g., Employee Onboarding, Customer Dispute Resolution, Procure-to-Pay).

Regulatory and Compliance Mandates: Statutory rules that apply across the entire organization (e.g., GDPR data retention, HIPAA privacy protection, Sarbanes-Oxley audit logging).

Non-Functional Requirements (Quality Attributes): Corporate architectural standards, disaster recovery RTO/RPO limits, cybersecurity encryption protocols, and WCAG 2.1 AA accessibility standards.

Business Glossary and Data Entities: Master data definitions, customer entity schemas, and core business calculation algorithms.

Enterprise Software Capabilities: Standard login/SSO authentication, payment gateway adapters, and notification engines.

Guidelines for Authoring Reusable Requirements

Write in Solution-Independent Language: Focus strictly on the business need and business rules rather than specific UI controls or ephemeral software implementations.

Maintain High Modularity: Express requirements as atomic, cohesive units rather than monolithic narrative paragraphs.

Store in Centralized Repositories: Maintain requirements in accessible enterprise repositories (e.g., Jira Enterprise, Confluence, DOORS, ARIS) with consistent taxonomy and tagging.

Keep Metadata Current: Continually update status, version numbers, and parent-child linkages.

Requirements Baselining

A Requirements Baseline is a formally reviewed and agreed-upon snapshot of a specific set of requirements and designs at a defined point in time. It establishes a trusted reference point for future development, testing, and change control. +-----------------------------------------------------------------------------------+

• | Requirements Baseline Lifecycle |
• +-----------------------------------------------------------------------------------+
• | |
• | [ Draft / In-Review ] ---> [ Formal Approval (Task 5.5) ] |
• | | |
• | v |
• | +==========================+ |
• | | BASELINED REQUIREMENTS | <--- Immutable Reference Point|
• | | (Version 1.0 Locked) | |
• | +==========================+ |
• | | |
• | Proposed Change | |
• | (Task 5.4 Assessment) v |
• | ---------------------> [ Impact Analysis ] ---> [ CCB Approval ] |
• | | |
• | v |
• | +==========================+ |
• | | NEW BASELINE v2.0 | |
• | +==========================+ |
• +-----------------------------------------------------------------------------------+

Baselining Rules:

Once a baseline is established, requirements within that baseline cannot be edited or deleted without formal change control (Task 5.4).

In predictive projects, baselines correspond to major phase gates (e.g., Business Requirements Baseline, System Architecture Baseline).

In adaptive/agile projects, baselines occur at sprint or release boundaries (e.g., Sprint Backlog Commitment, Release Definition of Done).

Enterprise Scenario: Global Pharmaceutical Compliance & Reuse

A global pharmaceutical enterprise develops laboratory information management systems (LIMS) across twelve international manufacturing plants. The lead business analyst creates a centralized Requirements Management Repository.

Standardizing Reusable Assets: The BA extracts 80 core compliance requirements governing FDA 21 CFR Part 11 electronic signatures and audit trails. These requirements are authored in vendor-agnostic language and stored in the enterprise repository.

Attribute Maintenance: Every requirement is tagged with Owner: Global Quality & Regulatory , Stability: High , Status: Baselined , and Source: FDA-Reg-21CFR11 .

Multi-Project Deployment: When Plant 4 and Plant 9 launch localized packaging automation initiatives, they reuse the baselined compliance requirements directly, cutting discovery time by 6 weeks per project.

Post-Deployment Currency: When the European Medicines Agency (EMA) updates digital certificate standards, the BA updates the master repository requirement and conducts an immediate impact analysis across all twelve plants.

Key BABOK v3 Techniques for Task 5.2

Item Tracking: Used to manage the status, history, ownership, and resolution of ongoing requirement modifications, defects, and maintenance updates throughout the operational lifecycle.

Metrics and Key Performance Indicators (KPIs): Tracks the health and stability of requirements (e.g., requirement volatility index, percentage of reused requirements across projects, defect rate traced to requirement ambiguity).

Organizational Modelling: Maps requirement ownership and business rules to specific organizational units, departments, and business roles, ensuring that when corporate restructurings occur, requirement owners are reassigned accurately.

Tip

CCBA Exam Tip: If a question asks which attribute describes how likely a requirement is to undergo changes in the near future, the answer is Stability . Do not confuse Stability (volatility/maturity) with Priority (importance) or Urgency (time-sensitivity).

Warning

CCBA Exam Trap: Remember that maintaining requirements is NOT confined to the duration of a project. BABOK v3 explicitly emphasizes that maintaining requirements continues beyond the project lifecycle throughout the operational life of the solution to support reuse, ongoing maintenance, and retirement.