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.

9 Responses to The obsolete idea of requirements

  1. Pingback: uberVU - social comments

  2. Pingback: Tweets that mention Leanway » Blog Archive » The obsolete idea of requirements -- Topsy.com

  3. JulianSammy says:

    I like the way you think; this is a thoughtful, considered article. I’m not so sure about the conclusions, because I think they are based on a few shaky premises. In particular, I think there is a clear distinction between requirements and designs — or rather needs and solutions — but only because of the perspective of the stakeholder. The same statement is a need to one person, and a solution to another.

    Before I describe why I think this, let me clarify what I mean by requirements; I use the IIBA definition. It has several layers, starting with business (highest level organizational objectives), stakeholder (objectives from the solution-stakeholder perspective) and solution (‘the solution shaped hole’ is the best description I’ve seen for this level of detail). When you say “They would describe what they were doing today and what their goals were for the future,” I see a mix of current-state solution requirements (fulfilled) and future state stakeholder requirements (not fulfilled).

    In your time travel example, the business requirement is (loosely) to create a linear and random-access record of the events in the courtroom. The stakeholder requirements will vary: a court reporter will have different-but-related goals to a lawyer or a judge. Solution requirements would describe, among other things, the work that these stakeholders do and the ways that they would interact with any solution.

    This is where the ‘requirement/design’ false dichotomy rears it’s head. If the higher level requirements are not understood, it’s easy to get trapped into a solution mindset. What about 3D? Audio? Hyperlinked text? Each is an answer to the top level business requirement. Each solves the problem, but depending on the stakeholder, it may be better or worse in supporting their workflow. As new technologies and solution options are invented, they can be assessed against the business requirements. Similarly, the business requirements can be assessed against the changing solution options.

    Ultimately, needs and solutions can only be separated by a point of view (I don’t use ‘what’ and ‘how’ because in my experience it causes much confusion and little clarity). For the people in your meeting, ‘video’ is a solution to their ‘linear recording’ requirement. A designer would take the requirement and propose a solution in the form of a design. The person building the solution could insist that the ‘design’ is really a requirements document to them — and from their perspective, they’d have a strong case.

  4. smalltalk80 says:

    Thank you for an interesting reply. I am not sure if we disagree that much. It seems to be more about semantics. You say that you can have requirements as long as they are formulated the right way and then you provide a rough example: “a linear and random-access record of the events in the courtroom”. This expresses as you say a need but it is not in any meaningful way verifiable. A filing cabined stuffed with tape recordings can be said to fulfill this requirement.

    For me the interesting thing is therefore what kind of process that will work if the customer only has described these kinds of “needs” or goals. My view is that it is necessary to work incrementally and iteratively if one accepts that requirements can not be described in detail before the project starts. Detailed requirements will by definition imply a design.

  5. JulianSammy says:

    To be clear, I wasn’t trying to define a fully articulated business objective in my response. I gave one attribute (description) an objective, without any of the other attributes that would turn it into a complete business requirement. I certainly agree about the iterations; I wrote our last Quick Tip For Better Business Analysis(TM) on that very subject.

    So taken alone, a filing cabinet stuffed with tape recordings could meet this objective, as could hand-chiseled stone tablets. Clearly, further iterations of elicitation and analysis are needed to make a useful solution design more likely. During these iterations, we would discover needs that will constrain the solution in ways that would make our tapes and tables a poor fit to the need. Many of them supplementary – such as performance, reliability, access rights, durability, comprehensibility.

    I think this emphasizes the relationship between solutions and needs: coupled, but distinct. In most cases it is a one to many relationship, where one need can be fulfilled in a myriad of ways. When you have a constellation of functional requirements, the solution set is narrowed, but may remain very broad. When you add a constellation of supplementary requirements, which constrain the solution set, you rapidly reduce the viable design options. It’s still a 1:N relationship between [a set of needs] and [0..1..N sets of solution options], but in this case N is usually small. Instead of ‘detailed requirements will by definition imply a design’, we are left with ‘detailed requirements will by definition constrain design options’.

    On the premise ‘that requirements can not be described in detail before the project starts’, I don’t accept this. Business requirements and some stakeholder requirements _must_ be described to determine if there should be a project at all, and described in detail appropriate to a business case. The enterprise prioritization process that compares business cases doesn’t care about solution requirements — but need details at the conceptual level and relevant organizational stratum. (The example I used above did not have the appropriate details for a business requirement and you locked on this immediately.) Since solution requirements are not useful at this stage and could be made redundant by enterprise prioritization, they shouldn’t be described before the project is started to prevent waste at an organizational level.

  6. smalltalk80 says:

    I think we are getting to the core of where we differ. My basic point is that needs are (to a larger degree than one assumes) influenced by solutions. New needs arise when new solutions become possible. My point is not that one should start a project without any idea of needs or goals. My point is that the interdependency of needs and solutions makes it essential to work incrementally and iteratively. Start with the most pressing needs and once these are satisfied see what are the most pressing needs now. There is a definite role for business analysts in this, it is just that they have to work in a different way.
    Customers that believe that they can get a price tag for the “whole” project are doing themselves a disservice. The project will become less responsive to new possibilities. Better to work with frequent releases (http://www.leanway.no/?p=173) and thereby have the option to terminate the project when appropriate.

  7. iknovate says:

    Nice to have more on the journey. I’ve been on this path for over 2 decades.

    My path was punctuated by an article in ~1990 where the oft-quoted excuse for system failure was tested “the requirements were wrong”. They debunked the mantra. They audited the entire effort: requirements collected accurately (based on common methods), check; requirements satisfied by solution, check; system sufficient, fail.

    This was where my path took a divergent track. They brought in anthropologists to observe the conditions in which the system was being used (it was an emergency medical system, used in ERs), they added more specifications. The system was a success.

    That’s why I’m now an Experience Design Strategist who practices Design Thinking which focuses on ferreting out the possibilities.

    Requirements (as I’ve learned from the commercial building industry) are nothing more than the checklist of things agreed to be done — they’re a response to the specifications. What we’re missing is the entire blueprint/specification cycle that happens ahead of time — we’re missing the architecture phase. Requirements are a response to a design — they’re not the procuring cause of a design.

  8. Pingback: Can requirements be "solved"? | Service Oriented Architecture - SOA

  9. Pingback: Bookmarks for 10/05/2010 — MK Anderson

……….

About Niklas

Born in Sweden, grew up in New York, lives in Norway. Yes, I have problems with identity, but I do think that my background helps me see things from a different perspective.

Read more