Business Process Modeling: It’s All About Context | Quisitive
Business Process Modeling: It’s All About Context
September 7, 2010
Quisitive
We'll explore the uses for context diagrams when looking at Business Process Modeling.

Have you ever heard the saying, “One picture is worth a ten thousand words”? 

In the realm of requirements management, a single picture or diagram can support numerous verbose textual requirements and convey a concept to the reader in a quick glance without requiring lengthy description.

One of the most useful diagraming tools that can be employed by a business analyst in the early phases of a project is the context diagram. The International Institute of Business Analysis (IIBA) defines a context diagram as “a top-level data flow diagram. It uses a single data process to describe the scope and shows the external entities and data stores that provide data to and receive data from the system.”

Benefits of the context diagram are:

  • Easily understood by non-technical project members
  • Conveys a breadth of information in a more digestible visual format than verbose text
  • Assists with validation of written requirements by allowing the project team to compare the diagram to ensure all systems are addressed
  • Easier to create in comparison with other diagramming techniques, such as an enterprise data model
  • Can be leveraged as a tool for the creation of other, more detailed diagrams

Challenges of the context diagram are:

  • Complex environments can result in diagrams that are difficult to read
  • Non-UML process model, which may not be acceptable to strict UML development environments

It is important to note that there are different uses for context diagrams, including the system context diagram (SCD) and the operational context diagram (OCD). For the purposes of this article, I am going to focus on the system context diagram.

“The objective of a system context diagram is to focus attention on external factors and events that should be considered in developing a complete set of system requirements and constraints.” 3 Within a system context diagram, the center of the diagram is usually reserved for the core system and is the focus of the given process or development activity. External actors surround the core system and can represent other systems as well as users. If the project team is having difficulty getting started, there are a variety of tools that can be leveraged to capture the list of actors. I often use the SIPOC six sigma modeling technique as a framework for defining the actors as well as the inputs and outputs, but a simple whiteboard brainstorming activity or table of users would also suffice.

All entities should be appropriately labeled to allow readers to easily identify the actor. In the example below, the software manufacturer and product name are detailed, although this level of specificity can have its drawbacks if the system platform changes. An alternative to this approach would be to use a more generic nomenclature that provides the business name for the system (ex: Order Management System) or the user type (ex: External Customer).

Figure 1: Sample SharePoint 2010 Extranet – System Integration Context Diagram

After the actors have been added to the diagram, the project team will need to determine the nature of the relationship between the entities. The first step is to determine the directionality of the relationship by linking each pair of actors with either one-way or bi-directionally connectors.

While the diagram above does not reflect it, I would recommend placing two distinct arrows between a given pair to reflect bi-directional information or activities so that you can easily distinguish between what is flowing in each direction. Lastly, a brief description of the information or activity that is shared between two given entities should be listed along the arrow connecting them.

As with any requirement elicitation tool, once the diagram is created it should be reviewed and revised by the project team until consensus has been reached that it accurately reflects the solution. With practice, the effort necessary for the initial creation and subsequent iterations is shortened, eventually making this one of the most usable tools available to the analyst and project team.

  • Fred R. Barnard, “One Picture is Worth Ten Thousand Words”, Printers’ Ink, March 10, 1927, p. 114-115
  • A Guide to the Business Analysis Body of Knowledge (BABOK Guide), 2.0 ed., International Institute of Business Analysis, Toronto, Ontario, Canada, 2009, pg. 206
  • Alexander Kossiakoff, William N. Sweet (2003). Systems Engineering: Principles and Practices p. 413.