159
1 Introduction
The purpose of this part is to derive requirements for the testing of integrated navigation systems from
the generic model of integrated navigation outlined in part B. The analysis of the model has shown that
the explicit allocation of requirements to certain processes is difficult since it cannot be clearly estab
lished in which system component the data-supplying process is located. One example is the treatment
of set values and limits for executing course changing manoeuvres. These may be defined in a spe
cialised functional component “Drafting the voyage plan (1)”. Such set values and limits may how
ever also be set in the component “Monitoring and executing the voyage (2)”. Several possibilities
thereby arise:
a) Set values and limits are fixed in “Drafting the voyage plan (1)”.
I Their values are transferred to “Monitoring and executing the voyage (2)”.
II The manoeuvres are carried out with the transmitted values in “Monitoring and executing the
voyage (2)”.
III Limits set locally in “Monitoring and executing the voyage (2)” may not act in delimiting
manner on the transferred planning data.
IV If limits set in “Monitoring and executing the voyage (2)” are not modifiable, signalling occurs
in the event of conflict situations between the values from “Drafting the voyage plan (1)” and
from “Monitoring and executing the voyage (2)” before execution of the manoeuvre.
or
b) The definition of set values and limits is dispensed with during the planning phase in “Drafting the
voyage plan (1)”.
I No transfer of these values to “Monitoring and executing the voyage (2)” takes place.
II In the functional components for “Monitoring and executing the voyage (2)”, focal input options
and administration arrangements are retained for these values.
All conceivable solutions may lead to a consistent system philosophy. The formulation of requirements
permitting only a certain implementation would therefore constitute an undue restriction.
In this report, therefore, the formulation of test requirements is concentrated on the data flows, i.e. re
quirements on the exchanged data flows are essentially formulated. In this instance, the starting point in
each case is the information sinks. This means that the logic chain, which is produced from the gen
eration of primary information in the sources, further processing and derivation of information up to the
point of usage of information in information sinks, is followed back when specifying requirements. From
the functionality of the information sinks are produced requirements on the received data (e.g. with re
gard to quality or consistency); from these requirements can in turn be derived necessary properties of
information sources.
In order to make the catalogue of test requirements for creation, application and maintenance manage
able, an appropriate structuring of the requirements is absolutely necessary. In this report, the test re
quirements are first of all structured according to the particular processing procedure and the data type
considered. As a further classification criterion, a process of categorisation of the requirements on input
information was undertaken. In the following, the categories used here are explained in detail.