I’m Buzzing about this post…
Because as well as giving a helping hand on a special BA tool. I’m also showing you the answer to one of the most likely questions in a Business Analyst interview:
“Please can you explain a context diagram and when you would use one?”
In this post, I will tell you exactly how to create a context diagram to explain how a system operates at a very high level
Let’s get the boring bit over with first. If you’re reading around the web for info about context diagrams, then this is what you might find:
A context diagram is a specialised version of a data flow diagram
System Context Diagrams… represent all external entities that may interact with a system… Such a diagram pictures the system at the center, with no details of its interior structure, surrounded by all its interacting systems, environments and activities. The objective of the system context diagram is to focus attention on external factors and events that should be considered in developing a complete set of systems requirements and constraints.
Here’s a real life example of when a context diagram worked for me.
A lot of architects who are attempting to transition to working Agile really like context diagrams. One reason is because it gives them an early idea of how to prepare for the security level in the form of different roles in the system
An Agile project was just kicking off. And I was the BA/Product Owner.
The architects were keen for us to define the security levels of each user.
But of course, so early on in the project, I had no clue of the levels of security we needed.
SO I asked (the most important word in a BA’s toolkit) – “WHY?”
They explained – it will save development time in the future if we can at least define the number of security roles at the start. And that it would usually be done using a context diagram.
So I decided to take my dataflow diagram and turn it into a hybrid context diagram.
Ultimately, we were able to come to an agreement on the basic requirements for user roles which, for now, kept everyone happy.
And we BA’s know just how difficult it is keeping techies HAPPY
Do I need a context diagram when I’m working Agile?
Imagine, you’re beginning a project and you have a blank page AND a blank mind. That’s how all projects work.
Context diagrams might just be your saving grace. So don’t discount them, whether you’re working Waterfall or Agile.
The truth is… If you’re truly working Agile development as a Product Owner or the person in the team with Business Analyst skills. You may NOT need a Context Diagram.
And here’s why:
User stories should tell the development team who the feature is going to be used by.
For example, As a BOOK PURCHASER I want to be able to sort the books by publication date so that…
If you’re new to user stories, you can read more about them on Mike Cohn’s website. He’s a master of Agile.
But if you’re working in a company that hasn’t yet fully transitioned to Agile, chances are you will want to do one or you will be asked to do one.
But as ever – make your own mind up. There’s hundreds of tools you could use
How to draw a context diagram
This is important and if you get it wrong, EVERYONE will suffer.
There are 3 key assets to a context diagram that you MUST collect before hand.
- Tasks – things that the actors are trying to do with the system e.g. Process payment
- Actors – people or systems who use the system
- Inputs – things that are needed for the tasks to be successful e.g.
So, here’s some simple steps on HOW to do it:
- Map out your high level process – read my process mapping article on how to do this
- Select a sub-process from the process map e.g.
- hold a workshop to map out all the different users of the system
- Put the users into a list
- Select users that will most heavily use the system in question
- Map a usage of the system to the
Modern Analyst provides a simple example of a Context diagram