Requirements Are Like Pornography

When the U.S. Supreme Court was called upon to distinguish pornography from art, one of the justices famously opined that "I cannot define it, but I know it when I see it." The court went on to rule, in effect, that only the social mores of the community could define pornography because it meant different things to different people in different places at different times.

The conundrum of developing a legally enforceable description of what is and is not an acceptable work of art is disturbingly akin to the challenge of defining software requirements. The same words on paper can conjure completely different images depending on point of view. The reality is that a description of something, unless it is stated in a scientifically standard language such as mathematics, or an industry standard measure such as a color code, is not the same as its manifestation because the door is left open to interpretation.

For example, I once asked a developer to provide an easy, visual means of editing a recorded test script. His solution? A utility that would allow the user to directly patch the memory address where the script was stored, using the ever-so-friendly hexadecimal system. I could not contain my amazement that he found this "visual" and "easy." He likewise was surprised that I did not grasp the essential elegance: with only a few short keystrokes (and a handy hex converter), the user was in complete command of every aspect of the script without the bothersome overhead of some unwieldy user interface. What was easy for him was incomprehensible to an end-user -- and vice versa.

This struggle has led to many variations on a common theme: how to express requirements in an objective, universally understood manner. The concept of rapid prototyping was one such attempt, the idea being that users could more easily evaluate a prototype that they could see and interact with.

As development technologies advanced this was replaced by rapid development, based on the realization that the prototype could become the product. Next came extreme programming, where requirements were replaced by stories that evolve with each incremental release of software.

But in the end, it all comes back to the same basic question: Are requirements best written in code or words, or something in between? And if you write them in code, is that a good thing or bad?

Bad, Bad Thing

Writing requirements in code is bad, the logic goes, because it is so costly if you get it wrong. Development effort may be wasted, modules rewritten, and schedules missed if requirements are misunderstood or incomplete. Just as the Supreme Court decision created litigation costs for artists, pornographers and law enforcement because each work had to be evaluated on a case-by-case basis, so does expressing requirements as software incur the costs of development, review, and modification or rewrites.

And of course it is true that this is time-consuming and error-prone. But it is also true that just as much time can be wasted writing detailed requirement documents that are eventually misinterpreted or found to be incomplete as can be wasted writing code. Furthermore, it may actually take more words to describe it than code to implement it. Trying to explain behavior may be more difficult than demonstrating it.

It's a Good Thing

Writing requirements as code is good, it can be argued, because of the inherent objectivity. Like the beleaguered Supreme Court, users have a hard time describing what they want, but they know it when they see it. Code can be experienced, its behavior objectively observed; words must be interpreted, their intent subjectively discerned.

Another argument in favor of coded requirements is that once the code accurately represents the requirements, the software is finished. But once written requirements are finalized, the code remains to be written and the potential for interpretation issues still exists. In other words, you still won't know until you see it.

The Good, the Bad and the Beautiful

Perhaps the answer to the long-standing requirements struggle is that there is no single answer -- it's a mix. There are many types of requirements: architectural, design, user interface, business rules, and performance requirements, and each describe different attributes of the system. Some of these attributes are easily described in words; for example, "the system must accommodate 100 concurrent users and maintain response time of less than 2 seconds" is an objective description of a performance requirement.

Other requirements, like the user interface, are more easily described in code. Modern development tools allow programmers to drag and drop components to a UI faster than they could be described in words, and the user can more easily evaluate usability by seeing and interacting with the UI than with a written document. For business rules, new tools are evolving that allow them to be expressed in a formal syntax that can be executed, which makes them easy to objectively evaluate for acceptance.

Hopefully requirements tools of the future will adapt the form to the function and we can finally make requirements a reality.

Linda Hayes is CEO of WorkSoft, Inc. She was one of the founders of AutoTester. She can be reached at linda@worksoft.com.