Requirements change during the RE process and after a system has gone into service is inevitable. Developing software requirements focuses attention on software capabilities, business objectives and other business systems. As the requirements are elicited and analysed, you normally develop a better understanding of users’ needs. This feeds information back to the user who may then propose a change to the requirements. Furthermore, 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:
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, treatments, etc. These requirements may be derived from domain models that show the entities and relations which characterise an application domain (Prieto-Díaz and Arango, 1991, Easterbrook, 1993).
Volatile requirements These are requirements that are likely to change during the system development process or after the system has been become operational. Examples of volatile requirements are requirements resulting from government health-care policies or healthcare charging mechanisms.
Harker and others (Harker et al., 1993) suggested that volatile requirements fall into five classes. Using these as a base, I have developed the classification shown in the following table:
| Requirement type | Description | |
|---|---|---|
| Mutable requirements | Requirements that change because of changes to the environment in which the organisation is operating. For example in hospital systems the funding of patient care may change and thus require different treatment information to be collected. | |
| Emergent requirements | Requirements that emerge as the customer's understanding of the system develops during the system development. The design process may reveal new emergent requirements. | |
| Consequential requirements | Requirements that result from the introduction of the computer system. Introducing the computer system may change the organisations processes and open up new ways of working which generate new system requirements. | |
| Compatibility requirements | Requirements that depend on the particular systems or business processes within an organisation. As these change the compatibility requirements on the commissioned or delivered system may also have to evolve. |
References
Prieto-DÌaz, R. and Arango, G. (1991). Domain Analysis and Software System Modeling. Los Alamitos CA.: IEEE Press.
Easterbrook, S. (1993). “Domain Modelling with Hierarchies of Alternative Viewpoints”. Proc. RE ’93, San Diego, USA.
Harker, S. D. P., Easton, K. D., et al. (1993). “The Change and Evolution of Requirements as a Challenge to the Practice of Software Engineering”. Proc. RE ’93, San Diego, USA.