Skip to content

Requirements Volatility

Treat frequent, substantive change in a system's requirements as a measurable churn rate matched against the team's absorption capacity, then flatten Boehm's cost-of-change curve so late changes force only local rework rather than cascading redesign.

Core Idea

Requirements volatility is the software-engineering condition in which the specification of what a system must do changes frequently and substantively during development, often faster than the team can absorb it into design, code, test, and docs. It crystallised as a critique of waterfall's assumption of a stable upfront baseline. Boehm's cost-of-change curve — the cost of accommodating a change rises steeply as the project advances — gives volatility its economic teeth: high volatility in late phases produces catastrophic rework.

Scope of Application

Requirements volatility lives across the software-engineering disciplines that share its object — a formal requirements specification maintained by a development team under change pressure.

  • Requirements engineering — the central object of elicitation, prioritisation, traceability, and change management.
  • Software process — the standing argument for iterative and agile delivery over waterfall.
  • Architecture and design — motivates loose coupling, dependency inversion, hexagonal style, feature flags, extension points.
  • Project management and contracting — drives backlog refinement, rolling-wave planning, change-control boards.
  • Testing and documentation — justifies regression-suite, CI, and living-specification investment.

Clarity

Naming requirements volatility reframes a moralised complaint as a diagnosable condition. Untreated, frequent change reads as scope creep or indiscipline, inviting the "fix" of pinning requirements down harder upfront. The concept relocates the cause: much volatility is a substrate property of the customer's evolving understanding and a world moving faster than a development cycle, neither of which a thicker document stabilises — and the reflexive remedy is the one empirically tied to higher failure rates.

Manages Complexity

Without the concept, a stream of changing requirements presents as an open series of one-off grievances. Volatility compresses that scatter into a single measurable parameter — churn rate — matched against a single capacity, the team's bandwidth for absorbing change. Boehm's curve then collapses "what should we do?" into three separable branches: suppress via tighter upfront spec, absorb-by-process via short iterations, or absorb-by-architecture via coupling and extension-point moves that flatten the slope.

Abstract Reasoning

The concept licenses a diagnostic move (separating irreducible substrate volatility from genuine indiscipline by asking whether thicker specification would stabilise it), a predictive move (reading a change's cost off Boehm's curve, with local-versus-cascading rework as the decisive signature), and an interventionist move over a three-branch menu (suppress / absorb-by-process / absorb-by-architecture) selected by matching measured volatility rate against absorption capacity.

Knowledge Transfer

Within software engineering the concept transfers as mechanism across every discipline sharing its object — the diagnostic, the two-quantity framing, Boehm's curve, and the three-branch menu carry intact from requirements engineering through architecture to contracting and testing. Beyond software it does not travel with its machinery; what recurs is a deeper structural shape — a non-stationary objective tracked by a bounded-rate adapter (concept drift, drifting servo set-points, the OODA loop, Red Queen dynamics). That pattern is carried by neighbouring primes such as feedback and adaptation, not by requirements volatility's own cost-of-change curve and churn machinery.

Relationships to Other Abstractions

Local relationship map for Requirements VolatilityParents appear above the current abstraction, mutual partners to the right, and children below. Node labels state whether each abstraction is prime or domain-specific; colors identify relation types.RequirementsVolatilityDOMAINPrime abstraction: Non-Stationary Objective — is a decomposition ofNon-StationaryObjectivePRIME

Current abstraction Requirements Volatility Domain-specific

Parents (1) — more general patterns this builds on

  • Requirements Volatility is a decomposition of Non-Stationary Objective Prime

    Requirements volatility is a non-stationary objective specialized to a software specification changing near or above the team's convergence rate.

Hierarchy path (1) — routes to 1 parentless root

Neighborhood in Abstraction Space

Requirements Volatility sits in a sparse region of the domain-specific corpus (71st percentile for distinctiveness): few abstractions share its structure, so a faithful description tends to retrieve it precisely.

Family — Proxy Metrics & Venture Adaptation (13 abstractions)

Nearest neighbors

Computed from structural-signature embeddings · 2026-07-12