Use Cases

From EUDP
Revision as of 12:15, 1 October 2015 by Charlotte (Talk)

Jump to: navigation, search

What

Use Case Analysis: An assessment and a selection of the Use Case Candidates and Actor Candidates, a description of the selected candidates and finally, the drawing of a use case diagram with use cases and actors.

How

The dish

Use Case Analysis

Ingredients

Process

Draw a use case diagram

As a help to understand the user interaction with the system, the developer can choose a use case diagram. Sometimes it helps to do this before the actual writing of the use cases, but it may also be a help to assess the use cases after they have been written.

You prepare the use case diagram by drawing the use cases as bubbles with names in a single column. At the left or the right side of the use cases, you draw the different actors of the system. Draw lines from the actor to the use cases in which he/she/it participates.

Assessment and selection of Use Case Candidates

From the list of use case candidates and maybe also the use case diagram, you now choose which ones are most important and subsequently write them.

Unimportant use cases are usually the ones the developer knows exactly how to implement. A developer who develops e.g. web applications will not write a use case for the login process, because this is a standard procedure on websites, but perhaps the developer will write a use case describing how a user would update the contents of the site.

When you have chosen the most important use cases, see if some of them contain more or less the same interaction with the system. Maybe these use cases should only be written as one use case? If two or more use cases have almost the same type of interaction with the system, e.g. entering data information into a form, it might be sufficient to write only one of them.

How to write use cases

The developer has chosen which use cases are the most important, and it is now time to write out the use case candidates. Write them as text (5-50 lines) and write from a user's (human or system's) point of view how he/she/it would interact with the system-to-be.

The purpose of writing is to get as much knowledge about the system as possible, so that you can estimate the development price of the system-to-be. Normally, this means that the developer only writes the most important success scenarios, and maybe a single fail scenario.

Do not write how to implement the functions, but write them as a use case, i.e. how to use the system.

Only write the use cases which help you understand the system better, and save the other ones until later on in the development process.

Why

The main goal of this project phase is for the developer to get an idea of the range of the project, so it is possible to estimate the economics of the project.

Why is a use case important?

A use case is important for the developer if he/she wonders how this interaction with the system will accomplish. Therefore, the main purpose of writing a use case is to get a grip of the interaction with the system. Focusing on the difficult interactions often facilitate the solution!

The use case analysis helps gather all the different user aspects of the project. The developer assesses the importance of the different use cases and thereby he/she realises where some of the difficulties in the project are. By writing the success scenario, the developer transforms all the thoughts that he/she has in his/her mind to the paper. This way it is possible to focus on other aspects in the project, and maybe see new angles.

The use case diagram helps to get an overview of the actor interaction with the different use cases. It is a quick task to draw such a diagram, but it shows the most important actors which can be used later on in e.g. the user interface description.

Example

Below is an example of one use case from the diagram seen below.

Name
Turn on the vehicle

Brief description
Turns on all electronics and prepares the vehicle for driving

Actors
Engineer
Driver

Preconditions
The energy source is present in the vehicle.
The vehicle is turned off.

Basic flow of events
1. Actor turns the main switch
2. Power is distributed to systems following the specified scheme
3. The use case ends successfully

Alternative flows

No energy source present
1. Led Energy source is set to blink

Error on an attached component
1. The power on sequence is reversed to power off the modules i correct order
2. The Error Led is set to blink

Post Conditions
Successful completion
1. The vehicle is powered and ready for driving
2. Logs has been updated with events during the power up sequence

Failure completion
1. There is no power on the vehicle modules
2. Logs has been updated with events during the power up and down sequence
3. Leds blinking


UseCases.png

Used In

The Use Cases are used in the rest of the design phase as well as in the Realisation Phase. From here you may want to go to the Interface Analysis