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:

Understand the domain Define the design (rough draft) Prove the design works (prototype/mock-up/stubbed out, etc) Write requirements Write code (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.

Share this: Twitter

Facebook

Like this: Like Loading... Related