4.2 Maintain Requirements (Task 5.2)
Key Takeaways
- 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.
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, andSource: 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.
A business analyst is configuring metadata attributes for an enterprise requirements management repository. A senior software architect requests a field that specifically tracks how mature the requirement is and the likelihood that it will undergo further changes before implementation. Which BABOK v3 requirement attribute directly fulfills this requirement?
An enterprise business analyst is establishing a reusable requirements repository for a multi-national financial institution. Which of the following requirement sets represents the BEST candidate for long-term enterprise reuse across multiple future digital banking initiatives?
A business analyst on a major enterprise ERP implementation is notified that a business stakeholder wants to alter an approved and baselined billing calculation requirement mid-way through development. What is the standard BABOK v3 governance procedure for handling changes to baselined requirements?