Your Requirements... Delivered
How do I drive quality during requirements definition?
In most typical SDLC projects, the requirements definition process is performed by individual business analysts conducting elicitation workshops or interviews, and completing their assigned use cases or requirements documentation. These requirements documentation may be reviewed by the lead business analyst, who then checks for any errors, before sending them to the business and IT stakeholders for approval and signoff. When these requirements documentation are signed off, the individual business analyst have largely completed their tasks, and move on to the next project.
Is this is a good model? Sure, the requirements documentation are signed off, and the work is completed. But how do you know if ALL requirements have been captured? How do you know if the work has been done to a high degree of accuracy? You are essentially relying on the business stakeholders themselves to verify and validate the quality of the requirements output. But is there a better way?
There is indeed, and a better model is to implement a quality driven approach towards requirements definition. By quality driven approach, we are talking about implementing statistical control processes and embedding any of the well known capability maturity models (eg CMMI, Six Sigma, etc) into the requirements definition activities that we do.
To implement such an approach, we first need to establish the necessary checklists, templates and guidelines to document and drive how we perform our work. In most projects, this is usually (hopefully) already done. However, we then go beyond this first stage, and capture metrics on every aspect of the requirements definition process, such as number of requirements, number of defects, and so on. We feed these metrics into a statistical tool to produce quality metrics that define how well we were producing each of the requirements artefacts. Using this tool, we are then able to measure and manage the effectiveness of each individual business analysis, as well as identify and analyse any significant trends or exceptions in the requirements definition process. We are also then able to benchmark these metrics and compare with industry best practice, and recommend systemic changes for continuos improvement.
Of course, if you had a team of expert business analysts, all of the above would be second nature to the work that they do. To get such a team, contact firstname.lastname@example.org