1.3 Requirements Gathering, Definition, and Specification

Homeowner: "Hey, I wanted that foundation laid over there!"

Requirements gathering is the activity of bringing requirements together. Requirements definition is the activity of documenting these requirements and organizing them into something understandable and meaningful. A requirements specification is the document that results from the requirements activities.

As the first activity in the lifecycle of application development, ^[1] requirements gathering sets the stage for the rest of the work. A shoddy or incomplete requirements specification causes the analysis, design, and construction to be based on a shaky foundation ”or worse , based on a foundation built in the wrong place entirely. An appropriate and complete requirements specification does nothing to ensure a successful implementation; however, it makes it possible.

^[1] Depending on the context, the first activity of application development might be business modeling. The introduction of a new computer application often requires changes to the manual business processes and the way the business is organized. If this is the case, business modeling is a required activity before requirements gathering.

Software development efforts fail much more often than they should. They fail in very high percentages. The bigger they are, the more often they seem to fall.

Capers Jones, founder of Software Productivity Research and metrics guru of the software industry, has done much interesting work on projects that fail. Table 1.3 shows that large projects fail in large numbers and small systems fail in small numbers .

Table 1.3. Probability of Project Failure

Function Points	Probability of Termination Prior to Completion
100	6%
1,000	17%
10,000	45%
100,000	80%
Reprinted with permission. Source: Jones, C., Applied Software Measurement: Assuring Productivity and Quality , Second ed. McGraw Hill, 1996.

The more complex the system, the larger the effort; the larger the effort, the more likely it is to fail. The major difference between developing systems 20 years ago and doing it today is that change is much more pervasive now. Changes to business processes and rules, user personnel, and technology make application development seem like trying to land a Frisbee on top of the head of a wild dog. The moving targets of requirements, tools, staff, and skills can make life difficult under the bright spotlight of an ongoing software project. The frequency of change means that systems must be built differently than they were before. They must be flexible enough so that changes can be made on-the-fly to requirements, design, code, testing, staff, and processes. The iterative/incremental lifecycle can address these issues because it accepts that each activity must be repeated multiple times to accommodate change even after the subsequent activities have started.

Software systems are more complex than most other engineering projects human beings undertake, but does that mean we're destined to produce overdue, poor-quality systems that don't last? We believe there are steps the industry can take to reverse this trend. If we focus on the root problems in software development and address them with high-quality processes and tools, we can make a real difference in producing more successful, on-time software that is resilient to change throughout its lifetime. For example, object orientation, when applied correctly, can address many of the issues of flexibility and extensibility in design and code for computer systems. It can also lessen the problems where maintenance of changes in one area cripples another area. Automated test tools can help address the massive test effort associated with iterative/incremental development. But how do we address requirements?