On this page
3. Context and Scope
Content
System scope and context - as the name suggests - delimits your system (i.e. your scope) from all its communication partners (neighboring systems and users, i.e. the context of your system). It thereby specifies the external interfaces.
If necessary, differentiate the business context (domain specific inputs and outputs) from the technical context (channels, protocols, hardware).
Motivation
The domain interfaces and technical interfaces to communication partners are among your system’s most critical aspects. Make sure that you completely understand them.
Form
- Various context diagrams
- Lists of communication partners and their interfaces.
Examples
See below, separated into business- and technical context.
3.1 Business context
Content
Specification of all communication partners (users, IT-systems, …) with explanations of domain specific inputs and outputs or interfaces. Optionally you can add domain specific formats or communication protocols.
Motivation
All stakeholders should understand which data are exchanged with the environment of the system.
Form
All kinds of diagrams that show the system as a black box and specify the domain interfaces to communiations partners.
Alternatively (or additionally) you can use a table. The title of the table is the name of your system, the three columns contain the name of the communication partner, the inputs, and the outputs.
Examples
<insert diagram or table>
<(optionally:) insert explanation of external domain interfaces>
3.2 Technical context
Contents
Technical interfaces (channels and transmission media) linking your system to its environment. In addition a mapping of domain specific input/output to the channels, i.e. an explanation with I/O uses which channel.
Motivation
Many stakeholders make architectural decision based on the technical interfaces between the system and its context. Especially infrastructure or hardware designers decide these technical interfaces.
Form
E.g. UML deployment diagram describing channels to neighboring systems, together with a mapping table showing the relationships between channels and input/output.
Examples
<insert diagram or table>
<(optionally:) insert explanation of technical interfaces>
<insert mapping of input/output to channels>
Practical Tips
- Tip 3-1: Explicitly demarcate your system from its environment!
- Tip 3-2: Show the context as diagram!
- Tip 3-3: Combine the context diagram with a table!
- Tip 3-4: Explicitly indicate risks in the context!
- Tip 3-5: Restrict the context to an overview, avoid too many details!
- Tip 3-6: Simplify the context by categorization!
- Tip 3-7: If many external systems are involved, aggregate (cluster) them by explicit criteria!
- Tip 3-8: Aggregate (cluster) similar neighbour systems with ports!
- Tip 3-9: Show all (all!) external interfaces!
- Tip 3-10: Differentiate business and technical context!
- Tip 3-11: In the business context, show data flows (instead of dependencies)!
- Tip 3-12: Show external influences in the context!
- Tip 3-13: Show transitive dependencies in the context!
- Tip 3-14: Pay attention to quality requirements at external interfaces!
- Tip 3-15: Show the technical context (in case hardware is central to your system)!
- Tip 3-16: Use the technical context to describe protocols or channels!
- Tip 3-17: Combine business context with technical information!
- Tip 3-18: Explain the relationship between domain interfaces and their technical realization!
- Tip 3-19: Defer technical context to the deployment view!
Related Questions
See here for questions related to context, scope and external interfaces.