What are requirements?
Aaron Sloman

This is a note added to the Open Letter to my MP about government IT procurements and the iSoft affair.

Some of the comments received made me realise that I was using the word 'requirement' in a more general way than some software engineers do.

I have learnt that some software engineers use the English word 'requirements' to refer to a set of agreed features of a target system built into a contract. However the word has a more general use which allows it to refer both to contractual requirements and to what is required in a system to enable it to achieve its intended goals or serve its purpose. (There may be different sets of requirements, in the latter sense, if there are different sets of jointly necessary and jointly sufficient conditions for achieving the goals.)

Where my open letter claims (a) that requirements are often hard to elicit fully prior to the development process and (b) that requirements can change during system development, it is using the more general notion of 'requirement relative to some set of agreed goals or needs'.

High level goals of the NHS Project
In the case of the NHS project the goals, as I understand them, include producing an integrated IT system linking hundreds of hospitals, medical practices and other services concerned with health care around the country, and which:

• ensures that required information stored anywhere in the system is always available where it is needed (e.g. at the point of care),
• makes it easier and faster to discover options, book appointments order tests and see results, anywhere,
• helps to ensure consistent good practice treatments,
• reduces errors in medical or associated decisions and actions.
• saves paper, and makes huge savings on the 30% of all NHS costs that are associated with recording, transporting, storing, and looking for information,
• preserves privacy and prevents misuses or unauthorised changes to the information in the system,
• detects inconsistencies and deals with them appropriately
• as far as possible ensures correctness of the information
• does all this in the most cost effective way possible

NOTE:

I have not yet seen a formal list of high level goals, so this is just my understanding of what was intended, based on news reports and other documents. Since these are government political objectives, different formulations may be used in different contexts. But the sort of thing intended is clear enough.

Requirements for achieving the goals
The 'requirements' referred to in my letter (but not spelled out in it ) are the more detailed specifications of system features and behaviours that are necessary to achieve those visionary objectives.

If there are alternative disjoint sets of minimal sufficient conditions then there may be no absolutely necessary features. Instead we can talk about requirements for a particular way of achieving the goals.

Example. Suppose you can travel from A to B either by cycling or by driving a car. If you choose the former means then requirements include having access to a bicycle, being able to ride, the existence of a suitable road or cycle track, having enough stamina for the journey, getting on the bicycle, etc. If you choose the latter means, the requirements include having access to a car, having fuel in the care, having a driving licence, the existence of a suitable road, etc. So there are (at least) two distinct ways of achieving the goal, and each way involves a collection of necessary conditions, which together are sufficient (or are sufficient in a particular context). The two sets may or may not overlap.

If changes outside the system under consideration (e.g. external factors leading to building of new roads, banning of cycles on the existing road, or avaiability of a motor scooter) make a difference to which sets of conditions are necessary or which are sufficient then we can say that requirements have changed -- and one of my claims is that in large government projects of the sort under condition this can happen in unpredictable ways.

Such a change need not imply that a design that meets a selected set of requirements is out of date, if the change provides a new way of meeting the requirements that does not significantly improve on the chosen set (e.g. if the motor scooter is unreliable).

If the new changes prevent the previously chosen set from being sufficient, then any design based on the chosen requirements will be out of date, even if the high level goals are unchanged.

---

NOTES:

People who are not familiar with the terminology and the issues may find these Wikipedia entries useful:

• Requirements (a high-level overview).
• Requirements Management. (This includes management of changing requirements.)

For more detail see standard texts on Software Engineering and the references in: the Wikipedia entry on 'Software Engineering' (written by a graduate student), The Software Engineering Institute at Carnegie Mellon University, An EPSRC-funded project on 'Managing Requirements Change Through Visualisation', Ian Sommerville's book on Software engineering and his Teaching materials, this entertaining summary.

There is a vast amount of additional material and different experts may express different views on the same topic. I am not an authority on software engineering (though I have both practical experience and some theoretical knowledge).

Maintained by Aaron Sloman
School of Computer Science
The University of Birmingham