Managing Changing Requirements

Managing Changing Requirements

No set of requirements survives first contact with reality unchanged. A clinic discovers mid-project that regulators now require two-factor authentication. An online store's marketing team decides to add a flash-sale countdown timer — after the cart module is already built. A logistics firm's operations director realises the original route-optimisation rules were wrong. Change is not an exception; it is the normal condition of software projects. The analyst's job is not to prevent change but to manage it so that the project can absorb it without fracturing.

This lesson covers the three interlocking disciplines that make change manageable: a formal change-control process, requirements versioning, and scope-creep prevention.

Why Requirements Change

Understanding the root causes of change helps you anticipate and respond to them rather than simply reacting. Common drivers include:

• Business environment shifts — a competitor launches a new feature; a regulator issues a new rule; the company pivots its strategy.
• Stakeholder misalignment surfacing late — two departments gave contradictory requirements that nobody noticed until integration testing.
• Incorrect initial understanding — the analyst or stakeholder misunderstood the domain; prototype demos expose the gap.
• Technology constraints discovered late — a third-party API cannot support the agreed feature set.
• Scope growth ("gold plating") — developers or product owners add features not in the original agreement, often with good intentions.

The Change-Control Process

A change-control process is a defined, repeatable workflow for evaluating, approving, recording, and implementing every proposed change to baselined requirements. The word "baselined" is important: once a version of the requirements has been reviewed and formally approved, it becomes a baseline — a controlled snapshot. All changes to that baseline must go through the process.

The workflow below reflects industry practice (aligned with IEEE 830, BABOK, and standard SDLC governance):

Each stage has a clear purpose:

1. Submit a Change Request (CR). Any stakeholder, developer, or tester can submit a CR. A standard form captures: the requestor's name, date, affected requirement IDs, a description of the desired change, and its business justification.
2. Log and assign a unique ID. The BA or PM enters the CR into a change log (a spreadsheet, Jira ticket, or dedicated tool). Every CR gets a unique identifier (e.g., CR-0047) and an owner responsible for progressing it.
3. Impact assessment. The BA and technical lead analyse what happens if the change is implemented: which requirements are affected, how many hours of rework are estimated, what tests must be re-run, and whether the delivery date or budget needs adjustment.
4. CCB decision. The Change Control Board — typically the PM, BA, a technical lead, and a key business stakeholder — reviews the impact assessment and votes: approve, reject, or defer. Small projects may replace the CCB with a simple sign-off by the sponsor.
5. Implement or document rejection. Approved changes update the SRS, are assigned to a sprint or iteration, and trigger regression testing. Rejected changes are logged with the reason so the rationale is auditable later.

Requirements Versioning

Versioning means maintaining a numbered history of every approved state of your requirements document so you can always answer: "What did we agree to on 3 March, and how does it differ from what we agreed on 15 May?"

A lightweight but effective versioning scheme for an SRS looks like this:

• Major version (1.0, 2.0) — a new baseline following a formal review and sign-off.
• Minor version (1.1, 1.2) — approved changes that do not alter the fundamental scope.
• Draft suffix (1.2-draft) — working copies under review, not yet approved.

Crucially, each version must include a revision history table at the top of the document:

When developers ask "are we building the 24-hour cancellation rule or the 2-hour rule?", this table provides an unambiguous answer tied to dates and decisions — not to people's memories.

Scope Creep: Recognising and Preventing It

Scope creep is the gradual, uncontrolled expansion of a project's scope — often through individually reasonable-sounding additions that collectively derail the timeline, budget, and quality of the original deliverable.

The classic signs in a logistics firm's tracking system project include:

• A driver asks the developer directly to "just add a fuel-consumption report — it will only take an hour."
• A stakeholder says "while you're there, can you also show the weather forecast on the route screen?"
• A developer gold-plates the UI with animations that were never requested.

None of these requests is inherently wrong. They may be genuinely valuable. The problem is process bypass: the change bypasses impact assessment, the CCB has no visibility, the change log is not updated, the SRS is not revised, and the test plan is not extended. The team carries hidden scope that nobody accounted for.

Prevention strategies:

1. Baseline early and communicate it. Once requirements are signed off, distribute the baselined SRS to all stakeholders. "That is not in v1.0" becomes a factual, non-confrontational answer.
2. Redirect all requests through the CR form. Train stakeholders and developers alike: every new idea, however small, gets a CR ID before any work begins. This does not mean saying no — it means saying "let us assess it properly."
3. Use a product backlog for future ideas. An agile-influenced "parking lot" backlog captures good ideas without injecting them into the current scope. It keeps conversations positive: "Great idea — it goes into the backlog for Phase 2."
4. Track velocity of approved changes. If more than 15–20% of your original requirements have been modified by the midpoint of the project, that is a warning signal requiring a formal scope re-negotiation with the sponsor.

Keeping Requirements Traceable Through Change

Every time a requirement changes, your traceability matrix must be updated. If FR-07 (the appointment-cancellation rule) is revised via CR-0031, then every design document, test case, and user story that references FR-07 must be flagged for review. Without this discipline, the system gets built to the old requirement while the SRS says something different — a silent, expensive divergence.

Linking CR IDs directly to requirement IDs in your traceability matrix (a topic covered in Lesson 9) is the mechanism that closes this loop.

Practical Summary

Managing changing requirements is fundamentally about making the invisible visible. Every change has a cost, a risk, and a trade-off. The change-control process makes those costs explicit and places the decision with the people who have the authority and context to make it. Versioning makes the history auditable. Scope-creep prevention keeps the project honest. Together, these three practices are what separate projects that finish from projects that drift.