Page 139 -

122 Chapter 5 System modeling

«system»
Patient Record
System
«system»
«system»
Management Admissions
Reporting
System System
«system»
MHC-PMS
«system» «system»
HC Statistics Prescription
System System
«system»
Appointments
Figure 5.1 The context
of the MHC-PMS System

The definition of a system boundary is not a value-free judgment. Social and
organizational concerns may mean that the position of a system boundary may be
determined by non-technical factors. For example, a system boundary may be delib-
erately 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 divi-
sion 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 5.1 is a simple context model that shows the patient information system
and the other systems in its environment. From Figure 5.1, you can see that the
MHC-PMS is connected to an appointments system and a more general patient
record system with which it shares data. The system is also connected to systems for
management reporting and hospital bed allocation and a statistics system that col-
lects information for research. Finally, it makes use of a prescription system to gen-
erate prescriptions for patients’ medication.
Context models normally show that the environment includes several other auto-
mated systems. However, they do not show the types of relationships between the
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 connected directly, through a network or not connected
at all. They might be physically co-located or located in separate buildings. All of
these relations may affect the requirements and design of the system being defined
and must be taken into account.
Therefore, simple context models are used along with other models, such as
business process models. These describe human and automated processes in which
particular software systems are used.