How do data requirements differ from other requirements?

by | Oct 11, 2016

How do data requirements differ from other requirements?

by Oct 11, 2016

Requirements fall into two distinct categories; non-functional and functional.
Non-functional requirements define how the system should behave, things like performance, scalability, capacity, availability, reliability, etc. These tend to be the ones ‘the business’ forget about and any Business Analyst worth their salt works hard to elicit.
Functional requirement defines something the system should do, for example, how the users interact with the screens and what the system does in the background. These are the ones everyone is really interested in! They get very excited about describing a new system; after-all, who wouldn’t?
The issue from a data point of view is that by the time everyone has talked about what the system will do, they generally forget about the data and reporting. Again, a decent Business Analyst will remember that functional requirements also include business rules, data and reporting. But too often, the requirements are gathered in an ‘unusable format’.
From my experience, the Business Analyst talks to the business, the business say things like ‘I want this report’ and they pull out a bundle of reports that they’ve currently got, maybe some of which they actually use.
The Business Analyst takes the reports, draws new versions, perhaps even does some denormalising to get to third normal form and creates a logical data model. A Developer picks up the reports, laughs in derision, and goes off to find a friendly business person to talk to about the reports.
Unfortunately, with all the best will in the world, the Business Analyst has wasted their time; there’s nothing there that can be built from. And worse, just defined your future state reporting to be the same as the current state! Did that with the system and processes too? No? I thought not, so why do it with the reporting?
But it’s not all doom and gloom, there is a better way. You gather the business together and ask a simple question; ‘who does what?’ Except, of course, that you’ve already done that as part of the future state processes, right? So using that as your start point, you can identify what data is used in each business process and therefore what the business should really be reporting on.
The net result; for each business process, you identify all the data to report on it. And, you end up with it all in a format that the business understands, because it’s their business process, and a Developer can use to build from.
It’s a skill any Business Analyst, or Developer, can master. We learned it from Lawrence Corr; author and world renowned authority on Business Event Analysis Modelling. If you fancy learning, we run a one-day workshop based on Lawrence’s book/course.
Come along. We have chocolate biscuits too!
Geoff blogs from a flat overlooking the intersection of Agile, Business, and Life
Want more? Read Geoff’s last blog Being Agile, Not Doing Agile or more of his blogs here
We run regular Data Requirements and Agile data warehouse training courses with an Agile business intelligence slant in both Wellington and Auckland

Start your AgileBI journey with us.

Other steps in the AgileBI Journey

And sometimes a sprint or a scrum.
[wmls name="Geoff Hunt" id="10"]
Submit a Comment

Your email address will not be published. Required fields are marked *