Remember the three C’s of modelling?
Clarity, Consistency, and Conciseness.
After clarity, consistency is the next pillar of modelling.
Model is only a simplified representation of something – a process, a concept, a problem, a solution.
Consistency is critical to the understanding and interpreting the model, whether your model is conventional or unconventional.
On top of that, consistency reflects the professionalism of the business analyst. Consistently inconsistent diagrams will raise a doubt in the quality of all your other work.
Let’s look at the consistency of the example below.
When you are creating a model, you must be ruthless about every little thing. Let’s call out a few problems:
- A different color jumps out of the diagram, but the legend is missing
- Actors must be singular nouns – some of them are plural
- Line width is not consistent
- Fonts are not consistent
- Shape sizes for use cases differ – aim to keep the same size
- One use case is partially outside boundaries. This is not consistent with modeling standards for a use case diagram
- Two actors are mixed in one (Customer and prospective customer). Consistency requires: One role = one actor
- Not all use cases follow the same verb + noun naming convention
- Some connectors have arrows which does not convey additional meaning
- Not all connectors pointing to an actor converge
- A comment is out of place – the diagram can be amended so that a comment is no longer required
When using one of the modelling notations such as UML, BPMN , TOGAF or ArchiMate, you will have well-documented standards to follow. Otherwise, be strict with yourself and follow your own standards to help the audience comprehend the models created for them:
- Your diagram is either high-level or detailed – all elements in the diagram must be at the consistent level of abstraction
- Use the same shapes for the same types of objects
- Use the same types of connectors for the same relationships
- Maintain the same style from model to model: consistent font styles, line colour and weight, shape fills, arrow style and size, symbols, headings and legends
- If you use colour-coding, symbols and pictograms, they must make sense and mean the same thing everywhere where they are used
- Make all object labels consistent with business terminology and the meaning of each term
- Use consistent naming conventions, such as using “verb + noun” combinations to name use cases and process steps
- Label swimlanes using business standards (e.g. User vs Client vs Customer, System vs Application, names of organizational units and roles). Ideally, these should already be catalogued and standardized in your organization, but if not, start it and follow the standards yourself. Soon your diagrams may be copied and imitated and may become the new standard
- Last but not the least, ensure consistency from one model to another. The last point cannot be shown through a simple example, but it is critical for your requirements package that all models are consistent across.
Remember that little things matter.
At a minimum, they will distract your audience from the message and will annoy them.
A more significant consequence is that your diagram may be misunderstood, misinterpreted and then the inaccurate interpretation may be replicated in other diagrams, requirements, design and ultimately in the finished product.
Diagrams and models are your tools to support the shared understanding of requirements – quality matters.
Based on the book “Business analyst: a profession and a mindset”.
For more free resources and materials, sign-up for the Why Change Newsletter. Explore the #ba_mindset in other formats: books, videos, or courses.