17 September 2007

Requirements Management case study; beyond formal processes

There is a lot of talk about how to document requirements properly. Let me tell you what I did the last time I delivered a set of requirements. It’s not a classic case of formal requirements management, but it got the job done.

The context
It was for an international corporation and the development was being done by vendors, not an in-house IT team. The organisation was highly bureaucratic and had detailed software development and project management processes. The project has a budget of more than $1 million and it involved a major BPR effort supported by a new website for external agents who do work for the business. The process was being wholly re-engineered and was not n incremental process improvement; there were no new actors in the process.

The method
My smal team of analysts worked closely with the manager responsible for the business process and got to understand his business intimately. After several weeks I drafted a one page hybrid use-case/data flow diagram, dummied up an example web page in excel (yep - excel), and provided a list of dot-point non-functional specs. It was all bundled into one six page PowerPoint document. I flew to the vendor site with a copy of the corporate branding guidelines and work-shopped the requirements with their lead developer. They agreed to provide a prototype from my specs over the next week. During the course of the week the developer lead rang me at the end of each day and we discussed the work done so far.

The outcome
70-80% of the functional requirements made it to the prototype. The non-functional specs could be reliably estimated. We had a tool to begin the stakeholder buy-in exercise. At this point I left the project and another team took over the next stage of the project. My method was validated and the project ended up being a solid success, coming in substantially cheaper and faster than a business as usual approach would have provided.

I provide this example to demonstrate that there are many ways to address requirements management. Essentially requirements management is about communicating needs to developers, and making sure they are the right needs with the client/sponsor and key stakeholders. At the end of the day quality requirements management comes from high intensity communication.

That’s the first and last job of the business analyst.


  1. Anonymous6:29 pm

    I think your final sentence really should be a mantra for anyone dealing with requirements:

    "At the end of the day quality requirements management comes from high intensity communication"

    It's too easy to become focused on producing a comprehensive requirements document that's hundreds of pages long while for getting that the aim is to communicate the requirements to another party.

  2. Thanks John. I agree totally. And its prbably a mantra for all collaborative work in any field.