Page 111 -

94 Chapter 4 Requirements engineering

FPO Problems with using natural language for requirements specification

The flexibility of natural language, which is so useful for specification, often causes problems. There is scope for
writing unclear requirements, and readers (the designers) may misinterpret requirements because they have a
different background to the user. It is easy to amalgamate several requirements into a single sentence and
structuring natural language requirements can be difficult.
http://www.SoftwareEngineering-9.com/Web/Requirements/NL-problems.html

to a fine level of detail. This means that the requirements documents are likely to be
very long and should include most if not all of the chapters shown in Figure 4.7. For
long documents, it is particularly important to include a comprehensive table of con-
tents and document index so that readers can find the information that they need.

4.3 Requirements specification

Requirements specification is the process of writing down the user and system
requirements in a requirements document. Ideally, the user and system requirements
should be clear, unambiguous, easy to understand, complete, and consistent. In prac-
tice, this is difficult to achieve as stakeholders interpret the requirements in different
ways and there are often inherent conflicts and inconsistencies in the requirements.
The user requirements for a system should describe the functional and non-
functional requirements so that they are understandable by system users who don’t have
detailed technical knowledge. Ideally, they should specify only the external behavior of
the system. The requirements document should not include details of the system archi-
tecture or design. Consequently, if you are writing user requirements, you should not
use software jargon, structured notations, or formal notations. You should write user
requirements in natural language, with simple tables, forms, and intuitive diagrams.
System requirements are expanded versions of the user requirements that are used
by software engineers as the starting point for the system design. They add detail and
explain how the user requirements should be provided by the system. They may be
used as part of the contract for the implementation of the system and should there-
fore be a complete and detailed specification of the whole system.
Ideally, the system requirements should simply describe the external behavior
of the system and its operational constraints. They should not be concerned with how
the system should be designed or implemented. However, at the level of detail
required to completely specify a complex software system, it is practically impossi-
ble to exclude all design information. There are several reasons for this:

1. You may have to design an initial architecture of the system to help structure the
requirements specification. The system requirements are organized according to