Data. It’s a requirement Jim, but not as we know it.
Data requirements aren’t like other functional requirements.
Non-data functional requirements can be relatively easily defined; ‘Registered users will be able to login to the system by providing a username and password’. They also fit easily into a prioritisation framework such as MoSCoW; Must, Should, Could or Won’t.
With data requirements, it’s not so simple. Sure, you can say ‘I want to know how many users are on the system at any one time’. And that’s pretty much where most requirements stop. But it tells us nothing of the types of users; admin, power, limited, etc, or how you know a user is logged on, or how we identify a user. And if you were to find the answers to all of these questions, then write them all down, traditional documentation would look horrendous!
So instead we use Business Event Analysis Modelling.
This enables us to discover the answers to all of those questions, and many more, and document the answers in a way that can be understood by the business and developers.
Business Event Analysis Modelling is described in the book ‘Agile Data Warehouse Design’ by Lawrence Corr and Jim Stagnitto. Or you can learn it and get practical hands-on experience at one of our courses or hear it from Lawrence Corr when he’s in Wellington.
Geoff blogs from a flat overlooking the intersection of Agile, Business, and Life