Page 113 -

96 Chapter 4 Requirements engineering

3.2 The system shall measure the blood sugar and deliver insulin, if required, every 10 minutes. (Changes in
blood sugar are relatively slow so more frequent measurement is unnecessary; less frequent measurement
could lead to unnecessarily high sugar levels.)
3.6 The system shall run a self-test routine every minute with the conditions to be tested and the associated
actions defined in Table 1. (A self-test routine can discover hardware and software problems and alert the user
to the fact the normal operation may be impossible.)

4.3.1 Natural language specification
Figure 4.9
Example requirements Natural language has been used to write requirements for software since the beginning
for the insulin pump
software system of software engineering. It is expressive, intuitive, and universal. It is also potentially
vague, ambiguous, and its meaning depends on the background of the reader. As a
result, there have been many proposals for alternative ways to write requirements.
However, none of these have been widely adopted and natural language will continue
to be the most widely used way of specifying system and software requirements.
To minimize misunderstandings when writing natural language requirements,
I recommend that you follow some simple guidelines:
1. Invent a standard format and ensure that all requirement definitions adhere to
that format. Standardizing the format makes omissions less likely and require-
ments easier to check. The format I use expresses the requirement in a single
sentence. I associate a statement of rationale with each user requirement to
explain why the requirement has been proposed. The rationale may also include
information on who proposed the requirement (the requirement source) so that
you know whom to consult if the requirement has to be changed.
2. Use language consistently to distinguish between mandatory and desirable
requirements. Mandatory requirements are requirements that the system must
support and are usually written using ‘shall’. Desirable requirements are not
essential and are written using ‘should’.
3. Use text highlighting (bold, italic, or color) to pick out key parts of the requirement.
4. Do not assume that readers understand technical software engineering language.
It is easy for words like ‘architecture’ and ‘module’ to be misunderstood. You
should, therefore, avoid the use of jargon, abbreviations, and acronyms.

5. Whenever possible, you should try to associate a rationale with each user
requirement. The rationale should explain why the requirement has been
included. It is particularly useful when requirements are changed as it may help
decide what changes would be undesirable.

Figure 4.9 illustrates how these guidelines may be used. It includes two require-
ments for the embedded software for the automated insulin pump, introduced in
Chapter 1. You can download the complete insulin pump requirements specification
from the book’s web pages.