Activity: Prioritize Use Cases

Purpose To define input to the selection of the set of scenarios and use cases that are to be analyzed in the current iteration. To define the set of scenarios and use cases that represent some significant, central functionality. To define the set of scenarios and use cases that have a substantial architectural coverage (that exercise many architectural elements) or that stress or illustrate a specific, delicate point of the architecture.
Steps Prioritize use cases and scenarios Document the use-case view Evaluate your results
Input Artifacts: Vision Use-Case Model Requirements Attributes Iteration Plan Glossary Iteration Plan	Resulting Artifacts: Requirements Attributes, updated Software Architecture Document, use-case view, refined for the current iteration Glossary, refined Iteration Plan, refined
Worker: Architect

Workflow Details:

Core Workflow: Requirements

Manage the Scope of the System

Core Workflow: Analysis & Design

Define a Candidate Architecture

Refine the Architecture

Core Workflow: Project Management

Plan for Next Iteration

Prioritize Use Cases and Scenarios

An architect proposes the technical contents and the order of successive iterations by selecting a certain number of scenarios and use cases to be analyzed and designed. This technical proposal is completed and refined by the various development teams, based on personnel availability, customer requirements in terms of deliverables, availability of tools and COTS products, and the needs of other projects.

The selection of scenarios and use cases that constitute the use-case view is driven by:

╖ Critical (or primary). These have to do with the main tasks of the system, its basic function, the functions for which it is being developed. If they are missing the system fails to fulfill its primary mission. They drive the architectural design and tend to be the most frequently exercised use cases.

╖ Important (or secondary). These have to do with the support of the system's functions, such as statistical data compilation, report generation, supervision, and function testing. If they are missing the system can still (for a while) fulfill its fundamental mission, but with degraded service quality. In modeling, less importance will be attached to them than to critical use cases

╖ Ancillary (nice to have). These are "comfort" features, not linked to the system's primary mission but that help in its use or market positioning.

In general the impact on architecture is correlated to the criticality. However, it should be noted that there may be critical use cases that have little or no impact, and vice versa, some ancillary use case may have a big impact on the architecture, which makes it questionable from a business perspective.

Document the Use-Case View

The use-case view is documented in the use-case view section of the Software Architecture Document. This section contains a listing of the significant use cases and scenarios within each package in the use-case model, together with significant properties such as descriptions of the flow of events, relationships, use-case diagrams, and special requirements related to each use case. Note that if the use-case view is developed early in the iteration, some of these properties may not yet exist.

Evaluate Your Results

The use-case view should be checked at this stage to verify that the work is on track, but not to review the use-case view in detail. See especially checkpoints for use-case view in Activity: Review the Architecture.