Task: Prioritize Use Cases
var backPath = './../../';
var imgPath = './../../images/';
var nodeInfo=[{view: "view:_LVCagP5WEdmAzesbYywanQ", path: ["_LVCagP5WEdmAzesbYywanQ", "_gpYSoAILEdq-_NKqZM1EhA", "_26PQIAIMEdq-_NKqZM1EhA", "_ydt60dnmEdmO6L4XMImrsA", "{6E23D919-D149-43C2-9D37-8AF77B667CA8}"]}, {view: "view:_LVCagP5WEdmAzesbYywanQ", path: ["_LVCagP5WEdmAzesbYywanQ", "_zRigkAILEdq-_NKqZM1EhA", "_qwxC8N7YEdmjRZts2c4ZjQ", "{4AC346F0-E6FC-4D2C-8410-2EDF8DDDC91D}", "{6E23D919-D149-43C2-9D37-8AF77B667CA8}"]}, {view: "view:_FCx1oN7CEdmsEI4YDGX2ag", path: ["_FCx1oN7CEdmsEI4YDGX2ag", "_f6_YwN7DEdmsEI4YDGX2ag", "_qwxC8N7YEdmjRZts2c4ZjQ", "{4AC346F0-E6FC-4D2C-8410-2EDF8DDDC91D}", "{6E23D919-D149-43C2-9D37-8AF77B667CA8}"]}, {view: "view:_FCx1oN7CEdmsEI4YDGX2ag", path: ["_FCx1oN7CEdmsEI4YDGX2ag", "_kC0pcN7GEdm8G6yT7-Wdqw", "_ydt60dnmEdmO6L4XMImrsA", "{6E23D919-D149-43C2-9D37-8AF77B667CA8}"]}];
contentPage.preload(imgPath, backPath, nodeInfo, '', true, false, false);
Task: Prioritize Use Cases
This task is where the use cases are prioritized, so that their order of development can be decided. This task is where the architecturally-significant use cases are identified and prioritized.
Disciplines: Requirements
Purpose
The purpose of this activity is to:
Define input to the selection of the set of scenarios and use cases that are to be analyzed in the current
iteration.
Define the set of scenarios and use cases that represent some significant, central functionality.
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.
Relationships
RolesPrimary Performer:
Software Architect
Additional Performers:
InputsMandatory:
Iteration Plan
Risk List
Software Architecture Document
Use-Case Model
Optional:
Software Requirement
Vision
Outputs
Software Architecture Document
Software Requirement
Process Usage
Requirements
>
Manage the Scope of the System
>
Prioritize Use Cases
Main Description
Some of the factors that are used to determine the priority of the use cases may be captured as Software Requirement attributes. The resulting use-case
priorities may also be captured as requirements attributes, so that they can be managed effectively.
Steps
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 are considered "architecturally significant" (e.g., constitute the
use-case view of the architecture) is driven by some key driving factors, summarized below.
The benefit of the scenario to stakeholders: critical, important, useful.
The architectural impact of the scenario: none, extends, modifies. There may be critical use cases that have little
or no impact on the architecture, and low benefit use cases that have a big impact. Low benefit use cases with big
architectural impacts should be reviewed by the project manager for possible de-scoping.
The risks to be mitigated (performance, availability of a product, and suitability of a component).
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: demonstration to the user, and so on.
There may be two scenarios that hit the same components and address similar risks. If you implement A first, then B is
not architecturally significant. If you implement B first, then A is not architecturally significant. So these
attributes can depend on the iteration order, and should be re-evaluated when the ordering changes, as well as when the
requirements themselves change.
Architecturally significant use cases that are poorly understood or likely to change should be prioritized for
clarification and stabilization. In some cases, this means further requirements analysis should be done before
implementing the requirement. In other cases, some form of prototyping may be best.
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. For specific recommendations on what to look for during the review, see Checklist: Software Architecture Document.
More Information
Concepts
Use-Case View
© Copyright IBM Corp. 1987, 2006. All Rights Reserved.
contentPage.onload();
Wyszukiwarka
Podobne podstrony:
prioritize use?sesfind?tors and use?sesCB35F0the estimation of?fort?sed on use?ses?41D15BAre Mathematical Truths Synthetic a PrioriA PrioriMożliwość zdań syntetycznych a priori logikaPriorityBlockingQueueMaxi Cosi priori xpPriorityBlockingQueuebalance competing stakeholder priorities?3BB4BCPriorityQueuePriorityBindingDemo csproj FileListAbsolutepriority queuefinding?tors and use?ses rup xde uc?B7A9F7083 ABY 0000 Priority Xdesigning use?ses581AAAPriorityQueuewięcej podobnych podstron