A systematic approach for software release planning is addressed here. The authors do a good job exploring the state of the art of requirements engineering. They provide an analytical structure for the problem of fitting features to software functions consistent with the capability of a development team, an estimate of feature value, a description of the use of resources to produce a release denoted as consumption, and the set of possible alternatives. This is a fine addition to our understanding of how to use quantitative methods to choose one set of features over another to satisfy some optimization criteria.

This is not an easy paper to read, but it is worth your time. You will need to remember that, in this paper, k refers to a particular release, r refers to resources required for that release, and x refers to the features in that release.

As you read the paper, the authors will expect you to recall these definitions from time to time, as well as the constraint that &Sgr; (consumption) < capacity, where consumption is the effort used to produce a set of features and capacity is the capability of the organization.

I think the approach to expressing the total net value (TNV) as a function of time is clever; their use of a genetic or-tree structure is innovative and the emphasis on trade-off analysis is welcome.

In section 5.3, the authors pose six questions, which are then answered in sections 5.4 to 5.9. In section 5.7, the paper shows the first release has a break-even point “where the release plan values tended to be highest.”

I am bothered by the tacit assumption that features and functions are the same and that capacity is constant. There needs to be a matrix mapping of features to functions; it may turn out that a low-value feature may be realized with small effort, and therefore might be implemented even though it has low estimated value [1]. There may be some features that are mandatory for every release; there does not seem to be an explicit provision for the continuous modeling and calibration of benefit and development efforts. Even though equation 5 does make capacity a function of release dates, there seems to be no way to increase the overall capacity of a software shop by upgrading the software engineering tools or processes or hiring new people.

Putnam and Myers [2] showed that shortened schedules decrease the features that can be produced unless the project manager adds substantial staff. However, the internal structure of the software may prevent having separate teams work independently on various features, so fewer features will be delivered on a shortened schedule. These improvements must be made before the EXPLODE+ tool they advocate is appropriate for large projects that are greater than 50,000 new or changed source lines of code.

Nevertheless the paper is a well-written, thought-provoking, fine tutorial on this emerging branch of requirements engineering. It is suitable for software people, systems people, and business analysts.