The Requirements Myth

Years ago I first heard this myth and it lodged itself deeply in my mind. It seems so true that it’s taken years to shed myself of it. The myth: Never start designing and certainly NEVER start writing code until the requirements are defined.

It implied that requirements make a foundation of solid rock on which to build grand edifices of code. Unfortunately, none of it is true. As a foundation requirements are no more stable than the shifting sands of North Carolina’s Outter Banks. Initially sketchy and ill defined with work requirements can grow into something akin to Mr. Obama’s political platform—all inclusive and contradictory. In school we were warned about some of this and armed with a technique to defuse it—the use case. Supposedly, if you define all user interactions the full scope of a system can be defined before one line of code is written. The problem: real users don’t have a clue about computer systems. Imagining interaction with a computer system requires a technical understanding of the evolving abilities and limitations of computer systems. Domain experts rarely have that knowledge.*

Domain experts don’t talk computer. They talk in domain. Domain problems, processes, challenges, and trajectory of change (in the domain field). Successful systems start in the domain. That is the ground-zero of a software system.

Building on ground zero produces a curious side effect. By nature domain understanding does not lead to specification. Understanding suggests design. A very important part of design is limits. When design is allowed to bubble up from understanding it’s easy to put the limit of the design into places that are logical for the domain. In contrast to design, requirement definition is limitless. The requirements gathering process typically goes on until someone says “I think we’ve got enough now”. That arbitrary stopping point becomes a design limit and hobbles further system development.**

The solution is to write the requirements after the design is created so that the scope will be defined. If a design is new it’s often a good idea to write a little code to prove the design will work before investing in the requirements. I haven’t done a scientific survey to prove this, but my guess is that the design of almost every great new invention was created long before any sort of specification/requirement document was written—if there ever was one. It also seems that great designers are almost always people who have a deep understanding of the domain as well as being excellent technologists.

Now that I’ve trashed on requirements some of you are probably getting fired up in their defense. At least I hope so because a requirements documents is one of the most useful tools in the software engineer’s tool belt. One of the most important things Software Engineers can do is communicate proposed designs/changes with key stakeholders before heavy investments in development are made.

Requirements give stakeholders the chance to review changes and catch misunderstandings. It also gives them a chance to plan for their future. Changes in software systems are disruptive and giving stakeholders the tools to coordinate change is important. I don’t know of any tool that does this better than a requirements document.

In Summary:

  1. Understand the domain

  2. Define the design (rough draft)

  3. Prove the design works (prototype/mock-up/stubbed out, etc)

  4. Write requirements

  5. Write code

  6. (Iterate 1-5 as needed)

The Myth reversed: Never write requirements until you’ve designed your system and written some code.


 *I have found use cases to be somewhat useful for explaining existing systems to technical/managerial people, but it’s too clunky and abstract for much more.

**If the requirements first method is used for maintenance patches the problem of arbitrary design limits compounds.

Advertisements

8 Responses to “The Requirements Myth”

  1. Very Funny Says:

    You should retitle this posting “Not knowing anything, not learning anything, closing your mind”

    Everything is so contextual and just because you failed elicitation or didn’t even try any planning doesn’t mean they don’t work for everyone. Even worse don’t pretend your little process works for everyone and everything, that was your fatal flaw and assumption to begin with.

    Engineering is meant to involve critical rational thought. Not just blind dogma which you seem to espouse.

  2. Very Funny Says:

    You should retitle this posting “Not knowing anything, not learning anything, closing your mind”

    Everything is so contextual and just because you failed elicitation or didn’t even try any planning doesn’t mean they don’t work for everyone. Even worse don’t pretend your little process works for everyone and everything, that was your fatal flaw and assumption to begin with.

    Engineering is meant to involve critical rational thought. Not just blind dogma which you seem to espouse.

  3. Michael Buchanan Says:

    I totally agree. I’ve almost abandoned everything I came to believe was true. I found some of the promises of OO to never be realized(reuse especially) I do things completely different now. I create the app immediately off of a data model, then design and scope as I go… This is my site.. http://www.overnightapps.com

  4. Twylite Says:

    Great article! We are a small team that handles numerous short (2-8 month) projects, and one problem that we have struggled with is how to estimate a fixed cost up front. In our industry quoting is done at risk, the customer’s stated problem or envisaged solution is sketchy at best, and they expect a quick (and binding) answer to the question “how much will (this half-page description) cost and how long will it take?”.

    We have arrived at a lightweight process quite similar to what you describe, in that we use our domain understanding to do a high level design based on the customer’s description, from which we can make time & cost estimates and write up a draft specification. In effect we say to the customer “You asked for X, and we will give you Y (similar to X) in N weeks at cost C”.

    From this we gain two significant advantages:
    1. We have a good idea of how we will approach the project before we commit to costs & times. You cannot do this if you start from a requirements spec.
    2. The specification was written by us and subject to our interpretation – we offer to implement the system that we have described in vague terms, as opposed to the one that the customer described in vague terms. This results in much better control of project scope, changes, and contractual disagreements.

    Taking all of this into account I would practice your process as something more like:

    1. Understand the domain
    2. Understand the customer’s problem and needs
    3. Draft of the high level design (major functionality, user interface sequences for the functionality, software components required to support the functionality, infrastructure components)
    4. Identify risky areas (functionality, approaches or technology your team hasn’t handled before) and make prototypes to reduce the risk.
    5. Estimate times & costs. Don’t forget documentation, testing, customer acceptance demonstrations, etc.
    6. Write a specification based on the high level design. This is probably best called a “functional” or “behavioral” specification.
    7. Get the signed contract (don’t underestimate the importance of this step!)
    8. Low level design, code, test, document.
    9. Iterate as needed

    Regards,
    Twylite

  5. Arjan`s World » LINKBLOG for November 4, 2008 Says:

    […] The Requirements Myth – Jeff Staddon ‘ The myth: Never start designing and certainly NEVER start writing code until the requirements are defined ‘ We still hear this, don’t you? […]

  6. Vijay Patel Says:

    Your post resonates with my own experiences. IMHO, the biggest obstacles to the domain discovery phase are:

    – Developers prefer writing code, than understanding the domain
    – Business users/stakeholders want to see *results*
    – Creating and delivering flexible prototypes takes too long

    We have a product that attempts to tear down these obstacles, and:

    – Allows developers to rapidly create prototypes using code
    – Allows business users/domain experts to interact with the prototypes
    – Allows all parties to understand and share the domain

    The product is called “TrueView”, and I believe it tackles a very important part of the software design process.
    You can learn more about it at http://www.evolving-software.co.uk.

    Cheers,
    Vijay

  7. /++//++//++//++//++//++/ » Blog Archive Says:

    […] (Iterate 1-5 as needed)” jeffspost.wordpress.com… […]

  8. mythorfact Says:

    Oh where did you learn all of this, Obie One? Espousing drivel that a 1 year IT intern should know? PHDs in the field of programming has driven all kinds of how in the world do programmers communicate with non-programmers since the 1970s. Nothing new in this post except maybe You are learning Your job. So glad you have had a revelation. Looks are more important than the darn system working right????????Yeah focus on that and you will go far…Not!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


%d bloggers like this: