Books on business analysis and requirements engineering, such as my own Software Requirements, describe dozens of “good practices” that can help any organization improve the way it develops and manages requirements for its products. Learning about the practices is one thing; implementing them and reaping the benefits is quite another. Putting better practices into action is the essence of software process improvement. In a nutshell, process improvement consists of using more of the approaches that work well for us and avoiding those that have given us headaches in the past. However, the path to improved performance is paved with false starts, resistance from those who are affected, and the frustration of having too little time to handle current tasks, let alone improvement programs. The ultimate objective of software process improvement is to reduce the cost of creating and maintaining software. There are several ways to accomplish this:

• Correcting problems encountered on previous or current projects
• Anticipating and preventing problems that you might encounter on future projects
• Adopting practices that are more efficient than the practices currently being used

If your team’s current methods seem to work well (or if people insist that they do despite evidence to the contrary), people might not see the need to change their approach. However, even successful software organizations can struggle when confronted with larger projects, different customers, long-distance collaborations, tighter schedules, or new application domains. An approach that works for a co-located team of five people with a single customer doesn’t scale up to 125 project participants located in two different time zones who are serving hundreds of corporate customers. At the least, you should be aware of other approaches to requirements that could be valuable additions to your software engineering tool kit. Let’s begin our journey through requirements process improvement by seeing how requirements activities relate to various other key project processes. Changing how your projects handle requirements will of necessity affect these other processes, and vice versa. If you want to succeed with requirements improvement, you’ll need to get the owners of these other process areas to play along.

How Requirements Relate to Other Project Processes

Requirements lie at the heart of every well-run software project, supporting and enabling the other technical and management activities. Figure 1 illustrates some connections between requirements and other processes; the sections that follow briefly describe these process interfaces.

Project planning. Too often, project deadlines and staff allocations are determined before the requirements are well understood. It's no wonder then that so many projects overrun their schedules and budgets. A more realistic approach is to make requirements the foundation of the project planning process. The planners select an appropriate software development life cycle and develop resource and schedule estimates based on the requirements. Thoughtful planning might indicate that it’s not possible to deliver the entire desired feature set within the available bounds of resources and time. The planning process can lead to reductions in the project scope or to selecting an incremental or iterative to deliver functionality in planned chunks.