Collapsing BridgeSince 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.


  1. 24 August 4:01 Gaby say's

    Generally a project starts with functional requirements; any project has to be initially defined by that. Because requirements define somehow rough estimations meaning project budget… nobody wants to pay for an ice-cream as much as a wedding cake….and how else can you define that then listing few characteristics: – firstly should be an ice-cream then should have chocolate and Neapolitan. Sounds like that’s what sponsor really wants and sound it’s easy too!
    SO the ice cream your factory should produce and as a consultant you have to provide the recipe: milk, eggs, chocolate powder etc then describe the process and then ask yourself if you could do the wafer also, and now you realize that there are some problems because you know the recipe but the technology for doing it is difficult and so on …but you have employed some dragged up confectioners and after some effort you have everything, BUT client changed his mind and he wants a nice dietetic hokey-pokey and that’s it!!!!
    Oh! That’s a big change if you already have done an ice cream which cannot be served otherwise than using a spoon and cannot stay on a stick – or at least not without some extra budget.
    Now the customer comes and wants to know how much was already consumed and what work can be reused?? Ice cream should be dietetically this time! Have you used sugar? If yes, then how much?
    Search the recipes and pray that your confectioner had forgotten to put the sugar!
    Having lists for everybody involved in the project and all the lists related with a budget approved then I’m not sure that list of requirements should be blamed for a project failure! On the contrary! List of requirements with lists of scenarios and user interface requirements has to exist and probably linked somehow in a specification…. so I suppose the way of linking these lists could be blamed because this is a real challenge…..
    I suppose you propose a better way of linking these lists!


Write your comment:

Will not be published