Team Skill 5 Summary

In Team Skill 5, we learned how to refine requirements so as to completely and concisely capture the user 's needs in such a way that the developer can build an application 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. Often, it is our team ”after all, we are closest to the project ”that can provide this specificity; this is one of our opportunities to make sure that the right system gets defined.

Various ways of organizing and documenting these requirements exist. We focused on the use-case technique for functional requirements and the supplementary specification for nonfunctional requirements. Although we made some suggestions about how to organize this requirements set, 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 requirements set, and all specifications in the set should be reflected in the development activities. Since these are the governing elements, it follows that all activities, such as regulatory constraints, should be reflected in the set and vice versa. The requirements set is a living entity that should be reviewed and updated throughout the lifetime of the project. The set should specify what functions are to be accomplished, not how they are to be accomplished. The set should be used to specify functional requirements, nonfunctional requirements, and design constraints.

The requirements set provides the detail you need to proceed to implement , or build , the right system. We'll discuss this part of the project next , in Team Skill 6, Building the Right System.