Any rant that is titled Business Requirements are Bullshit has my undivided attention right away. Coming from a programming and testing background into project management, business architecture and stopping for a bit to try everything in between, I carry more baggage than most people. Having said that, I do believe the traditional process of gathering requirements is dead on arrival in today's world. Also, a business analyst cannot be just that i.e. a business analyst - they have to be comfortable wearing many hats and speaking different languages.
The Monte Carlo simulating finance types and the Ajaxing programmer dudes are two different animals who can barely tolerate each other. The business analyst must broker a relationship between the two that is mutually beneficial and respectful. To that extent, the business requirement document cannot be a prescriptive artifact set in PMI or actually ITIL/ITSM stone.
It must morph to take on whatever form it must to be able to speak intelligently to everyone who provides input to it and all those who will consume it to build applications. There is need of course for record keeping and logging all the decisions made along the way that finally led to the requirements being what they are but that is a separate entity and is not a true "business requirement document".
I have used the approach I have described very successfully on several client engagements. It is also useful to take into account the level of design savvy of your development team. Chances are, with a cheap operation all they can do is code exactly as specified. In such situations it behooves the business analyst to play the system architect/designer role (at best) or corral the necessary inputs from the experts (at worst) thereby obviating the need for the development team to use their imagination. Again, I speak from experience when I say I have found this blend of business and system requirements very effective in getting a high quality output from a B or even C team of developers.
The Monte Carlo simulating finance types and the Ajaxing programmer dudes are two different animals who can barely tolerate each other. The business analyst must broker a relationship between the two that is mutually beneficial and respectful. To that extent, the business requirement document cannot be a prescriptive artifact set in PMI or actually ITIL/ITSM stone.
It must morph to take on whatever form it must to be able to speak intelligently to everyone who provides input to it and all those who will consume it to build applications. There is need of course for record keeping and logging all the decisions made along the way that finally led to the requirements being what they are but that is a separate entity and is not a true "business requirement document".
I have used the approach I have described very successfully on several client engagements. It is also useful to take into account the level of design savvy of your development team. Chances are, with a cheap operation all they can do is code exactly as specified. In such situations it behooves the business analyst to play the system architect/designer role (at best) or corral the necessary inputs from the experts (at worst) thereby obviating the need for the development team to use their imagination. Again, I speak from experience when I say I have found this blend of business and system requirements very effective in getting a high quality output from a B or even C team of developers.
Comments
Jessi