Page 101 -

84 Chapter 4 Requirements engineering

User Requirement Definition

1. The MHC-PMS shall generate monthly management reports showing
the cost of drugs prescribed by each clinic during that month.

System Requirements Specification
1.1 On the last working day of each month, a summary of the drugs
prescribed, their cost, and the prescribing clinics shall be generated.
1.2 The system shall automatically generate the report for printing after
17.30 on the last working day of the month.
1.3 A report shall be created for each clinic and shall list the individual
drug names, the total number of prescriptions, the number of doses
prescribed, and the total cost of the prescribed drugs.
1.4 If drugs are available in different dose units (e.g., 10 mg, 20 mg)
separate reports shall be created for each dose unit.
1.5 Access to all cost reports shall be restricted to authorized users listed
Figure 4.1 User and on a management access control list.
system requirements

You need to write requirements at different levels of detail because different read-
ers use them in different ways. Figure 4.2 shows possible readers of the user and sys-
tem requirements. The readers of the user requirements are not usually concerned
with how the system will be implemented and may be managers who are not inter-
ested in the detailed facilities of the system. The readers of the system requirements
need to know more precisely what the system will do because they are concerned
with how it will support the business processes or because they are involved in the
system implementation.
In this chapter, I present a ‘traditional’ view of requirements rather than require-
ments in agile processes. For most large systems, it is still the case that there is a
clearly identifiable requirements engineering phase before the implementation of
the system begins. The outcome is a requirements document, which may be part of the
system development contract. Of course, there are usually subsequent changes to
the requirements and user requirements may be expanded into more detailed system
requirements. However, the agile approach of concurrently eliciting the require-
ments as the system is developed is rarely used for large systems development.

4.1 Functional and non-functional requirements

Software system requirements are often classified as functional requirements or non-
functional requirements:

1. Functional requirements These are statements of services the system should
provide, how the system should react to particular inputs, and how the system