Difference between revisions of "Use Case Candidates"
(→What) |
(→Why) |
||
| (6 intermediate revisions by the same user not shown) | |||
| Line 2: | Line 2: | ||
== What == | == What == | ||
| − | Candidates for designing advanced use cases | + | Candidates for designing advanced use cases. |
== How == | == How == | ||
| Line 21: | Line 21: | ||
Consider which situations the user could face when he uses the system. All these situations are potential candidates for a use case. Do not assess the candidates now. The gross list with all possible and less possible candidates are useful and are assessed when writing the use cases. | Consider which situations the user could face when he uses the system. All these situations are potential candidates for a use case. Do not assess the candidates now. The gross list with all possible and less possible candidates are useful and are assessed when writing the use cases. | ||
| − | The customer can, with great success, be involved in this process, | + | The customer can, with great success, be involved in this process, since it is in fact the customer's use of the system we are trying to describe. Consult the customer with the list and compile all the comments relevant for the candidates. It might be helpful later on in the development process. |
== Why == | == Why == | ||
| − | In order to be open minded and not assess any possible use case candidates before actual analysis and description of the use cases in | + | In order to be open-minded and not assess any possible use case candidates before the actual analysis and description of the use cases in which they participate, the developer should produce a candidate list. |
| − | + | By preparing the list of all possible use case candidates without assessment of the individual candidate, the developer ends up with a list that probably contains at least all possible candidates. | |
| − | The assessment later in analysis will eliminate the candidates not suitable for the system-to-be. | + | The assessment later on in the analysis will eliminate the candidates not suitable for the system-to-be. |
== Example == | == Example == | ||
| Line 49: | Line 49: | ||
Set time | Set time | ||
| − | + | Drive | |
Accelerate | Accelerate | ||
| Line 59: | Line 59: | ||
== Used In == | == Used In == | ||
| − | The candidates | + | The candidates are used in cooperation with [[Actor Candidates]] to define the [[Use Cases]] for the [[system-to-be]] |
Latest revision as of 11:15, 1 October 2015
What
Candidates for designing advanced use cases.
How
The dish
Candidates for Use Cases
Ingredients
Process
Consider which situations the user could face when he uses the system. All these situations are potential candidates for a use case. Do not assess the candidates now. The gross list with all possible and less possible candidates are useful and are assessed when writing the use cases.
The customer can, with great success, be involved in this process, since it is in fact the customer's use of the system we are trying to describe. Consult the customer with the list and compile all the comments relevant for the candidates. It might be helpful later on in the development process.
Why
In order to be open-minded and not assess any possible use case candidates before the actual analysis and description of the use cases in which they participate, the developer should produce a candidate list.
By preparing the list of all possible use case candidates without assessment of the individual candidate, the developer ends up with a list that probably contains at least all possible candidates.
The assessment later on in the analysis will eliminate the candidates not suitable for the system-to-be.
Example
Turn the vehicle on
Turn the vehicle off
Emergency shut down
Change reading on dashboard
Read energy level
Set max speed
Read log
Set time
Drive
Accelerate
Turn
Brake
Used In
The candidates are used in cooperation with Actor Candidates to define the Use Cases for the system-to-be
