Activity: Prioritize Use Cases

Roles and Activities > Developer Role Set > Software Architect > 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: Iteration Plan Vision Use-Case Model Requirements Attributes Software Architecture Document	Resulting Artifacts: Requirements Attributes Software Architecture Document
Role: Software Architect

Workflow Details:

Requirements

Manage the Scope of the System

Analysis & Design

Refine the Architecture

Prioritize Use Cases and Scenarios

A software 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 the following:

The benefit of the scenario to stakeholders: critical, important, useful. See Guidelines: Requirements Management Plan, Benefit.
The architectural impact of the scenario: none, extends, modifies. See Guidelines: Requirements Management Plan, Architectural Impact.
The risks to be mitigated (performance, availability of a product, and suitability of a component). See Guidelines: Requirements Management Plan, Risk
The completion of the coverage of the architecture (making sure that at the end of the Elaboration phase, every piece of software to be developed has found a home in the Implementation View).
Other tactical objectives or constraints: demo to end-user, and so on.

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.

Rational Unified Process