Use Case - In Unified Process

Use Case

^ü   In the Unified Process, use cases are used to capture the functional requirements and to define the contents of the iterations. Each iteration takes a set of use cases or scenarios from requirements all the way through implementation, test and deployment.

Architecture Centric

^ü   The Unified Process insists that architecture sit at the heart of the project team's efforts to shape the system. Since no single model is sufficient to cover all aspects of a system, the Unified Process supports multiple architectural models and views.

^ü   One of the most important deliverables of the process is the executable architecture baseline which is created during the Elaboration phase. This partial implementation of the system serves and validate the architecture and act as a foundation for remaining development.

Risk Focused

^ü   The Unified Process requires the project team to focus on addressing the most critical risks early in the project life cycle. The deliverables of each iteration, especially in the Elaboration phase, must be selected in order to ensure that the greatest risks are addressed first.

Project Lifecycle

^ü   The Unified Process divides the project into four phases:

^ü   Inception

^ü   Elaboration

ü    Construction

ü    Transition

Inception Phase

^ü  Inception is the smallest phase in the project, and ideally it should be quite short. If the Inception Phase is long then it may be an indication of excessive up-front specification, which is contrary to the spirit of the Unified Process.

^ü  The following are typical goals for the Inception phase.

^ü  Establish a justification or business case for the project

^ü  Establish the project scope and boundary conditions

^ü  Outline the use cases and key requirements that will drive the design tradeoffs

^ü  Outline one or more candidate architectures

^ü  Identify risks

^ü  Prepare a preliminary project schedule and cost estimate

^ü  The Lifecycle Objective Milestone marks the end of the Inception phase.

Elaboration Phase

^ü    During the Elaboration phase the project team is expected to capture a healthy majority of the system requirements. However, the primary goals of Elaboration are to address known risk factors and to establish and validate the system architecture. Common processes undertaken in this phase include the creation of use case diagrams, conceptual diagrams (class diagrams with only basic notation) and package diagrams (architectural diagrams).

^ü    The architecture is validated primarily through the implementation of an Executable Architecture Baseline. This is a partial implementation of the system which includes the core, most architecturally significant, components. It is built in a series of small, timeboxed iterations. By the end of the Elaboration phase the system architecture must have stabilized and the executable architecture baseline must demonstrate that the architecture will support the key system functionality and exhibit the right behavior in terms of performance, scalability and cost.

^ü    The final Elaboration phase deliverable is a plan (including cost and schedule estimates) for the Construction phase. At this point the plan should be accurate and credible, since it should be based on the Elaboration phase experience and since significant risk factors should have been addressed during the Elaboration phase.

^ü    The Lifecycle Architecture Milestone marks the end of the Elaboration phase.

Construction Phase

^ü    Construction is the largest phase in the project. In this phase the remainder of the system is built on the foundation laid in Elaboration. System features are implemented in a series of short, timeboxed iterations. Each iteration results in an executable release of the software. It is customary to write full text use cases during the construction phase and each one becomes the start of a new iteration. Common UML (Unified Modelling Language) diagrams used during this phase include Activity, Sequence, Collaboration, State (Transition) and Interaction Overview diagrams. The Initial Operational Capability Milestone marks the end of the Construction phase.

^ü    s. Normally this phase would take between two to six weeks for large projects and may be only a few days for smaller projects. The following should be done during this phase:

1.  Project idea is developed.

2.  Assess the capablilities of any current system that provides similar functionality to the new project even if the current system is a manual system. This will help determine cost savings that the new system can provide.

3.  Utilize as many users and potential users as possible along with technical staff, customers, and management to determine desired system features, functional capabilities, and performance requirements. Analyze the scope of the proposed system.

4.  Identify feature and functional priorities along with preliminary risk assessment of each system feature or function.

5.  Identify systems and people the system will interact with.

6.  For large systems, break the system down into subsystems if possible.

7.  Identify all major use cases and describe significant use cases. No need to make expanded use cases at this time. This is just to help identify and present system functionality.

8.  Develop a throw away prototype of the system with breadth and not depth. This prototype will address some of the greatest technical risks. The time to develop this prototype should be specifically limited. For a project that will take about one year, the prototype should take one month.

9.  Present a business case for the project (white paper) identifying rough cost and value of the project. The white paper is optional for smaller projects. Define goals, estimate risks, and resources required to complete the project.

10.Set up some major project milestones (mainly for the elaboration phase). A rough estimate of the overall project size is made.

11.Preliminary determination of iterations and requirements for each iteration. This outlines system functions and features to be included in each iteration. Keep in mind that this plan will likely be changes as risks are further assessed and more requirements are determined.

12.Management Approval for a more serious evaluation of the project.

