From a development-speed point of view, detailed specifications also have some disadvantages.

Wasted specification effort. You can spend time specifying in enormous detail the characteristics of the system that the users don't even care about. Analysts sometimes force users to make decisions about button sizes and placement in dialog boxes, ordering of tab fields, and other aspects of a system that both the users and the developers would be just as happy to leave to the developers' discretion.

Obsolescence. Changes mid-way through a project can quickly render a requirements document obsolete. Changes that can be made relatively simply to the design and code in its early stages require time-consuming retrofits to the requirements document. Maintaining the requirements document becomes a moral or bureaucratic task rather than one that contributes to progress. It's possible to spend time specifying in enormous detail a feature set that you'd like to be able to change later in response to changing market conditions or customer demands.

Lack of efficacy. The net effect of specifying a system in enormous detail is often insufficient to guarantee the success of the system. The system can satisfy the letter of the specification and still not be satisfactory.

Overly constrained design. Overspecifying the software can force design and implementation approaches that waste time. For example, the requirements document might require that the dialog boxes use 3-D group boxes like the one shown in Figure 14-1.

Figure 14-1. A dialog box with the ideal group box.

At implementation time, it might turn out that another kind of 3-D group box that looks like the one in Figure 14-2 is commercially available and easier to implement.

Figure 14-2. A dialog box with the quick-to-implement group box. Relaxing requirements by a small amount can make a large difference in implementation time if the change allows for better tool support.

The only differences between the two group boxes shown in Figures 14-1 and Figure 14-2 are the widths of their outlines and the shading of the boxes' interiors, which gives the first one a deeper look.

If it makes sense to leave details like this to the developer's discretion, you should do so. One of these group-box styles can be implemented virtually for free. The other might require a developer to delve into the details of writing a custom control. What's really hazardous here, from a schedule point of view, is that developers like to delve into such details, and you might not even know that you've passed a decision point at which your team decided to spend an extra week or two so that you could have 3-D style #1 instead of 3-D style #2.

Users might genuinely have an opinion at requirements time that the group box in the first example looks better than the group box in the second. But that preference is probably based on an assumption that their costs are equal. Few users would choose 3-D style #1 over 3-D style #2 if they knew it would take an extra week to develop.

In summary, some of the drive to create a traditional spec is based on practical necessity, some on a desire to avoid high downstream costs, and some on a not-always-rational desire to control every aspect of the project from the beginning. A traditional specification approach can make it seem as though the goal of software development is to build the software exactly as planned. But the goal is not to build exactly what you said you would at the beginning. It is to build the best possible software within the available time. If project conditions are right, a minimal specification can help.

A minimal specification consists of what it sounds like it should consist of: the minimal amount of information needed to meaningfully specify the product. It could consist of any of the following elements:

You can create one of these minimal specifications in any of several ways. You can use a traditional one-on-one interview approach, keeping the amount of detail to a minimum. You can hold standard Joint Application Development (JAD) sessions and capture the outcome of the JAD session in a minimal-spec format. Or you can split the difference between one-on-one interviews and full-up JAD sessions by holding on-site meetings to define the software product. Live prototypes and paper storyboards can be valuable discussion aids in such a setting.

Success in using minimal specification requires considerable flexibility in requirements. Projects like the Boeing 777 that need more rigidity are not good candidates for using a minimal specification. As part of the minimal-specification effort, you might want to present an "Article of Understanding" or something similar to your customers just to make sure they know what to expect. It could read something like this:

An article of understanding like this can help to reduce late-project haggling. Instead of the traditional bickering about whether a proposed change is a bug or a feature, you can simply ask, "Is the change in the project's best interest?"

When the minimal-specification approach is used effectively, it can produce several schedule-related benefits.

Improved morale and motivation. The greatest productivity benefit arising from the minimal-spec approach is its contribution to developer morale. With minimal specification, you in effect have the developers do much of the specification themselves. When they specify the product, it becomes their product, and they will do whatever is needed to make their product a success.

Opportunistic efficiency. With a minimal spec, developers are more free to design and implement the software in the most expeditious way possible. When every detail is spelled out in advance, they are more constrained.

Less wasted effort. Developers often expend effort trying to get users or customers to specify things they don't really care about. A minimal spec avoids that wasted effort and in general avoids the bureaucratic problems associated with traditional specification efforts.

Shorter requirements phase. A minimal spec takes less time to create than a traditional spec; you can save time during the requirements definition itself.

The minimal-spec approach is also subject to several risks.

Omission of key requirements. When you create a minimal spec, you leave out everything that you're sure the customer doesn't care about, but you risk leaving out things that the customer does care about. The minimal spec is a gamble. You bet that the time you would waste specifying unnecessary details in a traditional, detailed spec would outweigh the time you will waste by overlooking requirements and making more expensive changes later with a minimal spec. If you lose the bet, you deliver the software later than you would have if you had used traditional methods.

Unclear or impossible goals. Crystal-clear goals are essential to the success of a minimal-spec approach. The approach works because it allows developers to use ambiguities in the spec to their advantage. Goals tell them in which direction to resolve those ambiguities. Do they resolve them toward maximum usability, maximum "Wow!" factor, or minimum development time? If minimum development time is clearly the top priority, developers will resolve ambiguities to favor development speed.

