Structured language specifications

Structured natural language is a way of writing system requirements where the freedom
of the requirements writer is limited and all requirements are written in a standard
way. The advantage of this approach is that it maintains most of the
expressiveness and understandability of natural language but ensures that some degree
of unifonnity is imposed on the specification. Structured language notations limit
the tenninology that can be used and use templates to specify system requirements.
They may incorporate control constructs derived from programming languages and
graphical highlighting to partition the specification.
An early project that used structured natura1language for specifying system requirements
is described by Heninger (Heninger, 1980). Special-purpose forms were designed
to describe the input. output and functions of an aircraft software system. The system
requirements were specified using these forms.
To use a fonn-based approach to specifying system requirements, you must define
one or more standard fonns or templates to express the requirements. The specification
may be structured around the objects manipulated by the system, the functions
perfonned by the system or the events processed by the system. An example
of such a fonn-based specification is shown in Figure 6.12. I have taken this example
from the insulin pump system that was introduced in Chapter 3.
The insulin pump bases its computations of the user's insulin requirement on the
rate of change of blood sugar levels. These rates of change computed using the current
and previous readings. You can download a complete version of the specification
for the insulin pump from the book's web pages.
When a standard fonn is used for specifying functional requirements, the following
infonnation should be included:
I. Description of the function or entity being specified
2. Description of its inputs and where these come from3. Description of its outputs and where these go to
4. Indication of what other entities are used (the requires part)
5. Description of the action to be taken
6. If a functionaJi approach is used, a pre-condition setting out what must be true
before the function is called and a post-condition specifying what is true after
the function is called
7. Description of the side effects (if any) of the operation.
Using formatted specifications removes some of the problems of natural language
specification. Variability in the specification is reduced and requirements are
organised more effectively. However, it is difficult to write requirements in an unambiguous
way, particularly when complex computations are required. You can see
this in the description shown in Figure 6.12, where it isn't made clear what happens
if the pre-condition is not satisfied.
To address this problem, you can add extra information to natural language requirements
using tables or graphical models of the system. These can show how computations
proceed, how the system state changes, how users interact with the
system and how sequences of actions are performed.
Tables are particularly useful when there are a number of possible alternative
situations and you need to describe the actions to be taken for each of these. Figure
6.13 is a revised description of the computation of the insulin dose.
Graphical models are most useful when you nef:d to show how state changes
(see Chapter 8) or where you need to describe a sequence of actions. Figure 6.14
illustrates the sequence of actions when a IIser wishes to withdraw cash from an
automated teller machine (ATM).
You should read a sequence diagram from top to bottom to see the order of the
actions that take place. In Figure 6.14, there are thre:e basic sub-sequences:
I. Validate card The user s card is validated by checking the card number and
user sPIN.
2. Handle request The user s request is handled by the system. For a withdrawal,
the database must be queried to check the user's balance and to debit the amount
withdrawn. Notice the exception here if the requestor does not have enough
money in their account.
3. Compl,qte transaction The user s card is Ireturned and, when it is removed, the
cash and receipt are delivered.