-.

General principles of requirements engineering is a distinction between requi

rements definitions
and requirements specifications.
-. Many of the problems of software engineering are difficulties with the req
uirements specification.

7.1 Requirements definition

-. A software requirements definition is an abstract description of the s

ervices which the system
should provide and the constraints under which the system must operate.
-. System requirements may be either functional or non-functional require
ments.
-. There are three types of major problem with requirements definitions w
ritten in natural language :
(1) Lack of clarity
(2) Requirements confusion
(3) Requirements amalgamation
-. Some organizations try to produce a single specification to act as bot
h a requirements definition
and a requirements specification. When a requirements definition is comb
ined with a specification there
is often confusion between concepts and details.
-. The first sentence in this requirement mixes up three different kinds
of requirements :
(1) A conceptual, functional requirement states that the editing system
should procide a grid.
(2) A non-functional requirement giving detailed information about the g
rid units.
(3) A non-functional user interface requirement which defines how that g
rid is switched on and
off by the user.
-. The most useful approach to writing a readable requirements definition
is to invent a standard format
and to ensure that all requirements definitions adhere to that format.

7.2 Requirements specification

-. Requirements specifications add further information to the requirement

s definition.
-. Natural language is often used to write requirements specifications. H
owever, a natural language specification
is not a particularly good basis for either a design or a contract betwe
en customer and system developer.
-. There are various alternatives to the use of natural language which ad
d structure to the specification and which
should reduce ambiguity. These are :
(1) Structured natural language
(2) Design description language
(3) Requirements specification language
(4) Graphical notations
(5) Mathematical specifications
-. When requirements specifications are written, it is important that rel
ated requirements should be cross-referenced.
-. There are some simple methods of traceability that may be applied to a
ny requirements definition of specification:
(1) All requirements should be assigned a unique number.
(2) Requirements should explicitly identify related requirements by refe
rring to their number.
(3) Each requirement document should contain a cross-reference matrix sh
owing related requirements.

7.2.1 Structured language specifications

-. Structured natural language is a restricted form of natural language
for requirements specification.
-. Special-purpose forms were designed to describe the input, output and
functions of an aircraft software
system.
-. A forms-based approach to requirements specification relies on defini
ng one or more standard forms or
templates to express the requirements.
-. If a standard form is used for specificationn, the following informat

ion should be included :

(1) The description of the function or entity being specified.
(2) A description of its inputs and where these come from.
(3) A description of its outputs and where these go to.
(4) An indication of what other entities are used.
(5) If a functional approach is used, a pre-condition setting ou
t what must be true before the
function is called and a post-condition specifying that is tr
ue after the function is called.
(6) A description of the side-effects(if any) of the operation.
-. The form-based approach to specification may be used with formal math
ematical specifications.

7.2.2 Requirements specification using a PDL

-. To counter the ingerent ambiguities in natural langyage specification
, it is possible to describe requirements
operationally using a program description language or PDL.
-. Using a PDL may be the best way to provide this information in two si
tuations :
(1) When an operation is specified as a sequence of simpler acti
ons and the order of execution
is important.
(2) When hardware and software interfaces have to be specified.
-. There are disadvantages to this approach to requirements specificatio
n:
(1) The language used to write the specification may not be suff
iciently expressive to describe
application domain concepts in an understandable way.
(2) The specification will be seen as an abstract design rather
than a model to help the user
understand the system.
-. In principle, PDLs may be based on amy programming language.
-. An effective way to use this approach to specification is to combine
it with the use of structured natural language.
-. Three types of interface which may have to be defined:

(1) Procedural interfaces

(2) Data structures
(3) Representations of data
-. At a more detailed level, it may be necessary to specify the precise
representation of elements in the interface.

7.3 Non-functional requirements

-. Non-functional requirements define system properties and constraints.
-. Non-functional requirements are sometimes more critical than functiona
l requirements.
-. Customers impose these process requirements for two reasons:
(1) System quality
(2) System maintainability
-. Classified Non-functional requirements depending on how they have been
dericed :
+. Product requirements
+. Organizational requirements
+. External requiremetns
-. A very common error in requirements specifications is to confuse non-f
unctional requirements with general goals of
the system customer.