14--Feature-Set Chapter Control There are three general kinds of feature-set control: 1. Early-project control of defining a feature set that is consistent with your project's schedule and budget objectives. 2. Mid-project control of controlling creeping requirements. 3. Late-project control of trimming features to meet a schedule or cost goal. 14.1 Early Project: Feature-Set Reduction Feature-set control in the early part of a project consists primarily of not putting unnecessary features into the product in the first place. The first commandment of rapid development is to "narrow your scope". There are three ways to do this: 1. Minimal specification 2. Requirements scrubbing 3. Versioned development 1. Minimal Specification A. Advantages of traditional specification approaches The attempt to create a detailed requirements specification catches more of the requirements than a less detailed one would, avoids the time and cost problems associated with adding requirements late in the project. It provides a thorough basis for planning and tracking the project. And it provides developers with a secure foundation upon which to base their design and code. B. Problems with traditional specification approaches a) 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 of dialog boxes...and other aspects of a system that both the users and the developers would be just as happy to leave to the developers' discretion. b) Obsolescence. Changes mid-way through a project can quickly render a requirements document obsolete. c) 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. d) Overly constrained design. Over-specifying the software can force design and implementation approaches that waste them. If it makes sense to leave details to the developer's discretion, you should do so. Relaxing requirements by a small amount can make a large difference in implementation time if the change allows for better tool support. 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. C. Creating a minimal specification. Minimal specification consists of the minimal amount of information needed to meaningfully specify the product. It could consist of any of the following elements: a) A short paper spec. This is a text description of the software you want to build, which should be 10 pages or less. b) Point of departure spec. A one-shot approximation spec which is not intended to be maintained after it is initially written. Its primary purpose is to align the development group, customers, and end-users on a common vision of the product. c) User manual as spec. Write a user manual and require the software to conform to the manual. d) User-interface prototype. Can either serve as a de facto spec or it can supplement a written spec. e) Paper storyboards. Sometimes it's quicker and easier to draw reports, screens, and other user interface elements on flip charts and to design the product that way. f) Vision statements. Describe what to put in and what to leave out of the product. The natural tendency is to try to make a product be all things to all people, and a good vision statement draws the line by stating what a product is not. g) Product theme. For example, a theme might be to make the product flashy. 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 by holding on-site meetings to define the software product--live prototypes and paper storyboards can be valuable discussion aids in such meetings. Success in using minimal specification requires considerable flexibility in requirements. D. Benefits of minimal specifications. a) Improved morale and motivation. Developers do much of the specification themselves, so it becomes their product and they will do whatever is needed to make their product a success. b) Opportunistic efficiency. Developers are freer to design and implement the software in the most expeditious way possible. c) Less wasted effort. Minimal specification avoids wasted effort associated with traditional specification efforts. d) Shorter requirement phase. E. Risks of minimal specification. a) Omission of key requirement. b) 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 specs to their advantage. Goals tell them in which direction to resolve those ambiguities. c) Gold-plating. d) 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. For minimal specification to work, you have to set a milestone early in the project at which time visible changes to the product stop. You need to set that point often called "visual freeze," early enough that documentation and testing don't become critical-path activities. e) Increased developer attachment to specific features. f) 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. F. Keys to success in using minimal specifications. a) Use a minimal specification only when requirements are flexible. b) Keep the spec to a minimum. c) Capture the important requirements. You must be careful to capture all the requirements the users care about, but you should try not to capture requirements the that users don't care about. d) Use flexible development approaches. Use development approaches that allow mistakes to be corrected. e) Involve key users. f) 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. 2. Requirements Scrubbing After you create a product specification, go over the specification with a fine-tooth comb and with the following aims. a) Eliminate all requirements that are not absolutely necessary. b) Simplify all requirements that are more complicated than necessary. c) Substitute cheaper options for all requirements that have cheaper options. 3. Versioned Development You can plan out a set of requirements for a robust, complete, ideal project but then implement the project in pieces. Put in any hooks you'll nee to support the later pieces, but don't implement the pieces themselves. 14.2 Mid-Project: Feature-Creep Control A typical project experiences about 25-percent change in requirements during development. 1. Sources of change 1) Killer-app syndrome. 2) Unclear or impossible goals. If developers can't meet the project's goals, they will meet their own goals instead, and you will lose much of your influence over the project's outcome. The devil really is in the details, and implementation time can vary tremendously based on how developers interpret seemingly trivial details. No specification can hope to cover every one of these trivial details. 2. Effects of Change
People are far too casual about the effect that late changes in a project have. They underestimate the ripple effects that changes have on the project's design, code, testing, documentation, customer support, training, configuration management, personnel assignments, management and staff communications, planning and tracking, and ultimately on the schedule, budget, and product quality. When all these factors are considered, changes typically cost anywhere from 50 to 200 times less if you make them at requirements time than if you wait until construction or maintenance. Several studies have found that feature creep is the most common source of cost and schedule overruns. It is hardly ever possible to achieve high productivity unless you control changes. 3. Wisdom of Stopping Changes Altogether Here are some circumstances in which it is unwise to try to stop changes altogether. 1) When your customers don't know what they want. You can use the various incremental development practices to respond to this need. 2) When you want to be responsive to your customer. 3) When the market is changing rapidly. 4) When you want to give latitude to the developers. 5) Stable or not stable requirements? If your requirements are stable, you develop one way. If not, you develop another way. You can take certain steps to compensate for unstable requirements, and you must take those steps if you want to develop rapidly. 4. Methods of Change Control Because stopping changes altogether is rarely in a project's best interest, the question for most projects turns to how to manage change most effectively. Any change-management plan should aim for several goals: 1) Allow changes that help to produce the best possible product in the time available. Disallow all other changes. 2) Allow all parties that would be affected by a proposed change to assess the schedule, resource, and product impacts of the change. 3) Notify parties on the periphery of the project of each propose change, its assessed impact, and whether it was accepted or rejected. 4) Provide an audit trail of decisions related to the product content. The change process should be structured to perform these jobs as efficiently as possible. Here are some options for accomplis...