Page 103 -

86 Chapter 4 Requirements engineering

FPO Domain requirements

Domain requirements are derived from the application domain of the system rather than from the specific
needs of system users. They may be new functional requirements in their own right, constrain existing
functional requirements, or set out how particular computations must be carried out.

The problem with domain requirements is that software engineers may not understand the characteristics of
the domain in which the system operates. They often cannot tell whether or not a domain requirement has
been missed out or conflicts with other requirements.

http://www.SoftwareEngineering-9.com/Web/Requirements/DomainReq.html

requirements for the MHC-PMS system, used to maintain information about patients
receiving treatment for mental health problems:

1. A user shall be able to search the appointments lists for all clinics.
2. The system shall generate each day, for each clinic, a list of patients who are
expected to attend appointments that day.
3. Each staff member using the system shall be uniquely identified by his or her
eight-digit employee number.
These functional user requirements define specific facilities to be provided by the
system. These have been taken from the user requirements document and they show
that functional requirements may be written at different levels of detail (contrast
requirements 1 and 3).
Imprecision in the requirements specification is the cause of many software engi-
neering problems. It is natural for a system developer to interpret an ambiguous
requirement in a way that simplifies its implementation. Often, however, this is not
what the customer wants. New requirements have to be established and changes
made to the system. Of course, this delays system delivery and increases costs.
For example, the first example requirement for the MHC-PMS states that a user shall
be able to search the appointments lists for all clinics. The rationale for this requirement
is that patients with mental health problems are sometimes confused. They may have an
appointment at one clinic but actually go to a different clinic. If they have an appoint-
ment, they will be recorded as having attended, irrespective of the clinic.
The medical staff member specifying this may expect ‘search’ to mean that, given
a patient name, the system looks for that name in all appointments at all clinics.
However, this is not explicit in the requirement. System developers may interpret the
requirement in a different way and may implement a search so that the user has to
choose a clinic then carry out the search. This obviously will involve more user input
and so take longer.
In principle, the functional requirements specification of a system should be both
complete and consistent. Completeness means that all services required by the user
should be defined. Consistency means that requirements should not have contradictory