Page 106 -

4.1 Functional and non-functional requirements 89

PRODUCT REQUIREMENT
The MHC-PMS shall be available to all clinics during normal working hours (Mon–Fri, 08.30–17.30). Downtime
within normal working hours shall not exceed five seconds in any one day.
ORGANIZATIONAL REQUIREMENT
Users of the MHC-PMS system shall authenticate themselves using their health authority identity card.
EXTERNAL REQUIREMENT
The system shall implement patient privacy provisions as set out in HStan-03-2006-priv.

Figure 4.4 shows examples of product, organizational, and external requirements
Figure 4.4 Examples
of non-functional taken from the MHC-PMS whose user requirements were introduced in Section 4.1.1.
requirements in the The product requirement is an availability requirement that defines when the system
MHC-PMS has to be available and the allowed down time each day. It says nothing about the
functionality of MHC-PMS and clearly identifies a constraint that has to be consid-
ered by the system designers.
The organizational requirement specifies how users authenticate themselves to the
system. The health authority that operates the system is moving to a standard authenti-
cation procedure for all software where, instead of users having a login name, they
swipe their identity card through a reader to identify themselves. The external require-
ment is derived from the need for the system to conform to privacy legislation. Privacy
is obviously a very important issue in healthcare systems and the requirement specifies
that the system should be developed in accordance with a national privacy standard.
A common problem with non-functional requirements is that users or customers
often propose these requirements as general goals, such as ease of use, the ability of
the system to recover from failure, or rapid user response. Goals set out good inten-
tions but cause problems for system developers as they leave scope for interpretation
and subsequent dispute once the system is delivered. For example, the following sys-
tem goal is typical of how a manager might express usability requirements:

The system should be easy to use by medical staff and should be organized in
such a way that user errors are minimized.
I have rewritten this to show how the goal could be expressed as a ‘testable’ non-
functional requirement. It is impossible to objectively verify the system goal, but in
the description below you can at least include software instrumentation to count the
errors made by users when they are testing the system.

Medical staff shall be able to use all the system functions after four hours of
training. After this training, the average number of errors made by experi-
enced users shall not exceed two per hour of system use.

Whenever possible, you should write non-functional requirements quantitatively
so that they can be objectively tested. Figure 4.5 shows metrics that you can use to
specify non-functional system properties. You can measure these characteristics