Diagrams are essential to provide a clear, unambiguous picture. They can be put together in meetings, can make discussions easier than lots of text and are quicker and easier to do iterations and re-work.
It is very easy to be tempted to start writing a document. However it will save time holding off until the diagrams are agreed.
Examples of types of diagrams are:
- Brainstorming
- Process modelling
- Use case models or context diagrams
- Class diagrams
- Story boards
Below describe the diagrams listed above, gives examples, the benefits of each and when to use. This is just to give an overview to just some of the diagrams a Business Analyst should have in their arsenal.
Brainstorming diagrams
The most useful at the beginning of a project when:
- There are a lot of unknowns
- Pulling information together for the first time
- When some information is known and there is a need to establish whether there is anything else.
This starts with a cloud in the middle containing the concept being explored. If the project was about setting up a new intranet then the word intranet with a cloud around it would be in the centre of the diagram. The ideas for what the intranet would contain would spin off around it.
This makes it easy to see what ideas are being explored and further branches could stem off into more detail.
Some of the benefits are:
- Fast and quick to put together
- Lets other stakeholders easily see what is being considered and what else can be added.
Process modelling
These are useful near the beginning of the project but after the scope has been defined when:
- There is a need to understand and document the business processes from either an as is point of view or to work out the desired to be process
Benefits are in the information that can be extracted from viewing the diagrams. Some of the benefits are:
- Simple for stakeholders to understand
- Helps to identify where information is missing and where additional processes are required
- To understand problems with the current process
- The starting point for understanding the requirements
Use case models or context diagram
These are useful for understanding the scope of the system requirements before delving into the detail. They depict all of the stakeholders and external system interfaces in a simple diagram.
Some of the benefits are:
- Can be used to understand the scope of the system requirements
- Can be used to then aid planning and estimation as will give an indication of size and complexity
- Ensure that all stakeholders and system interfaces are taken into account when gathering the requirements
Class diagrams
These are useful for projects that are very data focussed. The diagram explores all of the different types of data that need to be captured and how they relate to each other.
Some of the benefits are:
- Starting point for gathering the data requirements
- Helps to agree common definitions and meanings
- Builds an understanding of the relationships between the data required that will help form the logical and physical data model
Story boards
These are useful for communicating a low fidelity prototype on paper of how the system needs to work.
Some of the benefits are:
- Cheaper and faster than a high fidelity prototype
- Powerful persuasion tool if there could be disagreements
- Easy for the stakeholders to relate to, thus will increase their understanding of how the system should work and to whether there are any additional requirements as a result of a clearer understanding
Thoughts? Questions? Please share in the comments.
