Tuesday, November 15, 2011

How do you create a context diagram?



You can create a context diagram by following eight straightforward steps. Because of the fluid and transformative nature of most context diagrams, a whiteboard may be the best tool to begin their creation. Once the diagram is more concrete, it may become an artifact using Visio or some other tool which supports context diagrams:

Context Diagram pitfalls to avoid
Examine your context diagram to be sure that none of the following were inadvertently included:
  • Internal actors who initiate data flows or processes (as mentioned above, these have no place in a context diagram)
  • “Black holes,” meaning many inputs into the process are depicted but no outputs.
  • Or the converse, “miracles,” many outputs come out of the process, but nothing goes in
  • “Isolated entities,” meaning external entities are shown but not linked
  • Entity-to-entity data flows with no process in between
1: Using a white board or other flexible writing tool, draw a context diagram for the highest level process at hand (known as level 0). Once this is completed, that high-level process may be further decomposed into sub-processes. If the sub-processes are fairly independent of each other, they may each be made into a separate context diagrams (not on level 0) with their own external entities and data flows. If they are sufficiently complex, each of these sub-processes may be decomposed into further sub-processes. This technique is topic for a later article on data flow diagrams.
2: For each distinct high-level process (or system, functional area being studied) draw the process that acts upon the input. Place the process in the center of your white board. Label each process with a unique numeric identifier (example: 1.0, 2.0) that will enable easy reference and revision in your requirements. Use a verb-noun structure to label the process. An example would be “Take orders.” (Ignore the inner workings of the process for this and future steps.)
3: Next, you will identify and document all external entities that are sources of data to the process you just listed. List all the external entities you can think of on the margin of the document. Use nouns to indicate who these entities are. (Examples would be vendors and consumers.) Place the first source onto the diagram, and check it off your list. (You will methodically add the other sources later.)
Context diagram: identify and document all external entities
4: Next, capture the interactions between this first listed source and the process. Determine what input(s) the source provides into the process. Draw the arrow (relationship) and label it accordingly. Determine what output the process returns to the source (if any), and draw it accordingly.
Context Diagram: capture the interactions
5: Now document the additional sources you’ve already listed and their data flows. Determine for each of the remaining sources if it does something different from the source(s) already placed on your diagram. If a source initiates the same input into the process as a previous source, group them. Otherwise, place it into its own box and draw the data flow. Repeat until all sources are off your list.
Context diagram: document the additional sources you’ve already listed and their data flows.
6: Identify and document additional external entities and don’t forget about entities which need data from the process being studied. Use nouns to indicate who these entities are (Example: “Credit Bureau”). Draw their inputs and outputs. Don’t worry if you don’t know all of these. Capture whatever you can and move on to the next step.
Context diagram: Identify and document additional external entities
7: Identify and document high-level events. For each context diagram, brainstorm these by asking, “How could a source interact with this process?” Document these events on the margin of your context diagram. High-level events will be used as inputs.
8: Capture additional requirements. If you happen to discover a requirement during the creation of a context diagram, be sure to note it either in your requirements document (be sure to note its source as the context diagram) or in a separate requirements repository designed specifically for requirements unearthed from the creation of context diagrams.
If you are not already including context diagrams as a routine part of your requirements discovery and analysis, you are missing a key tool in your arsenal for ensuring a project’s success. Context diagrams are powerful tools for eliciting facts about a process are system. However, to be effective, they must be created for their intended purpose, include their own inherent characteristics, and not be confused with use cases, flowcharts, or similar tools. When used as intended, context diagrams are a potent tool for ensuring a project’s success.

No comments:

Post a Comment