How the use of visual models will significantly improve the quality of your requirements

I’ve been planning my analysis approach recently and have been recommending the use of visual models to support the business analysis effort. It seemed like a good time to revisit this subject to explain what they are and why they will make a sigificant difference to the quality of your work.

 

What I mean by visual models

There are a huge range of visual models that can be used from a strategic level (Alexander Osterwalder’s Business Model Canvas) through to bringing to life the detailed interactions with a PC/laptop/mobile/smartwatch/fridge(!) (prototypes,wireframes and storyboards – I wrote about these in 2009!).

 

Here are some other examples:

  1. Use cases
    (I wrote about these here – they are both visual and textual. You can listen to a recording of Be a Better BA webinar on using use cases for reqt gathering)
  2. Rich pictures
    (simple, pictorial representation of a business situation – great for communicating the business challenge and context very quickly)
  3. Business process modeling
    Image result for simple business process model
    (this is the ‘go to’ tool for most business analysts. Listen to this recording of Be a Better BA webinar on using BPM for reqt gathering)
  4. Mind maps
    (great as an organising tool when the structure is not clear at first)

 

Why should you use visual models?

There are many reasons but, for business analysts, there is one compelling reason which I would like you to consider.

One of our biggest challenges is making sure we have all the requirements. Most of us have experienced that moment when we realise late in the project that there are requirements missing. This realisation might come from a conversation with a stakeholder about what they assumed they were going to get when the project delivers.

One of the biggest risks is unstated or tacit requirements. Your stakeholders don’t necessarily realize everything that they need – they make assumptions, forget things or simply don’t know that you didn’t realize something was required and forgot to check when reviewing your requirements.

Visual models are brilliant at bringing out tacit requirements

If you show a stakeholder a prototype (which looks a bit like the final solution) they will immediately tell you if any steps have been missed because it stands out like a sore thumb to them.

Show them a list of discrete, textual requirement statements and it is a lot harder to spot any gaps.

 

So that’s why I believe visual models are an essential part of your BA toolkit.

Of course, this is not the only reason! They are also a great asset because:

– you can communicate complex subjects with a well-crafted picture

– they allow you to look at the problem or requirements space at different levels of detail (Business Model Canvas shows you the entire organisation; a process model shows you a process which may span many different business areas over a long period of time; a prototype shows you what one person does at one point of time with a digital device)

– people learn and understand in different ways so it is helpful to communicate the requirements in different ways

 

I find that any problem I am tackling in business analysis (or business in general) is only a day or two away from being drawn up as some sort of picture. Once I have drawn the picture then everyone understands!

 

If you want to learn more about representing problems visually and find a technique that works for all situations I strongly recommend you read Dan Roam’s Back of a Napkin.

 

What are your views or experiences on using visual models? Please add some comments at the bottom so we can discuss this further.

It's only fair to share...
Share on Facebook3Digg thisBuffer this pageShare on LinkedIn10Share on Google+0Share on VKTweet about this on TwitterShare on Tumblr0Pin on Pinterest4Share on Yummly0Flattr the authorShare on Reddit0Print this pageShare on StumbleUpon0Email this to someone

About Alex Papworth

7 Responses to “How the use of visual models will significantly improve the quality of your requirements”

Read below or add a comment...

  1. Great article! I’m new to the BA role, but have always been interested in how to explain complex IT concepts as simply and elegantly as possible. I’ve spent a lot of time trying to come up with visuals that help people digest information using PowerPoint, for example. In reviewing my own, and other’s Requirement documentation, I have been frustrated at how quickly I have found myself generating pages and pages of text, which I suspect will never be actually read by anyone, although the text captures requirements, and makes it easy for our governance bodies to approve the document, letting us progress from Requirements to Design. I’ve included many of the models you reference, but still feel my BRDs require nerves of steel to actually read.

    I am going to continue working on how to increase the readability of my documents, while remaining diligent about capturing the requirements, perhaps with less slavish devotion to text and more focus on visual models.

    This is a great article on some basic design principles that are based on the psychology/physiology behind how people perceive visual information. Highly recommend you take a look, you will likely get some good general principles to improve how you display models and text most effectively. http://piktochart.com/5-psychology-studies-that-tell-us-how-people-perceive-visual-information/

    • Alex Papworth says:

      Thanks Roseanne. Can I use your quote? … BRDs require nerves of steel to actually read
      There’s an important message in there for all of us!!

      That article is incredible – some really useful messages for all of us. Thanks very much for sharing.

      Seems like this post has got a lot of you interested – I’m not the only one who values a visual model!

  2. Adrian Reed says:

    Great points, Alex. As the old saying goes “a picture speaks a thousand words” and aids communication. And as I am sure someone once said — requirements are ultimately a *communication* problem, not a documentation problem.

    One additional thin I find it is useful to draw a distinction between informal/transient diagrams and those that will be used and relied upon as requirements artefacts. For example, a rich picture or mind-map are (I find) very useful ways of communicating informally amongst a team, and a useful way to depict a business situation. But the detail they uncover is going to require further elaboration and analysis before it’s ready to be considered as a ‘requirement’. They are extremely useful as transient work products that help us get to what we need. [Of course, if we’re in an Agile environment then they might spark the *conversation* that we need to have!]

    However, process models, use case models, data models, prototypes etc… are *excellent* for concisely showing a particular ‘view’ on the requirement. It is like looking at the requirement set through a different ‘lens’, I find. And as you (quite rightly) say, we can use models to check for gaps. If we have a Use Case called “Create Customer”, then we *know* we should have some data requirements about a class (or entity) called “Customer” — if these don’t exist then we have a problem! If our prototypes show a stage that isn’t in our Use Case Narrative then we know we have a problem! Of course, the formality and structure will vary… but the key being that by creating several ‘views’ on the requirements we can validate them.

    • Alex Papworth says:

      Thanks for the contribution Adrian – some very helpful further direction on the value and some techniques that can be used.

  3. Stephanie Cracknell says:

    Great article and one of the most powerful tools that BA’s have. I use them not only to ensure there is a common understanding and to find the hidden requirements with my stakeholders, but also to ensure that the developers understand what needs to be done as well.

    I have worked with developers for years and there is always a reluctance to sift through requirements documentation, but also quite a few of the developers I have worked with do not think in that fashion, so we have come to a common ground where we review visual models to ensure the requirements are not missed and that the understanding across the team is the same.

    • Alex Papworth says:

      Great comment Stephanie. Given that the developers are tasked with actually DELIVERING the solution it is critical that they have a good appreciation of the requirements… using visual models.

      Doesn’t everybody enjoy a well-crafted visual?!

Trackbacks

  1. […] help bring to life and prompt the attendees (A1 or A0 size) (read about the value of a visual model here and visual models that specifically support use […]



Leave A Comment...

*