Requirements Lessons from Building Software for Others

At first, I just hated computers. ("What? I stayed here all night and I have to submit this batch job again because I left out a 'space'? Are you crazy? Let me in that room. . . .") My first "real computer" was a minicomputer, which, although incredibly limited in performance by today's standards, was unique in that I could touch it, program it, and make it do what I wanted. It was mine .

My early research applied the computer to analyze physiological signals from the human body, primarily EKGs, and the dedicated computer was a wonderful tool for this job. Out of this experience, I began to apply my programming skills and experience with real-time software systems to the needs of the industry.

Eventually, I incorporated RELA, Inc., and began a long, and perhaps unusually difficult, career as CEO of a contract software development business. My coauthor, Don Widrig, joined me at RELA in the early years as Vice President of Research and Development. He had the primary accountability for the success of the many systems that we developed.

Over the years, the company grew rapidly . Today, the company employs many hundreds of people and has diversified beyond providing just software to providing complete medical devices and systems that encompass software, as well as mechanical, electronic, optical, and fluidics-handling subsystems. However, at the heart of each and every machine, including the latest DNA fingerprinting in-vitro diagnostic clinical laboratory, lies one or more computers, reliably and routinely delivering their steady heartbeats through the rhythm of a real-time multitasking system.

Initially, we would program anything for anybody, from antenna-positioning software to such games as laser tag, automated guided vehicles for amusement parks, educational products, welding robots, and automated machine controls. We even developed a large distributed computer system that automatically detected and counted the presence of commercials on television. (Our motto then was "We make computers to watch commercials so you don't have to!") Perhaps the only thing the software we developed had in common was that we developed it for others ”we were not domain experts in the field, and we couldn't cover our own paychecks if we had to. We were completely dependent on the customer's satisfaction as the final determination of outcome . In many ways, such an environment was very conducive to effective requirements management. Here's why:

• We knew little about the domain, so we were dependent on customers for the requirements. There was little temptation to make them up; we had to ask, and we had to learn how to ask the right questions the right way, at the right time.

• Our customers often knew little about computers, so they were dependent on us to translate their needs and wishes into technical requirements.

• The fact that money changed hands created a rigorous interface between the developer and the customer.

• Quality was easy to measure: We either got paid or we didn't.

Big Question 1: "Exactly what is this software supposed to do?"

It was in this environment that we discovered the first of two fundamental questions that face software developers on each and every project. This question dominated our behavior for many years and remains today as perhaps the toughest question to answer in any software project. And the Big Question is:

So, exactly what is this software supposed to do?

The principles and techniques presented in Team Skill 1, Analyzing the Problem; Team Skill 2, Understanding User and Stakeholder Needs; and Team Skill 3, Defining the System, were developed over more than a decade as a means to discover the answer to this question. Each of these techniques has proved its worth and has demonstrated its effectiveness in many real-world projects. It was also during this period that I first became aware of the work of Donald Gause and Jerry Weinberg, especially their book Exploring Requirements: Quality Before Design (1989). Because their book heavily influenced our work, we have borrowed a few key concepts from it for this book, both because the concepts work and because we thought it only fair that you share the Gause and Weinberg experience.