Continuing with the theme of requirements capture, I’ve been writing some course material describing how the outputs produced by Roger Burlton’s Business Process Management Framework, when it is used, can be valuable inputs to requirements gathering activities. The BPMF can provide not only requirements, but users (I feel dirty using that word), priorities, and key performance indicators.

Here’s what I’ve written...

In situations where the Business Process Management Framework has been applied much of the work undertaken by the process analyst(s) can be leveraged to aid requirements gathering activities. This section briefly describes outputs of the BPMF that will assist requirements gathering.

Stakeholder Analysis

The stakeholder analysis phase of the BPMF results in a detailed study of all stakeholders in the system being studied. Referring to the stakeholder analysis will often reveal a number of functional and non-functional requirements, and can also be used to identify the names, roles and types of stakeholders without needing to cover ground that has already been covered as part of the BPMF.

"To be" Process Maps

Once a renewed business process has been defined as part of the BPMF detailed process maps are created to describe the renewed process. These process maps can be used as one tool to identify functional requirements - discussing the process maps with stakeholders is a useful method for deciding which parts of the process should be automated as part of the development project.

IGOE Diagrammes

IGOE (Input, Guide, Output, Enabler) diagrammes are created for each process analysed as part of the BPMF, and these diagrammes can be used as an information aid during requirements gathering activities. Because they provide information about what is used by a process, what is produced by a process, what guides the process or dictates portions of the process, and the systems and stakeholders that support the process they can be invaluable in directing requirements gathering activities and ensuring that key parts of the are process being developed are not forgotten.

Pain/Gain Analysis

One artefact often produced by the BPMF is a pain/gain analysis. This is usually represented as a scatter graph of processes with 'pain' (effort) depicted on the X axis and 'gain' (value) on the Y axis, and can be exceptionally useful for prioritising requirements.

When prioritising requirements using a pain/gain chart priority should be given to those processes whose renewal will provide the largest gain. Additionally, it is usually a good idea to prioritise the more complex processes over the simpler ones so that they can undergo longer periods of testing before the end of development. This will result in us prioritising the high pain-high gain processes first, followed by the low pain-high gain processes, the low pain-low gain processes, and finally the high pain-low gain processes (in reality these will often be identified as delivering too little value at too high a cost to be developed). In situations where stakeholders need to be 'won over' by seeing some quick progress made, some of the 'quick wins' (low pain-high gain activities) can be undertaken first to deliver actual business value in very little time.