People who write bad requirements should not be surprised when they get bad products-but they always are.
Writing good requirements is a difficult job. Most of the people writing requirements have no training in what to do and very few good examples to follow. Yet those in charge make the task even more difficult by providing little or no direction.
You cannot write requirements unless you have a clear understanding of the scope of the project. If management does not provide a clear definition of the scope, each individual will create his or her own definition. These definitions will be unique to each individual and will probably have no correlation to what management has in mind.
Almost everyone is aware of the problems encountered by the NASA Space Station Program. Annually the budget for this mammoth project is a major battle in Congress. More than nine billion dollars have already been spent, but the requirements are being rewritten at this time. A year ago a blue-ribbon committee was formed to redesign the Space Station to meet cost constraints mandated by the President and Congress. Midway through their study the experts stopped and said that they could not redesign the station because they did not have the requirements, and worse, did not know the purpose for the station nor whom it is to support. The response from the White House was that there was not time to stop and define the purpose and use of the station and that the definition would have to be done in parallel with the redesign effort.
The Space Station Program made a mistake that no project can afford to make—it did not define the scope of the project before the requirements were written. It even went further awry by implying that the Space Station could and would do everything for everyone. Hundreds of NASA engineers participated in writing the initial set of requirements. Thousands of requirements were written and included redundancies, inconsistencies, and unnecessary and unverifiable requirements. Anyone with project management experience would have been able to predict the outcome. When a project is begun with no boundaries, it can only diverge.
This NASA project is not alone. One does not have to look very far to find any number of projects that were out of control before they began. Have you tried to upgrade your management information systems? Have you tried to get new application software developed to support your work? Have you received requests for proposals that contained large numbers of confusing requirements?
If you look at past successes in the development of large projects, one thing stands out—each had a system architect: from “Kelly” Johnson and the Lockheed P-38 to Steven Jobs and the Apple Macintosh; from Hyman Rickover and the Navy's Nautilus nuclear submarine to Brooks, Amdahl, and Blaauw and the IBM 360 operating system.
Civil architects understand that you need to architect the project before you begin. All other large complex projects must perform this architecting process. The process begins with defining a need. Goals, objectives, constraints, operational concepts, and a high-level definition of the system are the outputs of the process. Other items that need to redefined are budgets, schedules, and management.
Management cannot simply turn people loose to define requirements for a project without defining the scope of the project. It does not matter if the project is to develop a new software application, to update a computer center, to design a new ship or aircraft, or to develop a new refinery.
Managers and engineers, who understand the need to clearly define the scope for facilities or hardware, often do not apply this understanding to projects that employ software. The scope definition is just as vital to software as it is to facilities and hardware. It may be even more critical, because those who design and build facilities and hardware often understand the use of what they are designing or constructing. People who build software usually have no concept of how the code they develop will be used.
NASA data shows that cost overruns of 100 to 200 percent are common for those projects that spend 5 percent or less of project costs on the front end. Projects that spent 5 and 10 percent up-front show maximum overruns of 120 percent. Those that have invested 10 percent or more show zero to 50 percent overruns. Failing to invest up-front is penny wise and pound foolish.
Organizational Profile
Compliance Automation Inc. (CAI) was spun off from Bruce G. Jackson & Associates, Inc. (BGJ&A) in the summer of 1993. BGJ&A had developed a tool, Document Director, to automate many of the steps in the development and management of requirements over the project life cycle. CAI is devoted to enhancement of the Document Director family of tools; consultation and training in requirements definition and management; and sales of other tools that provide support for compliance to regulations, standards and IS0 9000.
The products and services of CAI are being used to manage requirements by almost all NASA centers, the U.S. Navy, U.S. Army, NASA and DOD contractors, and the Australian Defense Department. It is also used by Southwest Research Institute to manage regulations and to perform audits in the nuclear industry.
In direct contrast, Boeing Aircraft has been very successful with their 700-series of aircraft. They have typically spent 15 percent on the front-end effort-defining the scope, developing the requirements, and doing the preliminary design. They believe that they can invest more and save more and to that end have invested 30 percent up-fronton the 777 aircraft.
Those who try to short-cut this front-end effort have this motto: We don't have time to do it right but we always have time to do it over.
If you are experiencing cost and schedule overruns, you may want to look seriously at how you are scoping the project and how much investment is being made up-front. You maybe able to significantly improve your performance by devoting a larger percentage of your budget to this effort. If you are experiencing large numbers of requirement changes during development, you need to look at how you defined the scope. It is very likely that you have a poorly defined scope and that many bad assumptions have been made in writing the requirements.
To improve your projects, you need to answer the following questions:
- What is the need we are trying to meet?
- What are our goals and objectives?
- What constraints must we consider?
- What is our operational concept?
- What are our budget and schedule?
- Who has what management authority?
You need to provide this information to each requirements author. As you assess the validity of each requirement, test it against the information above to ensure that the requirement is within the scope of the project. 
