Getting Back To The Basics
Now that the Christmas roast and mince pies are well digested and we are brimming with vigour as we embark on crisply written resolutions I thought it would be a good idea to kick off the year by talking about requirements.
Yes, I know, it doesn’t sound awfully enticing or promising enough to read but I am reminded of my primary school maths teacher who had a habit of telling us that you can’t build a house and expect it to withstand the elements when its foundation is weak.
The same analogy applies here, requirements are the ‘bread and butter’ of what we do and often because it has become second nature to us we have stopped interrogating whether a requirement is actually a requirement. Alas, we even fail to recognise when a requirement is a product design requirement rather than a business requirement!
Without a doubt almost every business analysis course or presentation you attended probably began with a definition of what a business requirement is and you probably can rattle off quite a few definitions without much thought. For our purposes here, I don’t want get too hung up on definitions, although there is one that I simply love because it ‘hits the nail on its head’
Some years ago I was fortunate to have been given a copy of a book called’ Discovering Real Business Requirements for Software Project Success.’ A brilliantly written book, whenever I am faced with project challenges it’s the one book I turn to, I strongly suggest that you add this book to your ‘must read’ list)
Goldsmith ‘states that the real (business) requirements are the ‘what’s’ of the people who have some business purpose, to accomplish and provide value when delivered.’
I think this definition is about the best I have come across. The key element is that requirements are the ‘what’s’ that MUST BE DELIVERED to PROVIDE VALUE …conversely if it’s not delivered there is no value!! Another worthy note, it implies that requirements must be deliverable. A good way of distinguishing between design and business requirement is that only a ‘what’ is deliverable whereas a ‘how’ describes the means of delivery.
Business Requirements are meant to state conceptually what business results must be delivered in order to provide value. When business requirements are delivered only then do they provide value by meeting business objectives.
So I guess this is a good time to speak about our all-time favourite, system requirements. These describe the high level design of a product and ways to deliver the business requirement.
The product on the other hand only adds value when it satisfies business requirements, in other words the product will work as designed but will only provide value when it does indeed meet business requirements, and we as BA’s tend to overlook this very vital point.
The fundamental reality being; that any computer based solution we build will only add value when it satisfies the business requirement.
How often have you worked on projects where the design of the product, namely the ‘how’ became the ‘what’s’ of the business communities, whose needs the project was supposed to satisfy? When I reflect on my past projects I can quickly count up quite a few.
Now let’s talk about user stories.
So, have you found that user stories, which trace back to pieces of code making them, design or the ‘how’ requirements, seem to have replaced business requirements which are the ‘what’ or real requirements?
Whilst I am a fervent supporter of user stories it frustrates me tremendously when we lose focus of what a user story essentially is about. A user story is not and cannot ever be accepted as a business requirement!
Have you seen Developers code from requirements? (I am silently praying that you don’t answer in the affirmative!).Well, Developers code from design not requirements.
Sadly I may add, I have worked on projects where no business requirements were ever articulated or documented! It was simply deemed to be ‘out of scope’!!!!!Sounds horrendous, does it not? As BA’s how are we supposed to measure or test whether our solution will resolve whatever business problem we are meant to be addressing?
The bottom line is that requirements represent a need for a change, often the need for change is necessary in order to solve a business problem and change is meant to improve or make better whatever the current situation is. As BA’s we need to understand the context as to why the change is necessary.
The business context helps us in understanding the purposes, objectives and desired benefits for the Business.
A couple of years ago I remember having some ‘lively debates’ with a solutions architect on one of the project I worked on.
I would often argue that I needed to understand the business process and he would retort back at me ‘We don’t get paid to analyse the Clients business processes, this is not billable time, you are here to document the system requirements (albeit the use cases’)…so then tell me how can I as a BA judge reliably what needs to change or what not to change?
That’s why we have the ‘As-Is’ and ‘To-Be’ scenarios namely the current vs the future state.
Furthermore the realisation that my use case(s) was a representation of an automated business process seemed to have been missed by him altogether!
As BA’s we are constantly ‘fighting’ battles on all fronts trying to convince other stakeholders off the perils of having ill-defined business requirements or the lack of having business objectives and business context provided.
The truth of the matter is that we should be concentrating 75% of our analysis effort on the ‘what’s’ i.e. the business requirements and 25% on the ‘how’s’ which are the design requirements for the product, certainly not the other way around.
Let’s make 2013 the year of discovering real (business) requirements.
Robin F Goldsmith: Discovering REAL Business Requirements for Software Project Success, Boston, Artech House INC, 2004.