Volatile Requirements
Definition
Volatile requirements are requirements that are likely to change during development or after deployment — due to evolving business needs, technology changes, regulatory updates, or better understanding gained over time.
Common Causes of Volatility
- Changing business environment — market conditions, competitor actions, new opportunities
- Evolving technology — new platforms, APIs, third-party services being updated/deprecated
- Regulatory/legal changes — new compliance rules
- Incomplete initial understanding — stakeholders learn more as the project progresses
- Changing stakeholder priorities — organizational shifts, new management
- User feedback — from prototypes, pilot testing, or early releases
Examples
- "Support login via the latest social media platform's OAuth API" (APIs change often)
- "Comply with the current data privacy regulation" (laws get amended)
- "Support the newest mobile OS version" (yearly updates)
Managing Volatile Requirements
- Requirements Traceability Matrix (RTM) — track where each requirement originates and what depends on it
- Change Control Process / Configuration Management — formal process to evaluate, approve, and track changes
- Modular/flexible architecture — isolate volatile parts so changes don't ripple through the whole system
- Agile/iterative models — better suited to accommodate volatility than rigid Waterfall
- Prioritize and version SRS documents
Impact if Not Managed
- Scope creep
- Schedule and budget overruns
- Increased testing/regression burden
- Architectural instability if volatile parts aren't isolated
Exam tip: Pair this with Enduring Requirements in your answer — contrast table, causes of volatility, and 2–3 management techniques (RTM, Change Control, Agile) are the key points examiners look for.