Business Analysis 101: Requirements Life Cycle Management Managing Requirements Changes Change Control Impact Analysis

What This Is

Managing Requirements Changes – often called Change Control – is the disciplined way a Business Analyst (BA) tracks, evaluates, approves, and incorporates any alteration to the baseline requirements after they have been formally documented. It protects the project from scope creep, ensures that every change is understood, and that its ripple‑effects on schedule, cost, risk, and downstream artifacts are visible.

Real‑world example: A financial services firm is rolling out a new CRM system. Mid‑project the sales director asks for an additional “real‑time social‑media sentiment score” on each customer record. The BA must capture this request, assess its impact on the data model, integration points, and testing effort, and run it through the change‑control process before the development team can start work.

Key Terms & Techniques

• Change Request (CR) – A formal proposal to modify a requirement, deliverable, or baseline. Knowledge Area: Requirements Life Cycle Management (RLCM). Deliverable: Change Request Log.
• Baseline – The approved version of requirements (or any other project artifact) that serves as the reference point for measuring change. KA: RLCM. Deliverable: Baseline Requirements Document.
• Impact Analysis – Systematic assessment of how a proposed change affects scope, schedule, cost, quality, risk, and other requirements. KA: RLCM. Deliverable: Impact Analysis Report.
• Change Control Board (CCB) – A cross‑functional decision‑making body (often includes the sponsor, project manager, and key stakeholders) that reviews, approves, or rejects change requests. KA: Business Analysis Planning & Monitoring (BAPM). Deliverable: CCB Decision Log.
• Traceability Matrix – A grid linking requirements to design, test cases, and other artifacts; used to see what will be impacted by a change. KA: RLCM. Deliverable: Requirements Traceability Matrix (RTM).
• Version Control – The practice of assigning version numbers and maintaining a repository of requirement documents so that the current baseline is always identifiable. KA: BAPM. Deliverable: Version‑controlled Repository (e.g., SharePoint, Git).
• MoSCoW Prioritization – Categorizing requirements as Must, Should, Could, or Won’t have; helps the BA decide which changes are acceptable within constraints. KA: Elicitation & Collaboration. Deliverable: Prioritization Worksheet.
• Stakeholder Impact Assessment – Identifying which stakeholder groups are affected by a change and how their needs shift. KA: Stakeholder Analysis (part of BAPM). Deliverable: Stakeholder Impact Register.
• Configuration Management (CM) – Controlling the integrity of requirement artifacts, ensuring that only authorized versions are used. KA: BAPM. Deliverable: CM Plan & CM Log.
• Decision‑Making Techniques – Structured methods such as Weighted Scoring, Decision Tree, or Cost‑Benefit Analysis used by the CCB to evaluate a change. KA: Elicitation & Collaboration. Deliverable: Decision‑Making Output (e.g., Scoring Sheet).
• Rollback Plan – A predefined set of steps to revert the solution to the previous baseline if a change proves problematic. KA: Solution Evaluation. Deliverable: Rollback Procedure Document.

Step‑by‑Step / Process Flow

1. Capture the Change Request – Log the request in the Change Request Log; include who raised it, description, and business justification.
2. Initial Screening – Perform a quick feasibility check (e.g., does it align with the business objectives?) and assign a priority using MoSCoW.
3. Conduct Impact Analysis – Use the Traceability Matrix, version‑controlled artifacts, and stakeholder impact assessment to quantify effects on scope, schedule, cost, risk, and downstream requirements. Document findings in an Impact Analysis Report.
4. Present to the Change Control Board – Share the CR, impact analysis, and any decision‑making artifacts (e.g., cost‑benefit). The CCB decides to Approve, Reject, or Defer the change.
5. Update Baseline & Communicate – If approved, update the requirements baseline, version numbers, and the RTM; notify all impacted stakeholders and adjust the project plan accordingly.
6. Monitor & Verify – Track the implementation of the change, ensure that test cases reflect the new requirement, and close the CR once verification is complete.

Common Mistakes

Certification Exam Tips

1. Know the Input/Output Relationships – For Change Control, the primary inputs are the Change Request and the Baseline Requirements; the outputs are the Updated Baseline, Change Log, and Updated Traceability Matrix. Exam questions often ask you to match inputs to the correct knowledge area.
2. Distinguish Knowledge Areas – Impact Analysis belongs to Requirements Life Cycle Management, while the Change Control Board is part of Business Analysis Planning & Monitoring. Mixing these up is a common trap.
3. “What does the BA do next?” – After a change request is logged, the BA’s next activity is conducting impact analysis (not yet updating the baseline). Remember the sequence: Capture → Analyze → Present → Update.
4. Prioritization vs. Approval – MoSCoW is a prioritization technique; it does not replace the formal CCB approval process. If a question links MoSCoW to “authorizing” a change, the answer is No.

Quick Check Questions

1. Scenario: After a stakeholder workshop, the sales team asks to add a “customer loyalty score” to the CRM. The BA has already baseline‑d the requirements. Which technique should the BA use first?
   Answer: Impact Analysis.
   Why: The BA must assess how the new score affects data structures, integrations, and testing before any decision is made (BABOK §5.5).

2. Scenario: A change request is logged, and the BA discovers that the proposed change will affect three downstream test cases and one user manual section. What artifact helps the BA quickly identify these links?
   Answer: Requirements Traceability Matrix.
   Why: The RTM maps each requirement to its associated design, test, and documentation artifacts, making impact identification efficient (BABOK §5.5).

3. Scenario: The project sponsor verbally approves a change to add a new report. The BA updates the requirement document immediately. Which BABOK principle has been violated?
   Answer: Formal Change Control (CCB approval).
   Why: Even sponsor‑driven changes must go through the CCB and be documented in the Change Request Log; bypassing this breaks the controlled baseline process (BABOK §5.4).

Last‑Minute Cram Sheet (10 one‑liners)

1. RLCM = Requirements Life Cycle Management – home of Change Control and Impact Analysis.
2. Baseline = Approved, version‑controlled set of requirements; the reference point for any change.
3. Change Request Log = Input to Impact Analysis; output of CCB decision.
4. Impact Analysis → Output: Updated Baseline, Updated RTM, Change Log.
5. CCB = Change Control Board; not the BA – the BA facilitates, the CCB decides. ⚠️
6. Traceability Matrix = Shows downstream artifacts; essential for impact identification.
7. MoSCoW = Prioritization only; does not replace formal approval. ⚠️
8. Version Control = Required for every baseline change; ensures a single source of truth.
9. Stakeholder Impact Assessment = Part of Impact Analysis; identifies who is affected and how.
10. Rollback Plan = Belongs to Solution Evaluation; prepared when a change is high‑risk.

Keep these nuggets handy, and you’ll be ready to ace the exam and keep your projects on track when requirements evolve!