The Context Viewpoint
Many architecture descriptions focus on views that model the system’s internal structures, data elements, interactions, and operation. Architects tend to assume that the “outward-facing” information — the system’s runtime context, its scope and requirements, and so forth – is clearly and unambiguously defined elsewhere. However, you often need to include a definition of the system’s context as part of your architectural description, for several reasons:
- the system context is implicit rather than being explicitly defined as part of project initiation or requirements capture
- the system context is only loosely defined during requirements analysis
- you need to refer to elements of the system context elsewhere in your architectural description.
The Context view of a system defines the relationships, dependencies, and interactions between the system and its environment—the people, systems, and external entities with which it interacts. It defines what the system does and does not do; where the boundaries are between it and the outside world; and how the system interacts with other systems, organizations, and people across these boundaries.
|Definition||Describes the relationships, dependencies, and interactions between the system and its environment (the people, systems, and external entities with which it interacts)|
|Stakeholders||All stakeholders, but especially acquirers, users, and developers|