System requirements

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 maybe used as part of the contract for the implementation of the system and should
therefore be a complete and consistent specification of the whole system.
Ideally, the system requirements should simply describe the external behaviour
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 impossible, in practice,
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 organised according
to the different sub-systems that make up the system. As I discuss in Chapter
7 and Chapter 18, this architectural definition is essential if you want to reuse
software components when implementing the system.
2. In most cases, systems must interoperate with other existing systems. These constrain
the design, and these constraints impose requirements on the new system.
3. The use of a specific architecture to satisfy non-functional requirements (such
as N-version programming to achieve reliability, discussed in Chapter 20) may
be necessary. An external regulator who needs to certify that the system is safe
may specify that an architectural design that has already been certified be used.
Natural language is often used to write system requirements specifications as
well as user requirements. However, because system requirements are more
detailed than user requirements, natural language specifications can be confusing
and hard to understand:
1. Natural language understanding relies on the specification readers and writers
using the same words for the same concept. This leads to misunderstandings
because of the ambiguity of natural language. Jackson (Jackson, 1995) gives
an excellent example of this when he discusses signs displayed by an escalator.
These said 'Shoes must be worn' and 'Dogs must be carried'. I leave it to
you to work out the conflicting interpretations of these phrases.
2. A natural language requirements specification is overflexible. You can say the
same thing in completely different ways. It is up to the reader to find out when
requirements are the same and when they are distinct.
3. There is no easy way to modularise natural language requirements. It may be
difficult to fmd all related requirements. To discover the consequence of a change,
you may have to look at every requirement rather than at just a group of related
requirements.
Because of these problems, requirements specifications written in natural language
are prone to misunderstandings. These are often not discovered until later
phases of the software process and may then be very expensive to resolve.

--------------------------------------------------------------------------
Structured natural
language
This approach depends on defining standard forms or
templates to I!XpreSS the requirements specification.

---------------------------------------------------------------------------
Design description
languages
This approach uses a language like a programming language
but with mOrE! abstract feature!; to specify the requirements by
defining an operational model of the system. This approach is
not now widely used although it can be useful for interface
specifications.

---------------------------------------------------------------------------
Graphical notations
A graphical language, supplemented by text annotations is
used to definE! the functional requirements for the system. An
early example of such a graphical language was SADT (Ross,
1977) (SChoman and Ross, 19n). Now, use-case descriptions
(Jacobsen, et 411., 1993) and seqDence diagrams are commonly
used (Stevens and Pooley, 1999).
---------------------------------------------------------------------------
Mathematical
specifications
These are notations based on mathematical concepts such as
finite-state machines or sets. These unambiguous specifications
reduce the arguments between customer and contractor about
system functionality. However, most customers don't
understand fOlmal specifications and are reluctant to accept it
as a system cClntract.
---------------------------------------------------------------------------

--------------------------------------------------------------------------