The requirements capture process can cripple an IT project if it is not done correctly Recognise any of these? "If we go vanilla we can implement it sooner," or, "We can deliver anything you want (at a price)," or worse still, "These entity diagrams are your processes." These phrases, and many similar examples, can be found...
in the murky world of "requirements capture". Even with the best programme management capabilities, if your documented requirements are wrong, no amount of Prince2 project management is going to deliver a system that meets the users' needs. In my work I watch supplier/ client interaction at close range, and have seen how the requirements capture process can cripple a project if performed in- correctly. The first thing that becomes apparent is the gap between the supplier's technology-driven view of the problem and the client's organisational/commercial perspective. The very language used gives it away. One speaks in IT jargon, the other does not. One side does n0t understand IT functionality and capability and the other has no idea how operations really work. This lack of common understanding enables the pursuit of all sorts of risky approaches to requirements capture. Take the "going pure vanilla" approach, often used with the best intentions of speeding up the roll-out. Here we end up with a system that goes in quickly but then comes to a grinding halt because users dismiss it as useless. Take another example, where the IT department writes the user spec, usually as part of the draft functional spec for the tender process. This is invariably rushed, poorly written and results in a bid that completely misses the real business need but is a fine match with systems architecture. Managing user requirements But let us not be too hard on suppliers or IT departments. Given half a chance, users will want the earth and change their minds constantly. Managing this varying complexity, along with balancing costs and timescales can test anyone's staying power. So, getting the user community, at all levels, to quickly detail what they want in a concise, unambiguous format is no trivial task. But before moving onto what approaches to requirements capture may work we have to do some sanity checking. Buyers of IT systems must understand that you cannot computerise a mess and expect things to get better. If you have an operationally broken business, sticking in a CRM solution is not going to fix it. IT-driven change is inherently risky unless the broken or inefficient processes are redeveloped first. After spending £12m on CRM, one client found that it took 200 keystrokes to load an order and a visit to five separate screens, whereas on the previous system the same task could be done in 90 keystrokes on two screens. Order load speed goes down, data entry errors go up. What is needed is a structured approach that can bridge the technology and business divide. Getting users to imagine what the system could look like, and document the requirements as though it already exists, is a powerful starting point. This "vision" of the new way of working can be later refined in light of technological capability. Building the requirements downwards from a high-level operational strategy, through more detailed business processes, and finally down to procedures and work instructions, ensures that there is a logical, traceable link between your strategic aims and what key you press to get things done. So, who can sit in both camps to develop the lingua franca that enables client and suppliers to communicate effectively? Is it the supplier? For me, the jury is still out. But why take the risk? There are too many examples of where it has gone wildly awry.
Why use requirements capture?
Understanding the user's real requirements, rather than their requirements as perceived by the IT developer, is critical to the development of successful information systems.
To achieve a high level of user-friendliness, it is essential that the statement of user requirements is developed in the correct way. If this is done, the software that is produced will meet the users' needs. If it is not, the software is unlikely to meet the user's requirements, even if it conforms with the specification and has few defects.
There are three levels of requirements:
- Business requirements. High-level objectives of the project which are recorded in the vision and scope document
- User requirements. Task and facilities available to the end-user recorded in the "use cases"
- Functional requirements. Detailed listing out of each behaviour that the software must exhibit. This along with the quality attributes and other non-functional requirements is documented in the software requirements specification.
Francis Rice is business development director at Enigma Business Consultants