I have to confess to a serious diagram bias. I am very visual and whenever I open a requirements document, a project charter or a solution blueprint, I flip through and search for visuals first. If I don’t find any diagrams or models, and faced with reading through dozen of pages of text and bullet points, I would feel prejudiced before I even start.
Why prejudiced? Here’s is what I think – feel free to disagree. If someone went to all the trouble of writing so much text about a business problem, a new desired solution or to capture analysis of an existing problem, and could not come up with a single diagram to illustrate their analysis, I can’t help but doubt the quality of their analysis.
When faced with a lot of information, how do you make sense of it? How do you structure it and check whether what you’ve captured presents a complete picture? What is a complete picture, anyway? A simple diagram with a few boxes and arrows can do wonders in helping map out the future state and find gaps in the analysis.
And once the requirements are analyzed and captured, how do you validate the results of your analysis with the stakeholders?
I’ve attended quite a few requirements walkthroughs where a business analyst took an approach of reading requirement statements one by one to a group of people. And if a project manager made a comment about the pace and “getting through the whole document”, then the analyst would just try to read faster.
I don’t know about you, but it just does not work for me. I don’t need anyone to read to me. My comprehension is so much better when I read by myself. But my understanding and the speed with which I can catch up with the message increases manifold when I can see a simple model that sets the context me, highlights the main steps in a process or main actors and use cases being discussed.
Sometimes I would ask a question in the middle of a review, and in response the analyst might get up and start drawing a simple diagram on the whiteboard. A couple of boxes, circles, arrows or lines connecting them appear on the whiteboard. Short labels are added, a marker in a different colour adds some context…. And lo and behold, the fog clears, and the picture in front of me starts to makes sense.
After I watch a model appear on the board and thank the presenter for the visual, my next comment usually is:
— This was useful for me, and may be useful to others. Why isn’t it already captured to illustrate the requirements?
If you need to draw a picture to explain your analysis – do you want to draw it again and again when asked the same question again and again? Why not draw it, capture and share going forward? You might be able to reduce the volume of your documentation, save some trees and ink, save valuable time for yourself and your stakeholders, and reach a better understanding of the requirements in the end.
Modeling is not a dark art. Basic models and diagrams are very simple and easy to understand. They allow representing complex structures and relationships in a simplified visual that highlights what is important, and hides unnecessary details.
Diagrams are not the extra work you have to do after you’ve completed analysis. Creating diagrams and models makes your analysis more focused and efficient.
So if you have finished requirements analysis and did not create a single diagram, can you be sure that your analysis is complete?
Read more about modelling best practices (three C’s of modelling): Clarity, Consistency, and Conciseness.
If you want to learn more about creating diagrams, view these video tutorials on context models, conceptual data models, and decision trees.
For more free resources and materials, sign-up for the Why Change Newsletter. Explore the #ba_mindset in other formats: books, videos, or courses.
1 comment