Since I started working with web sites and software applications there is one thing I haven’t been able to figure out. Why do people hold on to handling software requiremts in flat lists. This practice is hopelessly demanding and it often results in mediocre software or even grand project disasters. In this post I will talk about why we need to go on to better practices.
The most common way to start an IT project is to state requirements in a list. In short you can say that a requirement is a description often started with “The system should…” If you state a couple of hundreds of these in a list and paste them in a word document you get a “requirement document”. This practice is based on the idea that such a list will guarantee order and structure . This is seemingly a quite good idea. The notion is that the client should make this list as detailed as possible, the programmers should develop a solution that fill all the stated requiremtents and everybody ends up being happy.
However, the “all happy” part does very seldom emerge out of a software project. Recent studies show that only 18 percent of the clients are happy with their own IT investments. I think that the method used to handle requirement is a big suspect.
The fact is that the classic requirement list only states what the system is required to do, not why it is needed, by whom and under what circumstances. It certainly does not even describe how it is suppose to look, feel or meet the customer. This is something that is supposed to be solved later in the process. You can say that a requirement only describes the what, not the why and how.
Lets fabricate a list
Not having to deal with the solution until later is actually creating problems in it self. The requirements are gathered in the beginning of the project when very little work has been done and the requirements are created based on theory rather than experience. At this point we guess freely and hope for the best. Often times there is not any user research conducted. This result of guessing is then suppose to be the main document underlying hundreds, maybe even thousands of man hours of work. When the actual work is started the list will always show to be obsolete as soon as the team meets reality.
The list gets expensive and good ideas get refused
When the system comes close to release keeping up the documentation becomes a burden on every development team. In most projects the maintaining the requirement documents takes a lot of effort. As the project progresses good ideas about how to make a better software are expressed more and more frequently. In order to get the ideas accepted changes needs to be included in the requirement document. All changes, of course, needs approval and so on. At a certain point, a good, or even brilliant idea is refused on the sole basis of the effort needed to adjust the paperwork. After the documentation has been subject to a number of changes it becomes impossible to keep track of responsibilities and expectations and conflicts often arise.
There is a better way!
I believe strongly that new and more modern practices need to be implemented. My recommendation to any development team is to keep the requirement document as brief as possible. In the design work it is possible to take advantage of the knowledge of the end users. The tools of effect mapping in combination with conceptual sketches give you a way of detailing a solution that makes sense.