In Requirements Engineering, managing change is one of the most critical challenges facing software developers. Requirements are rarely static; instead, they evolve as the system is designed, developed, and deployed . To manage this evolution, software engineers classify requirements based on their stability over time.

Requirements are broadly categorized into two main classes:

1. Enduring Requirements: Core requirements that are relatively stable and derive from the principal domain of the customer organization .
2. Volatile Requirements: Dynamic requirements that are likely to change during the system development process or after the system has become operational .

Understanding the distinction between these two classes is fundamental to designing a resilient Software Architecture that can accommodate change without costly redesigns.

Deep Dive: Enduring vs. Volatile Requirements

1. Enduring Requirements

Enduring Requirements are directly related to the core activity of the organization . Because they represent the fundamental business model, they remain stable throughout the software lifecycle.

• Example: In a hospital billing system, the requirement that "a patient record must exist before generating an invoice" is enduring. The core activity of treating and billing patients does not change, regardless of the technology used.
• Architectural Impact: Enduring requirements dictate the core entity model and database schema. Because they are highly stable, developers can build the foundational architecture around them with minimal risk of redesign.

2. Volatile Requirements

Volatile Requirements are temporary, evolving, or subject to external forces. Software engineers subdivide volatile requirements into four distinct types :

• Mutable Requirements: Requirements that change because of changes to the environment in which the organization is operating . For example, a change in national tax laws requires an update to the system's tax calculation modules.
• Emergent Requirements: Requirements that emerge as the customer's understanding of the system develops during development . Stakeholders often cannot fully visualize system behaviors until they interact with prototypes.
• Consequential Requirements: Requirements that result from the introduction of the computer system . Installing a new system changes user workflows, which in turn generates new requirements to support the updated business processes.
• Compatibility Requirements: Requirements that depend on the physical or logical environment of the system . For instance, compatibility requirements change when an external database engine or a third-party payment gateway API updates its version interface.

Calculating Requirements Volatility

To quantify project risk, project managers calculate the Requirements Volatility Index ($V_i$) over a specific time window :

$V_i = \frac{N_a + N_m + N_d}{N_{total}}$

where:

• $N_a$ is the number of requirements added.
• $N_m$ is the number of requirements modified.
• $N_d$ is the number of requirements deleted.
• $N_{total}$ is the total number of requirements in the baseline.

A high value of $V_i$ (e.g., $V_i > 0.30$) indicates that a module is unstable and requires flexible, modular software patterns to isolate changes.