Putting the System in its Place – Context Diagrams

Alex continues discussing capturing requirements, this week looking at Context Diagrams and how they can help us understand the environment in which the system under development can operate... 

Although not strictly related to use cases, which I have previously stated as the theme of my series and upcoming posts, the development of a context diagram is an excellent first step in understanding the environment in which the system under development (SUD) will operate.

While some might consider this an unnecessary step in development I find that the development of a separate context diagram has two major benefits. Firstly it allows you to model elements which do not directly interact with you system but indirectly affect it and secondly it allows you to consider different system usages.

With regard to the former you might ask “why would I want to model things that don’t directly affect my system?” Take, as an example, the command and control (C²) for a complex weapon system (credit must be given here to my colleagues who worked with me to develop the example I am using – I’d tell you who they were but then I’d have to kill you). On a use case diagram you would represent things that directly interact with you system but at no point does your C² directly engage the target, it is the weapon itself that does that and it would be illegal UML or SysML if you modelled the interactions between the weapon and the target as it is out of scope. Not modelling this, however, does not accurately represent the system purpose as you end up with a model that explains what your system does but not why. A context diagram showing the larger scope of system usage is the perfect place to communicate this.

In my title I refer to context diagrams (plural) and have done so deliberately. A good system (or software) model considers more that the, obvious, operational context. There are many other points of view to be considered; as an example I cite the defence lines of development (for the purposes of not defence developers I have attempted to demilitarise them – the MoD definitions can be found at http://www.aof.mod.uk/aofcontent/strategic/guide/sg_dlod.htm):

•  Training - the provision of the means to practise, develop and validate, within constraints, the practical application of a capability.
• Equipment - the provision of platforms and systems needed to outfit an individual, group or organisation.
•  Personnel - the timely provision of sufficient, capable and motivated personnel to deliver outputs.
• Information - the provision of a coherent development of data, information and knowledge requirements for capabilities and all processes designed to gather and handle them.
• Concepts and Doctrine - a concept is an expression of the capabilities that are likely to be used to accomplish an activity in the future. Doctrine is an expression of the principles which guide actions and is a codification of how activity is conducted today.
• Organisation - the organisational relationships of people.
• Infrastructure - the acquisition, development, management and disposal of all fixed, permanent structures in support of the required capabilities.
• Logistics - the science of planning and carrying out the operational movement and maintenance.

Remember that your first attempt at context modelling is likely to be based on a limited understanding of the system and is therefore merely a starting point. Further analysis of the requirements will result in a refining of the system boundary and is likely to cause the context to change. As with all good development, producing a system context is an iterative activity.

Alex