Difference between revisions of "Use Cases"

From EUDP
Jump to: navigation, search
(Used In)
(Example)
 
Line 96: Line 96:
 
  2. Logs have been updated with events during the power-up and power-down sequence
 
  2. Logs have been updated with events during the power-up and power-down sequence
 
  3. Leds are blinking
 
  3. Leds are blinking
 +
 +
Often it can be easier to overlook a table. The same Use Case as above is here set in a table.
 +
 +
[[Image:Use_Case_analysis.png|600 px]]
  
 
[[Image:UseCases.png|600 px]]
 
[[Image:UseCases.png|600 px]]

Latest revision as of 08:51, 3 October 2016

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.

Assess and select 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 s/he wonders how the interaction with the system is accomplished. Therefore, the main purpose of writing a use case is to understand the interaction with the system. Focusing on the difficult interactions often leads to the solution!

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

The use case diagram helps to get an overview of the actor interaction with the various 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, e.g. in the user interface description.

Example

Example of a use case from the diagram:

Name
Turn on the vehicle

Brief description
Turn on all electronics and prepare 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 in the correct order
2. The error led is set to blink

Postconditions
Successful completion
1. The vehicle is powered and ready for driving
2. Logs have been updated with events during the power-up sequence

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

Often it can be easier to overlook a table. The same Use Case as above is here set in a table.

Use Case analysis.png

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