Business Analysis Notes

Requirements engineering

Managing Requirements Changes

4 min read · Updated

In short Requirements changes are normal; uncontrolled changes are the problem. A light, visible process (a policy, a decision body, impact analysis and a few measures) lets you answer “yes”, “not now” or “no” based on facts.

Based on: K. Wiegers, J. Beatty, Software Requirements, 3rd ed. (Microsoft Press, 2013), ch. 28.

On this page

Key ideas#

Change is not the enemy#

You cannot define every requirement up front, and markets, regulations and business needs shift during a project. The aim is to make change visible and deliberate. The real danger is the back-door change: a developer quietly agrees to a user’s request and skips the process. Wiegers and Beatty describe a customer and contractor whose side deals of this kind ended in court.

Scope creep#

Scope creep is new functionality or a significant modification proposed after the requirements baseline (the agreed, approved set) exists. Citing Capers Jones, the authors note that requirements on information systems projects typically grow 1–3% per month. Growth is not the illness; growth without adjusting schedule, resources or quality is. Defenses: documented business objectives and scope as a filter for every request, customer involvement during elicitation, prototypes, short incremental cycles, and the ability to say “no”, or “not now, perhaps in a later release”. Freezing requirements right after the first round of elicitation is the opposite mistake.

A short policy#

The authors suggest principles along these lines: - every change goes through the process; nothing informal is considered; - no design or build work on unapproved changes, beyond feasibility checks; - submitting a request does not guarantee it will be done; - the change log is visible to all stakeholders; - every change gets an impact analysis; - the reason for each decision is recorded.

Small, local decisions can stay with developers, but anything affecting more than one person goes through the process. Provide a fast track for cheap, low-risk changes; people bypass a cumbersome process, and they are partly right to.

The change control board#

A change control board (CCB) is the group, sometimes one person, that decides on each request. Keep it small. Include product management or analysis, development, testing, the customer or marketing, and support. Large programs can have two levels: project boards for local issues and a program board for cross-project issues and budget or schedule overruns. Write a short charter: purpose, scope of authority (what the board decides and what it escalates), members, meeting rhythm, quorum and decision rule.

Typical roles: chair, board members, evaluator (does the impact analysis), modifier (makes the change), originator, request receiver (single entry point) and verifier. On small projects one person holds several roles.

Request life cycle#

Submitted → Evaluated → Approved, Rejected or Canceled → Change made → Verified → Closed. A failed verification sends the request back. Move a request to the next status only when that step’s exit criteria are met.

Impact analysis#

Before saying “sure, no problem”: 1. Understand the consequences: conflicts with other requirements or the baseline, effects on quality attributes and schedule, and the risk of not making the change. 2. Find every affected item: requirements, screens, reports, database, design, code, build files, tests, documentation, third-party components, project plans. 3. List the tasks and estimate the effort.

The authors’ example: a “simple” wording change in an error message turned out to exceed the maximum field length, both on screen and in the database, in one language version of the product.

Measure change#

Track open and closed requests, requirements added, removed and modified, and requests by source. A volatility chart (new requests per week after the baseline) should fall toward zero as delivery approaches; if it stays high, fix elicitation, not just change control. A sources chart gives you a neutral, factual basis for talking with the department that generates most changes.

On agile projects#

A cross-functional agile team already works like a CCB, and short iterations keep each change small. Teams choose whether to freeze an iteration’s content or allow adjustments; if mid-iteration changes are frequent, shorten the iterations. The product owner decides on the backlog, but changes to overall scope, budget or dates still go up a level.

How to apply it#

  1. Write the policy on one page and get the sponsor to endorse it.
  2. Set up a CCB, even if it is two people, and agree its charter.
  3. Create a single intake point and a shared change log.
  4. Require an impact analysis on the form below; define what qualifies for the fast track.
  5. Review volatility and sources monthly.

Example: change request form outline#

Text
Change request CR-___            Title:
Originator / department:         Date submitted / last updated:
Type: [ ] requirement change  [ ] enhancement  [ ] defect
Description and reason:
Originator's priority:           CCB priority:
Affected requirements (IDs):
Impact analysis: effort ___ h | affected items ___ | risks ___
Decision: [ ] approved for release ___  [ ] rejected  [ ] canceled
Rationale:
Modifier:                        Verifier:
Status:
Response history (append, never overwrite):

Keep the originator’s and the board’s priorities as separate fields, because they often differ. At The Workshop, a fictional bike-repair chain, a manager asks for SMS notifications to include the estimated repair cost. The impact analysis finds that estimates exist only on paper job cards, so the change needs a new data field, a front-desk screen and new tests. The board schedules it for release 2 and records why.

Sources and further reading#

  • K. Wiegers, J. Beatty. Software Requirements, 3rd ed. Microsoft Press, 2013, ch. 28.