Page 114 -

4.3 Requirements specification 97

Insulin Pump/Control Software/SRS/3.3.2
Function Compute insulin dose: Safe sugar level.
Description Computes the dose of insulin to be delivered when the current measured sugar level is in
the safe zone between 3 and 7 units.
Inputs Current sugar reading (r2), the previous two readings (r0 and r1).
Source Current sugar reading from sensor. Other readings from memory.
Outputs CompDose—the dose in insulin to be delivered.
Destination Main control loop.
Action CompDose is zero if the sugar level is stable or falling or if the level is increasing but the
rate of increase is decreasing. If the level is increasing and the rate of increase is
increasing, then CompDose is computed by dividing the difference between the current
sugar level and the previous level by 4 and rounding the result. If the result, is rounded to
zero then CompDose is set to the minimum dose that can be delivered.
Requirements Two previous readings so that the rate of change of sugar level can be computed.
Pre-condition The insulin reservoir contains at least the maximum allowed single dose of insulin.
Post-condition r0 is replaced by r1 then r1 is replaced by r2.
Side effects None.

4.3.2 Structured specifications
Figure 4.10
A structured Structured natural language is a way of writing system requirements where the
specification
of a requirement for freedom of the requirements writer is limited and all requirements are written in a
an insulin pump standard way. This approach maintains most of the expressiveness and understand-
ability of natural language but ensures that some uniformity is imposed on the
specification. Structured language notations use templates to specify system
requirements. The specification may use programming language constructs to
show alternatives and iteration, and may highlight key elements using shading or
different fonts.
The Robertsons (Robertson and Robertson, 1999), in their book on the
VOLERE requirements engineering method, recommend that user requirements be
initially written on cards, one requirement per card. They suggest a number of
fields on each card, such as the requirements rationale, the dependencies on other
requirements, the source of the requirements, supporting materials, and so on. This
is similar to the approach used in the example of a structured specification shown
in Figure 4.10.
To use a structured approach to specifying system requirements, you define one or
more standard templates for requirements and represent these templates as structured
forms. The specification may be structured around the objects manipulated by the sys-
tem, the functions performed by the system, or the events processed by the system. An
example of a form-based specification, in this case, one that defines how to calculate the
dose of insulin to be delivered when the blood sugar is within a safe band, is shown in
Figure 4.10.