Requirements change management: the process, with an example

Published 22 October 2026

Requirements change management is how a team changes requirements that were already agreed without losing track of what was agreed: each change is requested in writing, its impact is analysed, someone with the authority decides, everything built on the old requirement is updated — the text and its version, the acceptance criteria, the tests, the plan — and the people affected are told. Below are the process step by step, a fast path for small changes, one change followed from request to new version, the changes that never go through the process, how it works in agile, and the signs that it is not working.

Change control is not about stifling change. It’s about providing decision makers with the information that will let them make timely and appropriate decisions to modify the planned functionality.

— Karl Wiegers, The Line in the Sand

What requirements change management is

The SWEBOK Guide, the IEEE Computer Society’s body of knowledge for software engineering, separates the two halves of requirements work. Requirements development is “reaching an agreement on what software is to be constructed”; requirements management is “maintaining that agreement over time” (SWEBOK Guide V4.0a, 2024). Change management is most of the second half.

It starts when there is something to change against: an agreed set of requirements at named versions, a requirements baseline. Wiegers again: “When stakeholders “sign off” on requirements, what they’re really doing is agreeing and committing to a specific requirements baseline (whether they think of it in those terms or not).” Before that point, requirements are still being written; after it, every change is a decision.

Why requirements change, and how much

Wikipedia lists the usual causes: “changes in the environment in which the finished product is envisaged to be used, business changes, regulation changes, errors in the original definition of requirements, limitations in technology, changes in the security environment and so on” (Wikipedia).

The amounts are not small. Capers Jones found that requirements “change at rates in excess of 2% per calendar month”, with measured rates “from less than 1% per calendar month to more than 4% per calendar month” (Software Requirements and the Ethics of Software Engineering). NASA’s software engineering handbook quotes a 2003 JPL report: “The average project experiences about a twenty-five percent change in requirements after the requirements have been defined for the first system release, which causes at least a twenty-five percent schedule slip” (NASA SWE-053).

So the aim is not fewer changes. It is changes that someone decided on. Wiegers describes the other kind: “requirements changes slip in through the back door instead of being approved by the right stakeholders. Such uncontrolled change is a common source of project chaos, schedule slips, and quality problems” (Change Happens).

The requirements change management process

SWEBOK lists what a change process needs: “a means to request changes to previously agreed-upon requirements”, “an optional impact analysis stage”, “a responsible person or group who decides to accept, reject, or defer each requested change”, “a means to notify all affected stakeholders of that decision” and “a means to track accepted changes to closure”. In six steps:

1. Request. In writing, through one channel, against the agreed version. Wiegers’ test for the channel: “If a proposed change isn’t important enough for a stakeholder to take just a couple of minutes to submit it through a standard, simple channel, then it’s not worth considering for inclusion.” The change request template has the form.
2. Record. Give it a number and keep its original wording. Even a request that will be declined gets an entry: someone will ask about it later.
3. Analyse the impact. Which requirements, designs, code, data, tests and documents it touches, and what it costs in days and money. “Skipping impact analysis doesn’t change the size of the task. It just turns the size into a surprise,” Wiegers writes (Change Impact Analysis Practices). The change impact analysis template walks through it.
4. Decide. Accept, reject or defer — by the person or group with the authority, often called a change control board; on a small project that is one or two people. Record the reason in a decision log. In SWEBOK’s words, “accepting a change means accepting its impact on schedule, resources and/or commensurate change in scope elsewhere in the project.”
5. Update everything the change touches. The requirement gets a new version; so do the requirements, criteria and tests that depend on it. Wiegers’ rule for where to start: “start at the highest level of abstraction that the change touches and cascade the impact of the change through related system components.”
6. Verify, tell, close. Check the changed work, tell everyone affected — including when the answer is no — and close the request. NASA’s handbook names one of the follow-through steps that is easiest to skip: “Ensuring that the rest of the project uses only the latest, updated project documents that reflect the requirements change.”

A fast path for small changes

