Difference between revisions of "Use Cases"
(→Example) |
|||
| (22 intermediate revisions by 3 users not shown) | |||
| Line 2: | Line 2: | ||
== What == | == What == | ||
| − | Use Case Analysis | + | 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 == | == How == | ||
| Line 14: | Line 12: | ||
'''Ingredients ''' | '''Ingredients ''' | ||
| − | * Preliminary Use Cases | + | * [[Preliminary Use Cases]] |
| − | * Use Case Candidates | + | * [[Use Case Candidates]] |
| − | * Actor Candidates | + | * [[Actor Candidates]] |
'''Process''' | '''Process''' | ||
| − | Draw a | + | '''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. | |
| − | The purpose of writing is to get as much | + | '''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. | 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 in the development process. | + | 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 == | == Why == | ||
| Line 47: | Line 48: | ||
Why is a use case important? | Why is a use case important? | ||
| − | A use case is important for the developer if | + | 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 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 | + | 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 == | ||
| − | |||
| − | + | 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. | |
| − | + | [[Image:Use_Case_analysis.png|600 px]] | |
| − | + | [[Image:UseCases.png|600 px]] | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | == 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]] | |
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.
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
