In the introductory chapters, we learned that our industry often does a poor job of delivering quality applications on time and on budget. Some of the root causes of this problem are also clear. 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.

Perhaps developers and customers alike have a common attitude that "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 wanted or what the current system really does.

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? To address these issues, we recommend an encompassing philosophy of requirements management, which we defined as

Since the history of software development—and the future for at least as far as we can envision it—is one of ever increasing complexity, we also understand that the software development problem must be addressed by well-structured and well-trained software teams. Every team member will eventually be involved in helping manage 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 Team Skill 1, we introduced a set of skills that your team can apply to understand the problem to be solved before application development begins. We introduced a simple, five-step problem analysis technique that can help your team gain a better understanding of the problem to be solved.

All in all, following this process will improve your team's ability to address the challenge ahead, providing a solution to the problem to be solved.

We also noted that a variety of techniques can be used in problem analysis. Specifically, we looked at business modeling, a specific problem analysis technique that works quite well in complex information systems that support key business infrastructures. The team can use business modeling to both understand the way in which the business evolves and to define where within the system we can deploy applications most productively. We also recognized that the business model we defined will have parallel constructs in the software application, and we use this commonality to seed the software design phases. We will also use the business use cases we discovered again later to help define requirements for the application itself.

For the embedded-system software applications, we used systems engineering as a problem analysis technique to help us decompose a complex system into subsystems. This process helps us to understand where software applications should lie and what overall purpose they serve. In so doing, we also learned that we complicate the requirements matter somewhat by defining new subsystems, for which we must, in turn, come to understand the requirements to be imposed.

We started Team Skill 2 by introducing three "syndromes" that increase the challenge of understanding the real needs of users and other stakeholders. The "Yes, But," the "Undiscovered Ruins'" and the "User and the Developer" syndromes were used as metaphors to help us better understand the challenge ahead and to provide a context for the elicitation techniques that we developed in this Team Skill.

We also recognized that since we rarely have been given effective requirements specifications for the systems we are going to build, in order to do a better job of building these systems, we are going to have to go out and get the information we need to be successful. Requirements elicitation is the term we used to describe this process, and we concluded that the team must play a more active role in this process.

To help the team on this mission, we then presented a variety of techniques for addressing these problems and better understanding the real needs of users and other stakeholders. These techniques were

Although no one technique is perfect in every circumstance, each represents a proactive means of pushing knowledge of user needs forward and thereby converting "fuzzy" requirements to requirements that are "better known." Although all of these techniques work in certain circumstances, we did admit to a favorite: the requirements workshop/brainstorming technique.

In Team Skill 3, we moved from understanding the needs of the user to starting to define the solution. In so doing, we took our first baby steps out of the problem domain, the land of the user, and into the solution domain, wherein our job is to define a system to solve the problem at hand.

We also learned that complex systems require comprehensive strategies for managing requirements information, and we looked at a number of ways to organize requirements information. We recognized that we really have a hierarchy of information, starting with user needs, transitioning through features, then into the more detailed software requirements as expressed in use cases or traditional forms of expression. Also, we note that the hierarchy reflects the level of abstraction with which we view the problem space and the solution space.

We then "zoomed in" to look at the application definition process for a stand-alone software application and invested some time in defining a Vision document for such an application. We maintain that the Vision document, with modifications to the particular context of a company's software applications, is a crucial document and that every project should have one.

We also recognized that without someone to champion the requirements for our application and to support the needs of the customer and the development team, we would have no way to be certain that the hard decisions are made. Requirements drift, delays, and suboptimum decisions forced by project deadlines are likely to result. So, we decided to appoint someone or to anoint someone to own the Vision document and the features it contains. In turn, the champion and the team will empower a change control board to help with the really tough decisions and to ensure that requirements changes are reasoned about before being accepted.

In Team Skill 5, we learned that the problem of project scope is endemic. It is not unusual that projects are initiated with twice the amount of functionality that the team can reasonably implement in a quality manner. We shouldn't be surprised by this, as it is the nature of the beast: Customers want more, marketing wants more, and the team wants more. We just need to make sure that we can deliver something on time.

In order to manage scope, we looked at various techniques for setting priorities, and we defined the notion of the baseline, an agreed-to understanding of what the system will do, as a key project work product. We learned that if scope and the concomitant expectations exceed reality, in all probability, some bad news is about to be delivered. We decided on a philosophy of approach that engages our customer in the hard decisions. After all, we are just the resources, not the decision makers; it's our customer's project. So, the question is, What, exactly, must be accomplished in the next release, given the resources that are available to the project?

Even then, we expect to do some negotiating. We briefly mentioned a few negotiation skills and hinted that the team may need to use them on occasion.

We cannot expect that the process described so far will make the scope challenge go away, any more than any other single process will solve the problems of the application development world. However, the steps outlined can be expected to have a material effect on the scope of the problem, allowing application developers to focus on critical subsets and to incrementally deliver high-quality systems that meet or exceed the expectations of the user. Further, engaging the customer in helping solve the scope management problem increases commitment on the part of both parties and fosters improved communication and trust between the customer and application development teams.

With a comprehensive project definition, or Vision document, in hand and scope managed to a reasonable level, we at least have the opportunity to succeed in the next phases of the project.

In Team Skill 6, we learned that requirements are the key communication technique to capture the user's needs in such a way that the developer can develop a system to meet those needs. In addition, requirements need to have sufficient specificity so that we can tell when they have been met. We needn't be alarmed by this, as it is often our team members—after all, we are closest to the project—who can provide this specificity. This is one of our opportunities to make sure that the right system gets defined.

These requirements can be organized and documented in a variety of ways. We focused on what we called a Modern SRS Package, a logical construct that allows us to document requirements in use cases, documents, database forms, or other techniques. Although we made some suggestions on how to organize this package, we don't really care what form it takes, so long as it contains the right things.

All development should flow from the requirements specified in the Modern SRS Package. Nothing should be developed outside this package, and all specifications in the package should be reflected in the development activities. Since these are the governing elements, it follows that all activities, such as regulatory constraints, should reflect the package and vice versa. The Modern SRS Package is a living package that should be reviewed and updated throughout the lifetime of the project. The package should specify what functions are to be accomplished, not how they are to be accomplished. The Modern SRS Package should be used to specify functional requirements, nonfunctional requirements, and design constraints.

We also provided a set of quality measures for assessing the quality of your package and the various elements contained therein. Where necessary, the requirements documentation may be supplemented by one or more formal, or more structured, methods of specification. The Modern SRS Package provides the detail you need to proceed to implement, or build, the right system.

Designing and implementing the correct system is the biggest job of all. One useful technique is to use the requirements and use cases to drive the implementation architecture and design.

Verification is an analytic approach that allows you to constantly monitor the evolution of the project's features, requirements, design, and implementation. Verification is supported by the use of traceability techniques to relate parts of your project to one another. By using traceability, you can verify that

Although verification is an analytical technique, it is important to remember that thinking is important. You can't simply apply the verification techniques mechanically.

Validation, the other half of the V&V approach to ensuring that the system is built correctly, focuses on testing and uses traceability techniques to select system components that will require testing. As in verification, we use the validation techniques to ensure that

You may also need to apply hazard analysis and risk analysis to help you decide which portions of your system need verification and validation, and in what amounts.

We also described how periodic acceptance testing could help keep our projects on track.

Finally, building the right system also depends on managing change. We learned that change is just part of life, that we must plan for change and develop a process whereby we can manage it. Managing change helps us make sure that the system we built is the right system and, moreover, that it continues to be the right system over time.