A process heavy enough for a new feature is too heavy for a changed label. Wiegers’ advice: “no change affecting more than one individual’s work should bypass your change control process. However, your process should include a “fast path” to expedite low-risk, low-investment change requests in a compressed decision cycle.”

One commenter’s version, agreed at the start: “Set rules to ‘tweaks’ at the start. e.g. 5 small updates (no more than 1 hr effort each, as an example) Anything more and it’s a change request” (r/projectmanagement, 2026). A fast-path change still gets a number and a line in the log; only the analysis and the decision are shorter.

Make the full process too heavy and it stops being used. Wiegers: “people will find ways to bypass the process—and perhaps they should.”

Requirements change management example

The customer portal from the templates on this site, where customers see and pay their company’s invoices. Phase 1 was signed off against requirements version 1.3. In June, the client’s finance lead asked for CR-10: letting customers pay large invoices in parts.

CR-10  Pay part of an invoice

Asked     10 June, finance lead:
          "Some customers pay large
          invoices in two or three
          goes."
Analysed  12 June: FR-014 changes;
          FR-010, FR-011, FR-015,
          FR-016 and FR-021 are
          affected, with the use case,
          the data, the accounting
          export and six tests.
          9 days; phase 2 one week
          later. Options A, B, C.
          Open: remind about a partly
          paid invoice? (Q1)
Decided   16 June, D-7: yes, the
          reminder covers partly paid
          invoices.
          17 June, D-8: option A, any
          amount. Finance lead.
Updated   Requirements 1.3 -> 1.4:
          FR-014 and five more;
          business rule RULE-06,
          version 2; FR-016 gets a
          fourth acceptance criterion;
          two tests changed, three
          added; the traceability
          matrix; the phase 2 plan.
Kept      Version 1.3, unchanged: what
          phase 1 was signed against.

Each line points to a page that holds the detail: the impact analysis for 12 June, the decision log for D-7 and D-8, the business rule and the acceptance criteria for what changed in FR-016.

The request changed one sentence in one requirement. What it reached was five more requirements, a rule, the tests, an integration and a date. Most of that was found by following links from FR-014. Two things were on no link: the payments table allowed one payment per invoice, which was found in the code, and the accounting export assumed the same, which only the developer who built it knew.

What has to change after a change is approved

• The requirement: new text, a new version, the old version still readable — see how to track changes to requirements.
• The requirements that depend on it, found through the traceability matrix or the links in your tool.
• Business rules that the change touches.
• Acceptance criteria and tests: the ones to change, the ones to run again, the new ones.
• Designs, code and data, and any system it exchanges data with.
• User documentation and training.
• The plan, the cost and the dates, and the contract if there is one — a change order under the statement of work.
• The baseline, at the next natural point: a new baseline after a batch of approved changes.
• The people affected, told what changed and from which version.
• The approval: the changed part signed on its own version — see the requirements sign-off template.

The list is long because a requirement is written in more places than one. The old IEEE standard for requirements specifications warned about exactly that: “a requirement may be altered in only one of the places where it appears. The SRS then becomes inconsistent” (IEEE 830-1998). The person who started one thread asked how others keep up: “If a requirement changes, it means I have to update product requirement documents and Jira stories, and I have to work with designers to update specs” (r/ProductManagement, 2024). The top reply: “That’s the thing, you don’t” (r/ProductManagement). The fewer places a requirement is written in full — and the more places refer to it by ID — the shorter the list.

Informal requirements changes

Some changes never become change requests. A 2016 study of a software vendor and its client, by Hussain, Zowghi and colleagues, found that “informal requirements changes” were “pervasive and unavoidable” — changes “that bypass most of the controls imposed by formal change management processes (e.g. formal review and change impact analysis) and get implemented in the resulting system.” Many were small requests accepted to keep the client happy: “no documents (such as change request forms) were produced. Similarly the client was not billed for the additional effort” (Managing Requirements Change the Informal Way, IEEE Requirements Engineering conference).

