Enduring and volatile requirements

Requirements evolution during the RE process and after a system has gone into service
is inevitable. Developing software requirements focuses attention on softwarecapabilities, business objectives and other business systems. As the requirements
definition is developed, you normally develop a better understanding of users needs.
This feeds information back to the user, who may then propose a change to the
requirementsFurthermore, it may take several years to specify and
develop a large system. Over that time, the system's environment and the business
objectives change, and the requirements evolve to reflect this.
From an evolution perspective, requirements fall into two classes:
I. Enduring requirements These are relatively stable requirements that derive from
the core activity of the organisation and which relate directly to the domain of
the system. For example, in a hospital, there will always be requirements concerned
with patients, doctors, nurses and treatments. These requirements may
be derived from domain models that show the entities and relations that characterise
an application domain (Easterbrook, 1993; Prieto-Diaz and Arango, 1991).
2. Volatile requirements These are requirements that are likely to change during the
system development process or after the system has been become operational. An
example would be requirements resulting from government healthcare policies.