Page 107 -

90 Chapter 4 Requirements engineering

Property Measure

Speed Processed transactions/second
User/event response time
Screen refresh time
Size Mbytes
Number of ROM chips

Ease of use Training time
Number of help frames

Reliability Mean time to failure
Probability of unavailability
Rate of failure occurrence
Availability
Robustness Time to restart after failure
Percentage of events causing failure
Probability of data corruption on failure
Portability Percentage of target dependent statements
Number of target systems

when the system is being tested to check whether or not the system has met its non-
Figure 4.5 Metrics
for specifying functional requirements.
non-functional In practice, customers for a system often find it difficult to translate their goals
requirements into measurable requirements. For some goals, such as maintainability, there are no
metrics that can be used. In other cases, even when quantitative specification is pos-
sible, customers may not be able to relate their needs to these specifications. They
don’t understand what some number defining the required reliability (say) means in
terms of their everyday experience with computer systems. Furthermore, the cost of
objectively verifying measurable, non-functional requirements can be very high and
the customers paying for the system may not think these costs are justified.
Non-functional requirements often conflict and interact with other functional
or non-functional requirements. For example, the authentication requirement in
Figure 4.4 obviously requires a card reader to be installed with each computer
attached to the system. However, there may be another requirement that requests
mobile access to the system from doctors’ or nurses’ laptops. These are not normally
equipped with card readers so, in these circumstances, some alternative authentica-
tion method may have to be allowed.
It is difficult, in practice, to separate functional and non-functional requirements
in the requirements document. If the non-functional requirements are stated sepa-
rately from the functional requirements, the relationships between them may be hard
to understand. However, you should explicitly highlight requirements that are clearly
related to emergent system properties, such as performance or reliability. You can do
this by putting them in a separate section of the requirements document or by distin-
guishing them, in some way, from other system requirements.