They cannot all be stopped, but they can be written down after the fact. A line in the change log — who asked, on which call, what was done — turns a memory into a record; more in informal requirements changes. One commenter on why that matters: “I’ve had multiple clients say something along the lines of “We never agreed to that” but when I’ve been able to show them an email it helps change the mood of the discussion” (Hacker News, 2020).

Requirements change management in agile

In agile teams, SWEBOK notes, change management happens implicitly: “any request to change previously agreed-upon requirements becomes just another item on the product backlog. A request will only become “accepted” when it is prioritized highly enough to make it into an iteration (a sprint).” The Scrum Guide protects the sprint itself: “No changes are made that would endanger the Sprint Goal” (Scrum Guide, 2020).

The backlog replaces the change request form. It does not replace the rest:

• Work already built. A changed requirement for a finished story is new work, and the finished story’s text now describes a rule that no longer holds — see requirements in Jira.
• A signed scope. On a client project with a contract, a change still has a price and a date, and someone on the client’s side still has to agree to them.
• Audited or regulated requirements, where every change needs a record of who decided and why.

“If your process doesn’t allow you to control the rate of change in requirements, your process is not agile, but haphazard,” as one Stack Exchange answer puts it (Stack Exchange, 2010). What to do when a change arrives mid-sprint, after sign-off or every week is in how to handle changing requirements.

Change control, change management and configuration management

Wikipedia notes “considerable overlap and confusion between change management, configuration management and change control” (Wikipedia). One change followed through all of them is in change control vs change management.

Measuring requirements change

Wiegers suggests counting the change requests received, open and closed; where they come from; how many changes each requirement has had since the baseline; and the effort spent on them (Using Change Control Tools). The frequency of change, also called requirements volatility, “should trend toward zero as the project approaches its ship date.” His formula: “divide the number of changes by the total number of requirements at the beginning of the period” (Measuring Requirements). A worked example is in requirements volatility.

A simpler measure works for a client: a visible list of everything added since the project started. One commenter’s reason for keeping one is that stakeholders “don’t see the cumulative effect of 15 small asks over 3 months” (r/projectmanagement, 2026).

Tools for requirements change management

“Remember, though: a tool is not a substitute for a process,” Wiegers writes. What a tool adds is a record: each request’s status, who changed it and when, who was notified, and a link from the request to the requirements it changes. On a small project, NASA’s handbook allows that “spreadsheet programs may be used to manage the requirements and track changes to them”. Where the common tools fall short is covered in requirements in Jira, requirements in Confluence and requirements in git. Which tool holds what, and who decides, can be written down once in a requirements management plan.

Signs that requirements change management is not working

• Changes are found in testing. Wiegers’ example: “developers introduced new and modified functionality that the rest of the team didn’t discover until system testing.”
• Requests stay open for months. “Change requests that remain unresolved for a long time suggest that your change management process isn’t working well.”
• A storm of requests right after the baseline — “a clue that your requirements elicitation activities were incomplete”.
• Nobody can say which version was signed, or the same requirement reads differently in the document, the ticket and the test.
• Work arrives without a decision. That is scope creep; when the documents fall behind the work, it is spec drift.

Requirements change management checklist

1. A baseline exists, with a version and the names of who approved it.
2. Every change has a number, a requester and its original wording.
3. Every change has an impact analysis — short for small changes, full for large ones.
4. Someone with the authority decides, and the reason is recorded.
5. The requirement gets a new version; the old one stays readable.
6. Dependent requirements, criteria and tests are updated, and found through links, not memory.
7. The plan, the cost and the contract are updated.
8. Everyone affected is told, including when the answer is no.
9. Informal changes are written down after the fact.
10. The baseline is renewed at natural points, not silently.

Where Specroot fits

This is the problem Specroot works on: every agreed requirement kept with its versions, the request and the decision behind each change, and the links to what was built on it — so that a change reaches everything it touches. Specroot for agencies and consultancies.