Requirements volatility: definition, formula and metrics

Published 22 October 2026

Requirements volatility is how much the agreed requirements change over a period: the number of requirements added, changed or deleted after the baseline, divided by the number of requirements in the baseline. It tells you whether the requirements are settling as the release approaches, which requirements keep moving, and where the changes come from. Below are the formula, a worked example, what is normal, the metrics worth tracking, volatile requirements, volatility in agile, and how to use the number without turning it into blame.

The intent is not to try to eliminate requirements volatility. There are often good reasons to change requirements.

— Karl Wiegers, Measuring Requirements: Status, Requests, Changes

Requirements volatility formula

Wiegers’ formula: “To calculate requirements volatility over a given time period, divide the number of changes by the total number of requirements at the beginning of the period (for example, at the time a baseline was defined).”

volatility = changes in the period
             / requirements at the start
               of the period

changes = requirements added
        + requirements changed
        + requirements deleted

Two rules make the number mean something:

• Count from the baseline. “Don’t count changes made before baselining; you know the requirements are still evolving prior to establishing the baseline” (Using Change Control Tools). Before the requirements baseline, changing them is the work.
• Count requirements, not requests. Wiegers notes that “a single change request potentially can affect multiple requirements of different levels and types”. One request that changes six requirements is six changes.

Requirements volatility example

The customer portal from the other templates on this site. Say the requirements agreed as version 1.0 on 28 January held 40 requirements. The changes after that come from the change log:

Phase 1 ran on the first baseline: two changes to 40 requirements in four months, 5% in all, and none in the last two months before sign-off — the shape a release should have. June is phase 2, measured against the new baseline of 41 requirements, and one request moved 15% of them. A spike like that is not a problem in itself; it is a question for the board: is this one large change, or the start of many?

Requests that changed nothing are not in the count: CR-6 was declined and CR-8 deferred. They show up in a different metric, the number of requests.

What is a normal rate of requirements change?

The published figures are averages over very different projects, so treat them as a range, not a target. Capers Jones: requirements “change at rates in excess of 2% per calendar month”, and “The measured rates of change for requirements run from less than 1% per calendar month to more than 4% per calendar month” (Software Requirements and the Ethics of Software Engineering). His illustration: a large application that “starts at a nominal 10,000 function points” over a 36-month schedule can have “another 3,000 function points to be added in mid development, and these will probably add at least six months to the development schedule.”

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).

Requirements volatility metrics to track

These follow Wiegers’ list in Using Change Control Tools. The first is the one to chart: it “should trend toward zero as the project approaches its ship date. A sustained high frequency of changes implies a risk of failing to meet your schedule commitments.”

The last is the simplest, and the one clients understand. One commenter keeps “a visible ‘added since kickoff’ list”, because stakeholders “don’t see the cumulative effect of 15 small asks over 3 months” (r/projectmanagement, 2026).

Where requirement changes come from

“Record where the change requests come from: marketing, users, sales, management, developers, and so on,” Wiegers advises. In the portal, the four requests of phase 1 came from the product owner (CR-5), the marketing lead (CR-6) and the head of sales (CR-7, CR-8); the large phase 2 change came from the finance lead (CR-10).

His reason: the origins “will tell you who to work with to reduce the number of overlooked, modified, and misunderstood requirements” — a stakeholder who was not asked, a process nobody walked through. And the data makes that conversation easier: “Using data as a starting point for such discussions is more constructive than holding a confrontational meeting stimulated by frustration.”

Volatile requirements

Some requirements are more likely to change than others. The SWEBOK Guide’s example: in a banking application, “requirements for functions to calculate and credit interest to customers’ accounts are likely to be more stable than requirements to support different tax-free accounts”, which “may be rendered obsolete by a change in government legislation” (SWEBOK Guide V4.0a). Its advice: “Identifying potentially volatile requirements helps the software engineer establish a design more tolerant of change.”

Counting changes per requirement finds them after the fact. In the portal, the payment requirement FR-014 and everything that shows an invoice’s balance moved together in June — a sign that payment rules belong in one place in the design.

Requirements volatility in agile

In an agile team, new requests go to the backlog, so the backlog changing is normal. What is worth measuring is change to what was committed: stories added to or removed from a running sprint, and changes to the scope of a release. One answer to “How to measure scope change?” on Project Management Stack Exchange: “If you started with 100 story points and now you have 125 story points, you can say that scope has increased by 25%.” It comes with a caveat worth keeping: “The potential problem is that you are not measuring scope increase but the inability of people to estimate tasks accurately” (Project Management Stack Exchange, 2020). Counting stories or requirements avoids the estimating problem; counting points includes it.

How to use requirements volatility

• Expect it to fall near a release. Wiegers: “Changes become more expensive as the product nears completion, and a sustained high level of approved change requests makes it difficult to know when you can ship the product.” A cutoff date helps it fall.
• Read a sustained high rate as a gap, not bad luck. Wiegers: it “probably also indicates that the original baselined requirements were incomplete”.
• Read high volatility from one source as a conversation to have, with the numbers in hand.
• Do not aim for zero. A project with no changes after the baseline either got everything right or is not hearing its users.
• Do not use it to blame. The number describes the project, not the person who asked.

NASA’s handbook puts the warning plainly: “Changes to requirements can be an indicator of software instability or an unclear description of the end product.” Ignored, the number shows up elsewhere. One commenter’s summary of what went wrong with Healthcare.gov: “The root causes were requirements churn, split development, and no project coordinator” (Hacker News, 2013).

Where Specroot fits

This is the problem Specroot works on: every change to the agreed requirements recorded against the baseline it changed, with the request and the person behind it — so that how much the requirements moved is something you can count, not estimate. Specroot for agencies and consultancies.