We have all experienced the problem of people not being able to ask for what they want. That’s what documenting requirements really comes down to; people explaining what they want in a way that others understand. To do this we use and teach the BEAM✲ (Business Event Analysis and Modelling) methodology from the book Agile Data Warehouse Design: Collaborative Dimensional Modeling, from Whiteboard to Star Schema by Lawrence Corr.
This blog is an update to one written by Daniel Reed. It is still a great explanation of what BEAM✲ is and how it helps to better establish data warehouse requirements.
A while back we had a problem, a disconnect between what people were asking for and what they really wanted. We needed a solution that helped developers and business users speak the same language. The solution we found was BEAM✲ (Business Event Analysis and Modelling).
The BEAM✲ methodology gets you gathering data requirements without the need for technical expertise, based completely on the business process and functions.
Good requirements need both developers and business users to speak a common language. For example, the business has a Customer who Purchases a Product. Business users understand this concept, there are two business aspects; Customer and Product and the interaction between them. Developers can also understand this.
BEAM✲ relies on 7 Ws (or really 5 Ws and a couple of Hs); who, what, when, where, why, how and how many. These simple questions will give you all of the detail you need. You take a business event like Customer Purchases Product and ask these questions to understand the aspects which are important to that process.
Who? – In this case, we have Customer and probably an Employee who are involved in this event
What? – The Product is our what, it’s the item that’s involved.
When? – The date/time this happened.
Where? – The shop this occurred in.
Why? – This can be interpreted in different ways but I’d suggest the method as to why this happened. e.g. Promotion,
How? – This could be the method, e.g. In shop or Internet
How Many? – These are the values that you know. e.g. How many products were purchased and what were their costs.
Using this methodology, you can understand the data behind every business event. It gives you a structured set of questions to document the requirements you need to model your data warehouse.
Keep exploring! Daniel.
Dan blogs about the place where data and business come together.
You can read Dan’s original blog BEAM and the Agile BA or all of Dan’s blogs here.
We run regular Defining Data Requirments courses to bridge the technical-business divide when gathering data requirements, find out more here or book your place here.