I’ve always found using pictures, diagrams and models an effective way of describing and communicating ideas. I was fortunate enough to be visiting Minsk, Belarus recently and it struck me how useful pictures and diagrams really are. Being in a foreign country, with a completely different language and even a different alphabet means that it’s difficult to find a frame of reference.
However, pictures transcend language.
Take the example below. Even if you can’t speak Russian, I’d hazard a guess you can make an educated assumption about what this sign is trying to convey:
Pictures work in any language
What does this mean for those of us that work as Business Analysts, or those of us that work on projects? Well, I think it reaffirms the need to use diagrams, models and rich-pictures in our requirement artifacts. There are so many reasons why this is the case, but two of particular relevance are listed below:
1. Well drawn diagrams add precision: Chances are not everyone on your project speaks English as their first language. Pictures and models transcend this, and help to add precision to requirements and project documentation, irrespective of the language spoken.
2. Common notations save thousands of words: Where a common understanding of a modelling notation exists, it’s possible to draw a diagram that contains a huge amount of detail on a single page. This is a way of saving hundreds (or even thousands) of words. Take the example above — if every possible scenario of “slippery floor” or “slippery surface” or “you might slip” are written down, it would take pages and pages…. but because we all have an understanding of the symbol, it can be conveyed without words at all.
So — next time you’re in a foreign country, look out for the pictures to guide you. And more importantly, remember to include diagrams, models and rich pictures in your requirements and project documents.
Спасибо (Thank you) for reading this article 🙂
I hope you have found this article interesting. Do you use models/pictures in your project documentation? What tips do you have? I’d love to hear from you — please add a comment below.
** Remember – if you enjoy reading my blog, you can sign up for free e-mail updates using the link on the right sidebar! **
Adrian, I am glad you were enjoying Belarus! It’s absolutely true what you as saying, i’d say more – when you have a workshop to review a spec – no one is reading the text – everybody reviewing that the diagrams are conveying. When I start analysis of any kind, I start with drawing a picture – no matter if I show it to other ppl or it’s just for myself.
Mike, thanks for the comment. You have raised a great point — the reality is, when a specification of 100 pages is produced, it’s *very unlikely* that stakeholders will read it from cover to cover. It is often the pictures that “jump out” and grab their attention.
I also agree that drawing a picture is a great way to start analysis.. context diagrams are like gold dust!
Thanks again for your comment.
I completely agree with you that diagrams should be used rather than words whenever they can in requirements documentation. When they are used effectively diagrams add clarity, reduce ambiguity and save writing yards of text which at best can be tedious to read and at worst impossible to understand.
But………………..
While there are many ways diagrams and images can be used to help identify and describe requirements, there are just as many contexts were diagrams just don’t work because they either get too complicated or you can’t draw the idea. The rule tables in a descision model are a good example of the kind of detail you cannot draw. We need to avoid the trap of providing a diagram at too high level of abstraction without supporting material to clarify the finer detail the diagram does not describe. And if we provide further detail, avoid the trap of resorting to free text whenever we possibly can. I find psuedo code quite useful for this and I am experimenting with the descision model.
You need the right tool for the job – sometimes diagrams are not the right tool.
It is interesting to note that the Use Case, which is a popular approach to requirements capture and documentation associated with ULM is not a template for a diagram but an approach to writing textural descriptions of interactions with a system, something which Cockburn emphaises in Writing Effective Use Cases.
I was told by someone at IBM recently that, over the last 10 years, the use of ULM in software developement as in RUP, has all but died out. This is perhaps largly due to the rise of Agile methods. I wonder if BAs will or should be using more UML in the requirements they document to increase clarity and precision and readabiltiy of the material, using a wider range of the diagram types: sequence, state, class diagrams etc.
Rob, long time no speak! Good to hear from you, and thanks for adding a comment.
You are of course completely correct — it’s important that the right tool is used for the job. Use cases are an excellent example where a textual UC description is needed to add detail.
The way I tend to handle this is to use the diagrams to “string together” the text-based requirements. Perhaps I’ll have a high level use-case model that refers to some use case descriptions. These in turn might refer to a logical navigation diagram or business process diagram. The point being that there’s consistency between the models… and there’s a “clear line of sight” through them. Also, I try to arrange requirement artefacts so that a reader can start almost *anywhere* and trace their way through. So, for example, a “data person” can start with the data requirements/data model, and see how the other requirements relate to this. It isn’t always possible of course, but that’s what I strive for.
I also agree with your point that sometimes it just isn’t possible to “draw” certain requirements. Another example would be a data dictionary (or a glossary). The data model can be a diagram (perhaps an ERD) but the dictionary, by it’s nature, is going to be text.
Thanks again for your comments. Very thought provoking!
Adrian.
Really nice example – how important visual representation is! Like it.
It think following – we should use notation clear enough/understandable for everyone, not just for BAs or people with some background. The most hardest thing – is simplicity.
Dmytro – you are so right… the hardest thing is simplicity. In fact, maybe that’s how we should define Business Analysis — “We bring order to chaos and make the complex simple” 🙂
Thanks for your comment, take care, speak soon. Adrian.