Context model

I define a context model as a model that describes a system in its context. In other words, I map the system and its environment. Therefore, I reveal sources of requirements. For example, I show users, neighboring systems, and external data flows. Consequently, I help identify user interfaces and system interfaces.

First, I set the system boundary. Then, I list actors that interact with the system. Next, I add neighboring systems. Moreover, I add data and control flows between the system and its environment. In particular, I mark inputs and outputs. Specifically, I show arrows for incoming and outgoing information. Also, I document whether an arrow represents data or control. If necessary, I add a legend to explain the arrows.

I use context models early in requirements engineering. Thus, I focus on discovery, not on full requirements. Therefore, I do not use the context model as a final specification. Instead, I use it to expose where requirements come from. As a result, reviewers see which interfaces need further specification. For instance, if the system interacts with users, I note that user interfaces need detailed requirements later. Similarly, if other systems interact, I mark interfaces that require further design or modification.

Although no single modeling language dominates context models, I often choose common notations. For example, I use data flow diagrams (DFD) when I emphasize flows of information. Alternatively, I use UML use case diagrams when I focus on actors and services. Moreover, I can adapt SysML block definition diagrams for systems engineering projects. Additionally, I sometimes use tailored box-and-line diagrams for simple stakeholder communication.

I follow pragmatic rules when I create a context model. First, I include all neighboring systems that interact with the system. Second, I include all human actors who interact with the system. Third, I show interfaces clearly and consistently. Fourth, I mark existing interfaces versus interfaces that require development. Furthermore, I check the model for missing interactions and unexpected feature interactions. In particular, I look for unintended functional interactions between the system and its context.

I also use different viewpoints in context modeling. For example, I can take a data-flow-oriented view to find how data moves and where control passes. Alternatively, I can choose a use-case-oriented view to clarify goals of users and other systems. Moreover, I can model static information structures to define technical terms and data. Consequently, I support later tasks such as glossary creation and data modeling.

I write short, clear captions for each diagram. Moreover, I provide brief use case specifications when I use UML. In addition, I reference any assumptions about the environment. Because context models guide further requirements work, I update them regularly. Thus, I keep the system boundary aligned with project changes.

The additional context I received emphasizes DFDs and UML use case diagrams. Therefore, I focused on these views here. Finally, I recommend that you use a context model early, review it with stakeholders, and then refine interfaces into detailed requirements. As a result, you reduce misunderstandings and uncover important sources of requirements.