13.This phase is done once the business case is presented with major milestones determined (not cast in stone yet) and management approves the plan. At this point the following should be complete:

-  Business case (if required) with risk assessment.

-  Preliminary project plan with preliminary iterations planned.

-  Core project requirements are defined on paper.

-  Major use cases are defined.

^ü    The inception phase has only one iteration. All other phases may have multiple iterations.

^ü    The overriding goal of the inception phase is to achieve concurrence among all stakeholders on the lifecycle objectives for the project. The inception phase is of significance primarily for new development efforts, in which there are significant business and requirements risks which must be addressed before the project can proceed. For projects focused on enhancements to an existing system, the inception phase is more brief, but is still focused on ensuring that the project is both worth doing and possible to do.

Objectives

^ü    The primary objectives of the Inception phase include:

^ü    Establishing the project's software scope and boundary conditions, including an operational vision, acceptance criteria and what is intended to be in the product and what is not.

^ü    Discriminating the critical use cases of the system, the primary scenarios of operation that will drive the major design tradeoffs.

^ü    Exhibiting, and maybe demonstrating, at least one candidate architecture against some of the primary scenarios

^ü    Estimating the overall cost and schedule for the entire project (and more detailed estimates for the elaboration phase that will immediately follow)

^ü    Estimating potential risks (the sources of unpredictability)

^ü    Preparing the supporting environment for the project.

Essential Activities

The essential activities of the Inception include:

1. Formulating the scope of the project.

^ü This involves capturing the context and the most important requirements and constraints to such an extent that you can derive acceptance criteria for the end product.

2. Planning and preparing a business case.

^ü    Evaluating alternatives for risk management, staffing, project plan, and cost/schedule/profitability tradeoffs.

ü

3. Synthesizing a candidate architecture

^ü    Evaluating tradeoffs in design, and in make/buy/reuse, so that cost, schedule and resources can be estimated. The aim here is to demonstrate feasibility through some kind of proof of concept. This may take the form of a model which simulates what is required, or an initial prototype which explores what are considered to be the areas of high risk. The prototyping effort during inception should be limited to gaining confidence that a solution is possible - the solution is realized during elaboration and construction.

4. Preparing the environment for the project

^ü    Assessing the project and the organization, selecting tools, deciding which parts of the process to improve.

Milestone

^ü    The Lifecycle Objectives Milestone evaluates the basic viability of the project.

Tailoring Decisions

^ü    The example iteration workflow shown at the top of this page represents a typical Inception iteration in medium sized projects. The Sample Iteration Plan for Inception represents a different perspective of the breakdown of activities to undertake in an Inception iteration. This iteration plan is more complete in terms of workflow details and activities, and as such, more suitable for large projects. Small projects might decide to do only a subset of these workflow details, deviations should be challenged and documented as part of the project-specific process.

Inception Phase includes:

^ü    Refining the scope of the project

^ü    Project planning

^ü    Risk identification and analysis

^ü    Preparing the project environment

^ü    Estimating the Budget

The Use Case Model

^ü    The Use Case Model describes the proposed functionality of the new system. A Use Case represents a discrete unit of interaction between a user (human or machine) and the system. A Use Case is a single unit of meaningful work; for example login to system, register with system and create order are all Use Cases. Each Use Case has a description which describes the functionality that will be built in the proposed system. A Use Case may 'include' another Use Case's functionality or 'extend' another Use Case with its own behaviour.

^ü    Use Cases are typically related to 'actors'. An actor is a human or machine entity that interacts with the system to perform meaningful work

A Use Case description will generally include:

1.     General comments and notes describing the use case.

2.     Requirements

3.     Constraints

4.     Scenarios

5.     Scenario diagram

Actors

^ü    An Actor is a user of the system. This includes both human users and other computer systems. An Actor uses a Use Case to perform some piece of work which is of value to the business. The set of Use Cases an actor has access to defines their overall role in the system and the scope of their action.

Constraints, Requirements and Scenarios

The formal specification of a Use Case includes:

1.  Requirements. These are the formal functional requirements that a Use Case must provide to the end user. They correspond to the functional specifications found in structured methodologies. A requirement is a contract that the Use Case will perform some action or provide some value to the system.

2.  Constraints. These are the formal rules and limitations that a Use Case operates under, and includes pre- post- and invariant conditions. A pre-condition specifies what must have already occurred or be in place before the Use Case may start. A post-condition documents what will be true once the Use Case is complete. An invariant specifies what will be true throughout the time the Use Case operates.

3. Scenarios. Scenarios are formal descriptions of the flow of events that occurs during a Use Case instance. These are usually described in text and correspond to a textual representation of the Sequence Diagram.