Study guide
4.2 Maintain Requirements
CBAP Certified Business Analysis Professional Exam
Track your progress as you read
Finished sections get a check mark.
1 Chapter 1: Introduction & BACCM Framework
1.1 CBAP Exam Structure, Eligibility & Study Plan 1.2 The Business Analysis Core Concept Model (BACCM) 1.3 Key Concepts, Terms & Requirements Classification 1.4 Business Analysis Governance & Stakeholder Engagement Principles
2 Chapter 2: Business Analysis Planning and Monitoring
2.1 Plan Business Analysis Approach 2.2 Plan Stakeholder Engagement 2.3 Plan Business Analysis Governance 2.4 Plan Business Analysis Information Management 2.5 Identify Business Analysis Performance Improvements
3 Chapter 3: Elicitation and Collaboration
3.1 Prepare for Elicitation 3.2 Conduct Elicitation 3.3 Confirm Elicitation Results 3.4 Communicate Business Analysis Information 3.5 Manage Stakeholder Collaboration
4 Chapter 4: Requirements Life Cycle Management
4.1 Trace Requirements 4.2 Maintain Requirements 4.3 Prioritize Requirements 4.4 Assess Requirements Changes 4.5 Approve Requirements
5 Chapter 5: Strategy Analysis
5.1 Analyze Current State 5.2 Define Future State 5.3 Assess Risks 5.4 Define Change Strategy 5.5 Business Case Development & Financial Analysis
6 Chapter 6: Requirements Analysis and Design Definition
6.1 Specify and Model Requirements 6.2 Verify Requirements 6.3 Validate Requirements 6.4 Define Requirements Architecture 6.5 Define Design Options 6.6 Analyze Potential Value and Recommend Solution 6.7 Data Modeling & Process Modeling Techniques 6.8 Use Cases, User Stories & Acceptance Criteria Definition 6.9 Non-Functional Requirements & Solution Constraints
7 Chapter 7: Solution Evaluation
7.1 Measure Solution Performance 7.2 Analyze Performance Measures 7.3 Assess Solution Limitations 7.4 Assess Enterprise Limitations 7.5 Recommend Actions to Increase Solution Value
8 Chapter 8: Underlying Competencies, Techniques & Perspectives
8.1 Analytical Thinking, Problem Solving & Business Knowledge 8.2 Behavioral Characteristics & Interaction Skills 8.3 Core BABOK Techniques Master Review 8.4 Business Analysis Perspectives
4.2 Maintain Requirements
Key Takeaways Explain This Topic AI
Requirements maintenance (BABOK Task 12) ensures requirements and designs remain accurate, standardized, and accessible for ongoing enterprise reuse post-implementation.
Reusable requirements represent long-term enterprise assets, including business rules, regulatory standards, business processes, and structural data models.
Requirement attributes (Status, Author, Priority, Risk, Source, Stability, Version) provide critical metadata for filtering, governance, and lifecycle tracking.
A centralized requirements repository requires defined access controls, baselining protocols, and consistent taxonomies to prevent information corruption.
Post-implementation maintenance transitions project-specific requirements into operational baseline capabilities maintained throughout the solution's operational lifespan.
Last updated: August 2026
- 4.2 Maintain Requirements
- Core Purpose and BABOK v3 Context
In many organizations, requirements are treated as disposable project artifacts—written for a single software release and abandoned once code is deployed. Task 12: Maintain Requirements reframes requirements as valuable, persistent enterprise knowledge assets . The core purpose of maintaining requirements is to ensure that requirements and designs remain accurate, up-to-date, standardized, and accessible for reuse across future initiatives and ongoing operational maintenance.
Effective requirements maintenance saves organizations millions of dollars by eliminating redundant elicitation, preserving historical business logic, streamlining audit compliance, and ensuring that software enhancements do not violate existing enterprise rules.
Requirements Maintenance for Long-Term Enterprise Reuse
Not all requirements are candidates for long-term maintenance and reuse. BAs must evaluate requirements to identify those representing enduring business capabilities rather than transient project implementation details.
Candidate Categories for Requirements Reuse
Enterprise Business Rules : Core operational logic governing business decisions (e.g., credit scoring formulas, insurance premium calculations, customer discount eligibility).
Regulatory and Compliance Requirements : Mandatory legal frameworks (e.g., GDPR data privacy constraints, HIPAA security standards, Sarbanes-Oxley audit logging).
Core Business Processes & Capabilities : Standard operating procedures, supply chain workflows, customer onboarding journeys, and claims handling procedures.
Domain Data Models & Taxonomies : Enterprise data dictionaries, entity-relationship models, API contracts, and customer master data definitions.
Non-Functional Quality Attributes : Standard enterprise security baselines, disaster recovery RTO/RPO targets, and accessibility standards (WCAG 2.1 AA).
Prerequisites for Reusability
To make a requirement reusable, the BA must ensure it is:
Expressed in Clear, Unambiguous Business Terms : Devoid of project-specific jargon, vendor names, or temporary release dates.
Independently Modular : Structured so that changes to one rule do not silently corrupt unrelated business capabilities.
Accurately Tagged with Metadata : Cataloged within an enterprise repository using standard taxonomy keywords.
Requirement Attributes and Standardization
Attributes are metadata elements attached to individual requirements to manage them throughout their lifecycle. BABOK v3 emphasizes that standardizing requirement attributes across an enterprise ensures consistent governance, filtering, and reporting.
- Attribute Name Definition & Lifecycle Purpose Example Value
- Absolute Identifier (ID) Unique, immutable alphanumeric key assigned upon creation. REQ-FIN-2026-0042
Status Tracks lifecycle progression (e.g., Draft, Under Review, Approved, Deferred, Rejected, Implemented, Retired). Approved
Author / Owner Identifies the BA who authored the spec and the business SME accountable for its validity. Author: J. Doe (BA) / Owner: Risk Officer
Priority Relative importance or urgency derived from Task 13 (Prioritize Requirements). Must Have (High)
Source / Origin Tracing origin back to specific stakeholders, regulatory mandates, or customer feedback. SEC Regulation 17a-4 Mandate
Stability / Volatility Indicates likelihood of future change (High stability = core business rule; Low stability = evolving market feature). High Stability (Core Business Rule)
Risk Level Technical, operational, or business risk associated with implementing or failing to implement. Critical (Compliance Breach Risk)
- Version Number Incremental tracking identifier capturing precise revision history. v2.4 (Post-CCB Revision)
- Centralized Repository Architecture & Taxonomy Management
Maintaining requirements at scale requires an enterprise Requirements Repository . A repository is a structured database or ALM tool (e.g., Jama, Jira Align, DOORS, Azure DevOps) designed to store, manage, and baseline requirements information.
Key Repository Capabilities
Baselining : Creating an immutable snapshot of an approved set of requirements at a specific point in time (e.g., "Release 3.0 Baseline"). Once baselined, changes require formal Change Control Board (CCB) approval.
Access Control & Permissions : Restricting editing rights to authorized BAs while providing read-only access to testing and development teams.
Version Control and Audit Trail : Tracking exact text modifications, timestamps, and author IDs for every historical revision.
Taxonomy & Categorization : Organizing requirements hierarchically by business domain, product line, geographic region, or capability model. Enterprise Requirements Repository Taxonomy
- ├── Enterprise Business Rules (Reusable)
- │ ├── Credit Risk Scoring Logic
- │ └── Anti-Money Laundering Thresholds
- ├── Domain Capabilities
- │ ├── Retail Banking Onboarding
- │ └── Commercial Loan Origination
- └── System Release Baselines
- ├── Baseline v1.0 (Deployed 2025-06-15)
- └── Baseline v2.0 (Active Release)
- Post-Implementation Maintenance and Operational Handoff
When a project finishes and the solution is deployed into production, the BA's maintenance responsibility shifts from Project Requirements to Operational Enterprise Requirements .
The Operational Handoff Protocol
Decommission Project-Specific Specs : Remove temporary workarounds, migration rules, and sandbox configuration details.
Update Enterprise Baseline : Integrate newly deployed functional specs and business rules into the permanent enterprise repository.
Transfer Ownership to Operational SMEs : Assign ongoing stewardship of business rules to designated Product Owners or Business Operations Leads.
Archive Historical Context : Retain rationale behind rejected alternatives and historical trade-off decisions to prevent future teams from repeating discarded ideas.
BACCM Connections in Maintenance
Change : Manages ongoing modifications to requirements so the enterprise baseline reflects current operational reality.
Need : Ensures reusable requirements continue to address persistent enterprise needs across multiple projects.
Solution : Maintains accurate documentation of operational solution capabilities post-deployment.
Stakeholder : Provides stakeholders with an accessible, reliable single source of truth for business logic.
Value : Maximizes ROI on business analysis work by enabling cross-project reuse and reducing rework.
Context : Preserves alignment between documented requirements and changing business context (e.g., market shifts, new regulations).
Worked Example: Healthcare Enterprise Reusable Business Rules
Scenario : A national healthcare insurer operates four distinct software applications: Mobile Patient Portal, Customer Service Call Center, Claims Engine, and Provider Billing System. Each platform historically maintained its own separate copy of patient eligibility rules, causing operational discrepancies.
BA Maintenance Strategy :
Extraction & Standardization : The BA extracts eligibility rules across all four systems and standardizes them into a single, modular set of enterprise business rules.
Repository Centralization : The rules are uploaded to a central enterprise repository under the taxonomy ENT-RULE-ELIGIBILITY with attributes defining owner, compliance status, and version ( v3.0 ).
API Reuse : New IT initiatives are mandated to link directly to this central rule repository via microservice APIs rather than re-writing eligibility code locally.
Outcome : When state healthcare legislation alters eligibility thresholds, the BA updates the single baseline rule in the repository, automatically updating all four operational systems and saving an estimated $450,000 in redundant engineering work.
CBAP Exam Tips & Common Pitfalls
💡 Exam Tip : On the CBAP exam, when asked how to handle requirements after project completion, select the option that describes updating the baseline enterprise repository and transferring stewardship to business owners, rather than archiving or deleting project documents.
⚠️ Common Trap : Attributes like Priority and Status are dynamic and change throughout the lifecycle. Do not assume requirement metadata is static. BAs must maintain attribute accuracy continuously as requirements progress through review, prioritization, and implementation.