4.2 Maintain Requirements

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

1. Enterprise Business Rules: Core operational logic governing business decisions (e.g., credit scoring formulas, insurance premium calculations, customer discount eligibility).
2. Regulatory and Compliance Requirements: Mandatory legal frameworks (e.g., GDPR data privacy constraints, HIPAA security standards, Sarbanes-Oxley audit logging).
3. Core Business Processes & Capabilities: Standard operating procedures, supply chain workflows, customer onboarding journeys, and claims handling procedures.
4. Domain Data Models & Taxonomies: Enterprise data dictionaries, entity-relationship models, API contracts, and customer master data definitions.
5. 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.

---

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

1. Decommission Project-Specific Specs: Remove temporary workarounds, migration rules, and sandbox configuration details.
2. Update Enterprise Baseline: Integrate newly deployed functional specs and business rules into the permanent enterprise repository.
3. Transfer Ownership to Operational SMEs: Assign ongoing stewardship of business rules to designated Product Owners or Business Operations Leads.
4. 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:

1. Extraction & Standardization: The BA extracts eligibility rules across all four systems and standardizes them into a single, modular set of enterprise business rules.
2. 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).
3. 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.