Effective Software Project Management

Requirements Gathering

The structure that I recommend goes something like this:

Problem→Goal→Solution→Requirements→Functions→Features

If you are reasonably certain that all features have been identified and defined, use a Linear or Incremental SDPM strategy. If you think all functions have been defined and some features have not been defined, use an Iterative SDPM strategy. If some or most parts of the requirements (and hence of the solution) have not been defined, use an Adaptive SDPM strategy. If the goal and solution have not been clearly defined, use an Extreme SDPM strategy. This is the hierarchy followed throughout the book. In this part, I will use the case study to illustrate several concepts. The focus will be on Project 1. Project 2 will be covered in more detail in the chapters on the Adaptive SDPM strategy (Chapters 24-30).

Defining and Managing Customer Requirements

You can go about defining and managing customer requirements in two ways. In simpler situations, you can use Conditions of Satisfaction (COS) described in Appendix D. COS scales up to a certain point where the complexity of the project makes COS a poor choice and something a bit more sophisticated is required. You might prefer to use a more structured approach to gathering customer requirements. That would be the Volere process, which is also defined in Appendix D.

Gathering Customer Requirements

Simply put, project teams that make a concerted effort to manage customer requirements do so because they ...