If the development-speed goal is not the clear top priority, developers might favor development speed or they might favor something else. The effect will not be the shortest possible development schedule. If you have a complex set of goals, you'll be better off to create a traditional specification and spell out what you want in detail.

Gold-plating. Minimal specifications increase the risk of developer gold-plating; it is a natural consequence of the ownership that they feel from being able to specify much of the product themselves. They want their product to be as good as possible, and their internal notions of product quality can take precedence over the project's development-speed goals. At other times, gold-plating comes from developers who want to explore a technically challenging new area such as artificial intelligence or instant response time. A rapid-development project is the wrong forum in which to explore challenging new areas.

The extra work from gold-plating can be deceptive. Most developers are conscientious enough not to implement an extra feature that will take a huge amount of time. The extra time needed might seem small—a couple hours here to fix an additional bug, a couple hours there to tweak the code to be compatible with other changes. But that's the real hazard of gold-plating. It eats up time in ways that you don't realize until you look back and see how it all adds up.

Even at Microsoft, where schedule pressure is intense, almost every postmortem in every group gives rise to the complaint that major schedule problems arose when team members couldn't resist adding new features (Cusumano and Selby 1995).

You can address this risk on two levels—as the technical lead or as the manager. If you're the technical lead, you hold the reins on externally visible aspects of the product. Create a detailed user-interface prototype, and allow developers complete flexibility on their designs as long as they produce something really close to the prototype. But don't allow developers to add major functionality beyond what's expressed in the prototype. As the technical lead, you can probably make that point to the developers yourself.

If you're the manager, you're better off addressing the risk indirectly. The second way to address gold-plating is to hold regular design reviews that focus on minimal and time-effective designs. If the team as a whole has bought into the goal of minimum delivery time, it will apply pressure to any developer who is self-indulgently gold-plating a feature rather than supporting the group's objective.

Lack of support for parallel activities. One of the strengths of a traditional specification is that it provides superb support for parallel work. If the spec is done well, technical writers can create user documentation directly from the spec, and they can start writing as soon as the spec is complete. Testers can begin creating test cases at the same time.

For minimal specification to work, you have to set a milestone early in the project at which time visible changes to the product stop. At that point, user documentation and testing can begin in earnest. You need to set that point, often called "visual freeze," early enough that documentation and testing don't become critical-path activities. From that point forward, allow only the most critical changes.

Increased developer attachment to specific features. The increased ownership that developers feel with a minimal-spec approach can be a double-edged sword. You get extra motivation, but you can also encounter more resistance when you want to change one of the developer's features. Keep in mind that when product changes are suggested, they are no longer implicitly critical of only the product; they are implicitly critical of the developer's work.

Use of minimal specification for the wrong reason. Don't use a minimal specification to reduce time on the requirements-specification activity itself. If you use this practice as a lazy substitute for doing a good job of requirements specification, you'll end up with a lot of rework—designing and implementing features twice, the second time at a point in the project when it's expensive to change your mind. But if you use this practice to avoid doing work that would be wasted, you follow through with clear goals, and you give developers latitude in how they implement their features, then you can develop more efficiently.

If you use this approach, both you and your customers have to be prepared to accept a version of the product that doesn't match your vision of what the product should look like. Sometimes people start out saying they want to use this approach—and then, when the product departs from their mental image, they try to bring it into line. Worse, some customers will try to use the looseness of this specification approach to their advantage, shoehorning in extra features late in the project and interpreting every feature in the most elaborate way possible. If you allow much of that, you'll waste time by making late, costly changes; you would have done better specifying your intent up front and then designing and implementing the product efficiently the first time.

Know yourself and your customers well enough to know whether you'll accept the results of giving developers this much discretion. If you're uncomfortable with ceding such control, you'll be better off using a traditional specification approach or an incremental-delivery strategy.

There are several keys to success in using minimal specifications.

Use a minimum specification only when requirements are flexible. The success of this approach depends on the flexibility of the requirements. If you think the requirements are really less flexible than they appear, take steps to be sure that they are flexible before you commit to use a minimal specification. Flexible initial requirements have been identified by some people as a key to success with any rapid-development approach (Millington and Stapleton 1995).

Keep the spec to a minimum. With any of these approaches, you'll need to make it clear that one of the objectives is to specify only the minimum detail necessary. For items that users might or might not care about, the default option should be to leave further specification to the developers. When in doubt, leave it out!

Capture the important requirements. Although you should try not to capture requirements that the users don't care about, you must be careful to capture all of the requirements that they do care about. Doing a good minimal spec requires a special sensitivity to what users really care about.

Use flexible development approaches. Use development approaches that allow mistakes to be corrected. With a minimal-spec approach, more mistakes will occur than with a traditional-spec approach. The use of flexible development approaches is a means of hedging your bet that you can save more time than you waste.

Involve key users. Find people who understand the business need or organizational need for the software, and involve them in product specification and development. This helps to avoid the problem of omitted requirements.

Focus on graphically oriented documentation. Graphics in the form of diagrams, sample outputs, and live prototypes tend to be easier to create than written specifications and more meaningful to users. For the graphically oriented parts of your system, focus your documentation efforts on creating graphically oriented materials.