Read an Excerpt
Chapter 8: Requirements Development
During requirement development, the software concept becomes tangible through the creation of several versions of the User Interface Prototype and the User Manual/Requirements Specification. This approach facilitates gathering the best possible set of requirements, lays a foundation for excellent architecture work, streamlines the project by eliminating the time-consuming detailed requirements document, and keeps user documentation off the critical path.
Software requirement development is the part of the project during which the needs of the customer are gathered and translated into a specification of what the system must do. Requirement development consists of three related activities:
- Gathering candidate requirements, which is accomplished by interviewing the potential users about the system they want, reviewing competitive products, building interactive prototypes, and so on.
- Specifying requirements, which is accomplished by committing the gathered requirements to tangible media, such as a written requirement document, project storyboards, an interactive User Interface Prototype, or some other medium.
- Analyzing requirements, which is accomplished by looking for commonalties and differences among requirements and breaking them down into their essential characteristics. (This is a preliminary design activity and is not discussed further in this chapter.)
I depart somewhat from common terminology in referring to these activities as requirement development. These activities are often referred to as "specification," "analysis," or "gathering." I use the word development to emphasize that requirements work is usually not as simple as writing down what key user want the software to do. Requirements are not "out there" in the users' minds waiting to be gathered in the same way that iron ore is in the ground waiting to be mined. Users' minds are fertile sources of requirements, but the project team must plant the seeds and cultivate them before the requirements can be harvested.
The most difficult part of requirements gathering is not the act of recording what the users want; it is the exploratory, developmental activity of helping users figure out what they want.
Requirements gathering and specification is an open-ended activity. You can consider the project team to be finished with requirements only when it has achieved a clear, stable understanding of what the users want
The software to do. Abbreviating requirement activities is a costly mistake. For each requirement that is incorrectly specified, you will pay 50 to 200 times as much to correct the mistake downstream--during coding-as you would pay to correct the mistake at requirements time.
OVERVIEW OF THE REQUIREMENTS DEVELOPMENT PROCESS
Here are the general steps I recommend to develop requirements:
1. Identify a set of key end users that collectively have the credibility to define the software that the team is building.
2. Interview the end users to create a set of preliminary requirements.
3. Build a simple, interactive User Interface Prototype.
4. Show the simple User Interface Prototype to the key end users and solicit their feedback. Continue revising the simple prototype, keeping it simple, showing it to the end users, and revising it again until the end users are excited about the software concept,
5. Develop a style guide that codifies the prototype's look and feel, review it, and put it under change control.
6. Fully extend the prototype until it demonstrates every functional area of the software. Make the prototype broad enough to cover the whole system, but keep it as shallow as possible. It should demonstrate the functional area, not actually implement it.
7. Treat the fully extended prototype as the baseline specification. Put it under change control. Then require the developed software to match the prototype exactly, except for changes approved through the change control process.
8. Write the detailed end-user documentation based on the prototype. This detailed end-user documentation will become the detailed software specification, and it should also be put under change control.
9. Create a separate, non-user-interface requirements document for algorithms, interactions with other hardware and software, and so on. Put that document under change control.
This set of steps is weighted heavily toward development of interactive software. If the software you are developing is an embedded system that doesn't have a user interface (such as an automobile cruise control), much of the discussion in this chapter won't apply to your project.
The following sections describe the nuances of the steps in the requirement process.
IDENTIFY A SET Of KEY END USERS
The first step in gathering requirements is to identify a set of users who will provide guidance in defining software requirements. These users must be selected in such a way that if they say that a feature is important, you can believe that it truly is important. Likewise, if they say that a feature can be left out, you should be confident that you truly can leave it out. Be sure to include both power users and average users.
If the project is in-house software, the project leaders can recruit a handful of actual users and make the users' involvement with the project part of their job descriptions. If the project is shrink-wrap software, the project leaders can still recruit a handful of actual users. In order to use their time efficiently, they'll need to make sure that interactions with the users are more planned and structured.
Soliciting user input is a critical success factor. What if you can't find any end users and the project grinds to a halt? That might be a blessing in disguise. The project is better off burning only calendar time while you try to find end users than burning both calendar time and money while you build software that users will ultimately reject.
INTERVIEW THE END USERS
An initial set of user interviews should be conducted to elicit a preliminary set of requirements. The preliminary set of requirements is used as the basis for creating the initial, simple User Interface Prototype.
If we've learned one thing in the last 20 years about software developers' abilities to design software that users like, it's that software developers by themselves aren't very good at designing software that users like. But software developers can be very good at helping users discover what they like, because users by themselves aren't very good at designing software they like either.
BUILD A SIMPLE USER INTERFACE PROTOTYPE
Keep the prototype as simple as possible. The point of this activity is to present many alternatives. to the user before you commit much effort to any particular approach. The project team should develop just enough to give the user the look and feel of the software they're going for, and nothing more. If you want to prototype a report format, for example, don't even bother to have the User Interface Prototype print the report. The developers should only mock up the report in a word processor and tell the users, "Here's what will come out when you hit the print button."
If the project is being developed in an environment that doesn't have good prototyping tools, consider prototyping on a Windows-based machine and mimicking the look and feel of the target platform. If the real development environment is an IBM mainframe, for example, use Microsoft Visual Basic to mock up screens with green characters and black backgrounds.
Prototyping activity should be performed by a small team of about one to three senior developers. These developers should be skilled at demonstrating a software's look and feel with the least amount of work possible. If developers are taking more than a couple of hours to develop the prototype for any single part of the software, they are doing too much work; they are developing the prototype with too much functional depth. Keep it as shallow as possible.
Developing the prototype in this way helps users visualize the software they are specifying, which minimizes the problem of users not knowing what they want until they see it and then changing their minds later in the project. This kind of prototyping reduces the risk of creeping requirements, which is traditionally one of the most serious risks a software project faces.
Be sure the users understand that the prototype is "just a prototype." One risk of creating a User Interface Prototype is accidentally raising unrealistic expectations about future progress on the project. . . .
