The obsolete idea of requirements

The writing of requirements is one of the core practices in software development. Most people hate the job but they see it as something that is fundamentally necessary. But what if the whole idea of requirements is wrong? What would software development look like without requirements?

I would not be surprised if words such as “chaos” and “naive” cross your mind. After all, requirements are an integral part of the way people usually define a project. Even if you have adopted agile development you will probably think that this is going too far. Agile is (among other things) based around the notion of change and incremental corrections of strategy based of feedback. Agile practitioners will often advocate writing less detailed requirements and accepting that these will change as the project progresses. Less detailed requirements is one thing, removing them altogether is something completely different.

The what and how

Consider the statement “The customer describes what is needed and the supplier describes how to solve this”. This is intuitively correct for most people. Intuition often allows us to make correct decisions much faster than if we have to use reasoning. The problem with intuition is that it is not always right. Something that is intuitively right can still be very wrong. At the core of the statement above is the idea that what you want can be completely separated from how this need will be satisfied. The customer uses information about the business to arrive at what is wanted and the supplier translates this into a working solution. The problem with this setup is that “what” can never be separated from “how”? Let me show you why…

Time travel

Lets suppose that you are in a meeting room. You are part of a team that is formulating requirements for a system that is to be used by criminal courts to handle trials. It is vital that this system is able to store information about each trial for future reference. But what about video? Should the system store a video recording of each trial? My guess is that after some deliberation you and the team will agree that this is either a “must have” or a “should have”. There are obvious benefits and the costs should not be that large.

Now here is the twist. When you entered the meeting room you were transported back in time forty years. You think it is 2010 but the other people in the room know it is 1970. After you get over the strange hair styles and clothing you focus on the requirements. You suggest to the others that video recordings of each trial should be included as a requirement. The mood changes. The rest of the group looks at you as if you are completely insane. There is no way they are going to agree to your idea.

This twist can of course be applied the other way. When you entered the room you were transported forty years into the future. Now, when you suggest that video could be a good idea you get equally incredulous looks, but for the opposite reason. In an age where the cost of video capture and storage is zero there is no point in discussing whether to have it.

The implications

Maybe you feel that this video example is unfair. After all, there are other requirements that are viable today and forty years either way. Maybe so, but would these requirements be valid fifty years back? Requirements are often “obvious” when we take the technology behind them for granted. We all “know” that storage of snippets of text is incredibly cheap. This has been true for a long time. But what about the things that are just now becoming easy to do? As technology progresses, customers risk missing opportunities by not including requirements that they think are too expensive. Other requirements may be outdated. How many systems being built today have the probably needless requirement of supporting fax?

Alternatives to requirements

What is the alternative? I suggest using an unlikely source for inspiration, the advertising business. In advertising, a customer typically does not write a contract for a single project. The contract is instead the foundation of an extended relation. The advertiser works with the customer, looking at what the customer does and what the customer wants to achieve in the future.  The advertiser then formulates ideas that are elaborated on together with the customer. Some of these ideas result in “projects”, others are more open ended. Over time the customer uses a number of (imperfect) measures to assess how well the advertiser is helping it achieve its goals. Most of the goals a customer cares about are not related to a particular project, they are formulated in terms of the business itself.

I wonder what the software business would look like if it worked in this way. Customers would not write requirements. They would describe what they were doing today and what their goals were for the future. If a customer was contracting an external supplier, the selection criteria would primarily be based on the track record of that supplier. Suppliers would actively work with customers in order to figure out what to do. This kind of operation would demand a different kind of supplier. One that is not focused on “the project”. One that knew that IT systems can cause problems as well as solve them. And maybe most importantly, one that quickly identified developments in IT that the customer should take advantage of.

Update: Martin Fowler has written a post that ties in nicely with this one.

Posted on 2010.02.02 at 11:50

Comments are off for this post.