36.1. Ranking Requirements
Early Iteration Drivers: Risk, Coverage, Criticality, Skills Development
What to do in the earliest iterations? Organize requirements and iterations by risk, coverage, and criticality [Kruchten00]. Requirement risk includes both technical complexity and other factors, such as uncertainty of effort, poor specification, political problems, or usability. Ranking requirement risks is to be contrasted with ranking project risks, which is covered in a later section.
Coverage implies that all major parts of the system are at least touched on in early iterations—perhaps a “wide and shallow” implementation across many components. Criticality refers to functions of high business value; that is, primary functions should have at least partial implementations for main success scenarios in the earlier iterations, even if not technically risky.
On some projects, another driver is skills development—a goal is to help the team master new skills such as adopting object technologies. On such projects, skills development is a heavily weighted prioritization factor which tends to reorganize the iterations into less risky or simpler requirements in early iterations, motivated by learning rather than risk reduction goals.
What to Rank?
The UP is use-case driven, which includes the practice of ranking use cases (and scenarios of use cases) for implementation. Also, some requirements are expressed as high-level features unrelated to a particular use case, usually because they span many use cases or are a general service, such as logging services. These non-use case functions will be recorded in the Supplementary Specification. Therefore, include both use cases and other high-level features in a ranking list.
| Requirement | Type | . . . |
|---|---|---|
| Process Sale | UC | . . . |
| Logging | Feature | . . . |
| . . . | . . . | . . . |
Group Qualitative Methods for Ranking
Based on the drivers, requirements are ranked, and high priorities are handled in early iterations. The ranking may be informal and qualitative, generated in a group meeting by members mindful of these drivers.
|
Suggestion To informally prioritize requirements, tasks, or risks via a group meeting, use iterative “dot voting.” List the items on a whiteboard. Everyone gets, for example, 20 sticky dots. As a group, and in silence (to reduce influence), all approach the board and apply dots to the items, reflecting the voter's priorities. A voter can assign many dots to one item. On completion, sort and discuss. Then do a second round of silent dot voting to reflect updated insight based on first round voting and discussion. This second round provides the feedback and adaptation by which decisions improve. |
The requirements or risk ranking will be done before iteration 1, but then again before iteration 2, and so forth.
Quantitative Methods for Ranking
Group discussion and something like dot voting for requirements or risk ranking are probably sufficient—a fuzzy qualitative approach. For the more quantitatively minded, variations on the following have been used. The example values and weights are only suggestive; the point is that numeric values and weights can be used to reason about priorities.
On any project, the exact values should not be taken too seriously; on completion, the numeric scoring can be used to help group the requirements into fuzzy sets of high, medium, and low ranking. Clearly, Process Sale appears important to work on in early iterations.
The numbers don't tell the whole story. Even though logging is a low-risk, simple feature, it is architecturally significant because it needs to be integrated throughout the code from the start. It would be awkward and diminish architectural integrity to add it as an afterthought.
Ranking the NextGen POS Requirements
Based on some ranking method, a fuzzy grouping of requirements is possible. In terms of UP artifacts, this ranking is recorded in the UP Software Development Plan.
| Rank | Requirement (use case or feature) | Comment |
|---|---|---|
| High | Process Sale
Logging . . . | Scores high on all ranking criteria.
Pervasive. Hard to add late. . . . |
| Medium | Maintain Users
Authenticate User . . . | Affects security subdomain.
Important process but not too difficult. . . . |
| Low | Cash Out
Shut Down . . . | Easy; minimal effect on architecture.
Ditto. . . . |
The “Start Up” and “Shut Down” Use Cases
Virtually all systems have a Start Up use case, implicit if not explicit. Although it may not rank high by other criteria, it is necessary to tackle at least some simplified version of Start Up in the first iteration so that the initialization assumed by other cases is provided. Within each iteration, the Start Up use case is incrementally developed to satisfy the start up needs of the other use cases. Similarly, systems often have a Shut Down use case. In some systems, it is quite complex, such as shutting down an active telecommunications switch. In terms of planning, if simple, these use cases can be informally listed in the Iteration Plan, such as “implement startup and shutdown as required.” Obviously, complex versions need more careful requirements and planning attention.
A Caveat: Project Planning vs. Learning Goals
The book goal is to offer a learning aid for introductory analysis and design, rather than actually run the NextGen POS project. Therefore, some license has been taken in the choice of what is tackled in the early iterations of the case study, motivated by learning rather than project goals.