Context models

At an early stage in the requirements elicitation and analysis process you should
decide 011 the boundaries of the system. This involves working with system stakeholders
to distinguish what is the system and what is the system's environment.
You should make these decisions early in the proce:ss to limit the system costs and
the time needed for analysis.
In some cases, the boundary between a system and its environment is relatively
clear. For example, where an automated system is replacing an existing manual or
computerised system, the environment of the new system is usually the same as the
existing system's environment. In other cases, there is more flexibility, and you decide
what constitutes the boundary between the system and its environment during the
requirements engineering process.
For example, say you are developing the specification for the library system LIBSYS.
Recall that this system is intended to deliver electronic versions of copyrighted
material to users computers. The users may then print personal copies of the material.
In developing the specification for this system, you have to decide whether
other library database systems such as library catalogues are within the system boundary.
If they are, then you may have to allow access to the system through the catalogue
user interface; if they are not, then users may be inconvenienced by having
to move from one system to another.
The definition of a system boundary is not a value-free judgement. Social and
organisational concerns may mean that the position of a system boundary may be
determined by non-technical factors. For example, a system boundary may be positioned so that the analysis process can all be carried out on one site; it may be chosen
so that a particularly difficult manager need not be consulted; it may be positioned
so that the system cost is increased, and the system development division
must therefore expand to design and implement the system.
Once some decisions on the boundaries of the system have been made, part of
the analysis activity is the definition of that context and the dependencies that a
system has on its environment. Normally, producing a simple architectural model
is the first step in this activity
Figure 8.1 is an architectural model that illustrates the structure of the information
system that includes a bank auto-teller network. High-level architectural models are
usually expressed as simple block diagrams where each sub-system is represented by
a named rectangle, and lines indicate associations between sub-systems.
From Figure 8.1, we see that each ATM is connected to an account database, a
local branch accounting system, a security system and a system to support machine
maintenance. The system is also connected to a usage database that monitors how
the network of ATMs is used and to a local branch counter system. This counter
system provides services such as backup and printing. These, therefore, need not
be included in the ATM system itself.
Architectural models describe the environment of a system. However, they do
not show the relationships between the other systems in the environment and the
system that is being specified. External systems might produce data for or consume
data from the system. They might share data with the system, or they might be con·
nected directly, through a network or not at all. They might be physically co-located
or located in separate buildings. All of these relations might affect the requirements
of the system being defined and must be taken into account.
Therefore, simple architectural models are normally supplemented by other models,
such as process models, that show the process activities supported by the system.
Data-flow models (described in the following section) may also be used to show the
data that is transferred between the system and other systems in its environment.