Requirements processes, maturity and requirements tools

For some time now it has been known that there are limited, if any advantages to employee software tools before other things related to your processes and procedures have been established. As Ian Alexander has observed, it's processes, then methodologies, then tools. This article explores further.

The vital process of requirements management, including control of versions and traceability, becomes increasingly difficult as more requirements are discovered and need to be managed. A way out is perhaps to use software tools designed for the purpose. However, it is generally accepted that automating a flawed process will not achieve the desired effects. So, chicken and egg? Well, how about treating the whole thing as a requirements project?

As a project of course it must have well defined terms of reference such as objectives, scope, constraints, assumptions, risks and a view as to what deliverables are expected.

First, why exactly do we think a software tool could be useful? What’s the problem with our requirements related activities? Does the problem have an adverse impact on the business? Do the options for a solution involve buying a tool, improving the process or both? How much would it cost to implement each of the options compared to the cost of letting the problem continue?
Before making this decision, it may be useful to see if Capability Maturity Model Integration (CMMI) can help.

CMMI is the Software Engineering Institute’s (SEI) Capability Maturity Model (CMM) for product development. CMMI categorises process capability in terms of five levels, from ‘initial’ (not great) to ‘optimising’ (great and getting better). It provides a measure for evaluating proceses and for effecting process improvement.

If the processes in an organisation are unpredicatable, unrepeatable, out of control, reactive, …., if the organisation’s staff would not recognise a requirement if it came up and bit them, then these processes are at the Initial stage. At this stage, a tool will probably not be purchased for the right reason, may never get used, and if it does ge9t used will probably add to the chaos. The problem is the process (or rather, lack of it). This needs to be sorted first.

CMMI level 2 is referred to as ‘managed’. Organisations at this level have a process. In fact they may have more than one, as each project may create it’s own. Perhaps each project will get its own tool too. Diversification is a very sensible investment strategy – for requirements elicitation and management it is probably not so clever.

CMMI associates the requirements mangement process with level 2 and mandates certain aspects of such a process. Actually, quite a few good things are associated with level 2; project planning, monitoring and control, quality assurance and configuration management for example. Clearly implementation of an effective (CMMI compliant) process should precede tool support for that process, but a well chosen and well implemented tool will provide valuable support for the process. In fact, for tasks such as traceability, important both for the project and for CMMI compatibility, things can be extremely difficult without adequate tool support. Supplier agreement management is also defined as a level 2 process – if an organisation is looking to select and purchase a tool, supplier management will be essential. Perhaps an approach of iteratively improving the process and and itegrating it with tool support could be applied.

It is at CMMI level 3, ‘Defined’, that we really see organisations consolidating their grip on their processses. Such organisations are in control and in a good position to use a range of tools, probably integrated, supporting well defined and executed integrated processes. Inconsistencies between project plans, work products and requirements are jumped on and eliminated as they should also have been at level 2. Standardisation and consistency is the norm. Again, organisations should start by checking their processes, perhaps against CMMI recommendations, but tools that can support consistency checking are likely be very useful at this stage.

Requirements development is associated with CMMI level 3 as are risk management, verification and validation. A popular technique associated with requirements development is the use of scenarios in one form or another, e.g. use cases. Tool support should permit the integration of the scenarios with textual descriptions of requirements.

Requirements management should be fully integrated with requirements development. As requirements development procedes iteratively, product (software) requirements can be derived from customer (user) requirements. Tools to support traceability between such levels of requirements and between requirements, architectural components, detailed designs and finished products could prove invaluable, particularly in a large project.

So, in deciding whether to apply software requirements tools to deal with requirements process problems, organisations could usefully map the current state of their processes against CMMI recommendations. They should feel confident that they could achieve level 2 or 3 compliance.

As a foot note, there are two other levels defined in CMMI.

At level 4, ‘Quantitatively Managed’, things are really looking good. Performance is being measured so organisations should be able to get a clear and quantified view of the problems and their possible solutions. This level is characterised as being process driven and predictable.

There is a fifth level, ‘Optimising’, which is characterised by ‘continual process improvement’. Trying to attain this may be like the search for the Holy Grail – always just out of reach but with good things being discovered along the way.