Achieving a shared understanding of requirements is a process, not an event. Business requirements are just a format for capturing shared understanding of the problem and required solution.

So, requirements are not a secret that needs to be kept from the stakeholders until some supposed “readiness to review”. You are not writing a novel where you want to keep the plot to yourself until the mystery can be revealed. You are capturing problem analysis and root cause, process flows, conclusions drawn from the data, and models to support this understanding.

If you want quality analysis – share and validate as you go.

If you want to full cooperation from your stakeholders – do not keep them in the dark.

Share draft requirements, draft models, draft scenario matrices, draft hierarchy of themes and user stories.

Keep reviewing, updating and improving – and keep sharing.

#ba_mindset #why_change #businessanalysis

 

Continuing the topic of getting to shared understanding of business requirement, here is the next tip: use consistent terminology.

Define the terms, publish and share the #definitions in a glossary or business dictionary.

Then, promote the correct terms. As a business analyst, you are in the right position to enforce #consistency – provided you practice what you preach!

A simple term like #customer can generate many interpretations, with consequences. Misunderstandings can lead to defects, unexpected behaviour, even privacy breaches. A set of business rules may be required to support fundamental definitions.

Do I get customer treatment if I stopped buying your products two years ago?

Is each contact name of a business client a customer?

If you send me an offer every six months, but I never respond, do you count me as a customer?

Do I need to be a client to choose a preferred language of communication?

If I request a quote, then change my legal name and request another quote, am I the same customer?

What if I sold my VIP business – does the new owner get preferred treatment that I used to get, or will I keep my VIP client status?

You may need to ask a few questions to extract the right definition – consider this a good investment.

 

What you write may not be what I read. What I read may not be what I understand. And what I understand now may not be what I remember later…
When you capture result of your analysis, how do you ensure achieving a shared understanding of business requirements?
In 2019, my post about taking responsibility for shared understanding of business requirements has received by far the most responses.
The community agreed: it is critical to reach a shared understanding, and so frustrating when we struggle with it. So, starting a series of posts about different techniques to check for understanding, and make course corrections as needed. What are your tried and true tips?

*** Here is tip #1: Always create a context model and use it over and over.

What you may include (depending on the business problem and its context):

• Main categories of users (use business names)
• What will the users do with the system (name all the connectors)
• Other systems that need to interact with the solution (name all the boxes)
• External entities and parties that are key to understanding the context or participate in the value chain (name external parties)
• Customers
• Products or services created or impacted by the solution

Remember – there is no one right way to create a context model. The right one is the one that is understood, accepted and used.

Simple? You would be surprised how someone may completely misunderstand the context of the problem and the solution. Without a visual, you are going to need thousands of words with less chance of success.

Check out my book for other modelling ideas, and stay tuned for the next tip!