Use Case Candidates

From EUDP
Revision as of 14:31, 10 August 2009 by Ellyk (Talk)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

What

Candidates for designing advanced use cases,

How

The dish

Candidates for Use Cases

Ingredients

  • Preliminary Use Cases
  • Event Candidates

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