Difference between revisions of "Use Case Candidates"

From EUDP
Jump to: navigation, search
m (How: links added)
(Example: Added Used In)
Line 56: Line 56:
  
 
Set Summer time
 
Set Summer time
 +
 +
 +
== Used In ==
 +
 +
The candidates is used in cooperation with [[Actor Candidates]] to define the [[Use Cases]] for the [[system-to-be]]

Revision as of 08:48, 15 September 2009

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, because it is actually the customers use of the the system we are trying to describe. Consult the customer with the list and get all comments relevant for the candidates. It might help later in the development process.

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 where they may participate the developer should produce a candidate list.

Preparing the list of all possible use case candidates without assessment of the individual candidate, the developer ends up with a list probably containing at least all possible candidates.

The assessment later in analysis will eliminate the candidates not suitable for the system-to-be.

Example

Configure day and night temperatures

Configure week plan

View outdoor temperature

View Solar Power production

View all temperatures daily

View all temperatures weekly

View all temperatures monthly

Raise indoor temperature

Set on night permanently

Resume week plan

Set time

Set time server

Set Summer time


Used In

The candidates is used in cooperation with Actor Candidates to define the Use Cases for the system-to-be