4.3 Verifiability

Requirements should be written so that they can be objectively verified
Requires precision in terminology
- The system should be easy to use by experienced controllers and should be organised in such a way that user errors are minimised.
- The error rate should be been quantified Experienced controllers should be able to use all the system functions after a total of two hours training. After this training, the average number of errors made by experienced users should not exceed two per day.

4.3.0.0 Requirements measures


Property	Measure


Speed	processed transactions / sec.
	Response time
	screen refresh time

Size	k bytes

Ease of use	training time
	number of help frames

Reliability	mean time to failure
	probability of unavailability
	failure rate

Robustness	time to restart after failure
	probability of data corruption after failure

Portability	% of target dependent statements
	number of target systems

4.3.0.0 Requirements separation

Functional and non-functional requirements should, in principle, be distinguished in a requirements specification
However, this is difficult as requirements may be expressed as whole system requirements rather than constraints on individual functions
It is sometimes difficult to decide if a requirement is functional or a non-functional
- E.g., requirements for safety are concerned with non- functional properties but may require functions to be added to the system