Summary

It's difficult for anyone to argue rationally against the idea of managing and documenting the requirements of a system in order to ensure that we deliver what the customer really wants. However, as we have seen, the data demonstrates that, as an industry, we often do a poor job of doing so. Lack of user input, incomplete requirements and specifications , and changing requirements and specifications are commonly cited problems in projects that failed to meet their objectives. And we know that a significant number of software projects do fail to meet their objectives.

A common attitude among developers and customers alike is, "Even if we're not really sure of the details of what we want, it's better to get started with implementation now, because we're behind schedule and in a hurry. We can pin down the requirements later." But all too often, this well-intentioned approach degenerates into a chaotic development effort, with no one quite sure what the user really wants or what the current system really does. With today's powerful and easy-to-use prototyping tools, there's a perception that if the developers can build a rough approximation of the user's needs in a prototype, the user can point out the features that need to be added, deleted, or modified. This can work, and it is an important aspect of iterative development. But, due in part to the extremely high cost of fixing requirements errors, this process must be within the context of an overall requirements management strategy ” otherwise , chaos results.

How do we know what the system is supposed to do? How do we keep track of the current status of requirements? How do we determine the impact of a change? Issues like these cause requirements management to emerge as both a necessary and a practical software engineering discipline. We have introduced an encompassing philosophy of requirements management and have provided a set of definitions that support these activities.

Since the history of software development ”and the future for at least as far as we can currently envision it ”is one of increasing complexity, we also understand that the software development problem is one that must be addressed by well-structured and well-trained software teams . In the requirements management discipline in particular, every team member will eventually be involved in managing the requirements for the project. These teams must develop the requisite skills to understand the user needs, to manage the scope of the application, and to build systems that meet these user needs. The team must work, as a team , to address the requirements management challenge.

In order to do so, the first step in the requirements management process is to ensure that the developers understand the "problem" the user is trying to solve. We'll cover that topic in the next three chapters as Team Skill 1, Analyzing the Problem.