Requirements Capture – the Cinderella of Computing

“Garbage in, garbage out” is an often-quoted aphorism about computer systems but, all too often, it is forgotten that it is just as true about the design and implementation of systems. No matter how good the project management and suppliers, if the original specification is no good, the resulting system will be no good.

Requirements capture, as it has come to be known, i.e. the process of collecting and presenting the information necessary to define the system, is a highly skilled activity yet it is frequently delegated to junior, inexperienced staff on the grounds that it is just fact gathering. Taking that approach seriously undermines the quality and usefulness of the requirements before it has even begun. Why? Because fact gathering is not enough. Indeed, a purely technical approach is not enough.

The traditional skills of O & M (organisation and methods) have become lost in a welter of buzz word compliant methodologies. (Methodology is, of course, the study of methods, not a method in itself.) Common mistakes are to believe too much in methods, rather that treating them just as the tool they are, and, more seriously, to believe that they are a substitute for understanding the problem. If the requirement is not clearly understood, no amount of fact gathering, slavish method following or smart presentation can make up for it. Understanding is the key skill of requirements capture. Understanding the requirement allows problems to be identified. It may be (sometimes!) overly rude to say that users, and especially procurement staff, don’t understand what they want. But, even if the situation is not that bad, there are nearly always problems that have been overlooked or, worse, deliberately concealed to please management or secure funding or approval.

The outside perspective is always valuable – as recognised by the approach of peer review, widespread in local government. ‘Extreme Programming’ is a currently fashionable technique (I hesitate to enshrine it as a method just yet) heavily reliant on continuous and very critical peer review. The whole open source movement is a less extreme form of the same idea. However, this is for implementation, a purely technical process, not for the original requirement definition the programmers, extreme or otherwise, are working to solve. As any of you who have worked on large IS projects will know, once the concept, whether of a system or a particular programme, is no longer under the control and mind of one person, the problems start to multiply. The difficulties of clear communication of the concepts and needs start blurring the original clarity of vision. It is no accident that many of the best programmes were originally written by one person, not a team.

What is true of programming is even more true for requirements capture. Once the overall concept of the requirement gets outside one person’s head, the problems begin. A need may be defined/prepared by a committee, a good requirements definition cannot. The committee can, of course, review and comment, but the RD document should be the work of a single mind.

It may be starting to seem that requirement capture is a job to be avoided at all costs, such are the demands and the responsibility yet, for those brave enough, and with the necessary skills, it can be a very rewarding job. The skills needed for the task can be summarised as: communication, understanding, curiosity, scepticism and experience, experience, experience.

Communication does not mean just the ability to communicate your results well, very important though that is. Above all, it means the ability to communicate well with the people involved in the requirements capture process – management, project teams, IT/IS departments, users (if possible) and suppliers (if necessary). Unless you have the ‘people skills’ that enable the building of a rapport and mutual respect, you will achieve only a fraction of what you need to.

Understanding is vital – not only of the need, as originally presented, but also of any policies and strategies that may affect the project (which may themselves be flawed or inadequate and, crucially, of what the people tell you taking into account their perspectives, problems, lack of understanding or poor communication skills. All too often, the people you speak to will know only ‘their bit’ of the system in detail or have only a high-level overview of the whole system. You have to understand it all, perhaps not down to the last detail, but to some extent (knowing how to do vs. knowing how things are done).

Curiosity is what takes requirements capture beyond fact gathering towards understanding. If your commonest question isn’t ‘why?’, you’re not trying hard enough. Much of the time ‘why?’ produces useless or irrelevant information but it can also uncover gems of information that can enable, change or thwart the whole project. ‘Why?’ is the question, asked of others or only of yourself, that will help you to uncover a project based on shaky foundations or, even, down right deception.

That is where the scepticism comes in. You need to see beyond the bold, over-optimistic claims and unrealistic goals and try to work out what’s really going on. It’s said that there are no IS projects, only business change projects with an IS component. You do need to be cynical about the changes the project proposal claims to be bringing about. Hidden agendas abound. Your political skills may become a top requirement.

Lastly, there is no substitute for experience. No matter how good your degree or how brilliant your mind, or how many case studies or post-implementation reviews you have read, if you haven’t actually worked on the shop floor of projects that have flown, limped or crashed and burned, you will not spot the potential problems as well.