Use Cases

Intro

• A use case is a typical interaction that a user has with the system in order to achieve a goal.
• A use case does two things:

1. Describe how an actor achieves a goal using the system. This is described in terms of scenarios.
2. Ensures interests of stakeholder are protected by the system.

• Use cases drive the whole development process.
• Use cases provide the basis of communication between the customers and developers in planning a project.
  • e.g. deciding which use cases to include in the current release.
• Use cases can be used to capture the systems functional requirements.
• Defined the systems functional acceptance tests.

Actor

• An actor is someone or something external to the system and who interacts with the system.

Scenario

• A scenario is a description of a sequence of actions that is a way of achieving a goal.
• The main success scenario is the usual/main/straightforward way of achieving the goal.
• All scenarios have
  • A precondition : required condition before starting.
  • Interaction steps
  • Postcondition :
    • Guaranteed state of world once use case exits. successful precondition holds for successful exit.
  • A minimal postcondition: Something that guarantees to protect stakeholder interests.

• For each step of main success scenario, think of:
• Secondary Scenarios:
  • Alternative Scenario: A different way of achieving success (the goal)
  • Exception Scenario: Something that can go wrong - and can lead to a different postcondition.

• The scenarios must be kept free of design assumptions.

Structuring Use Cases

Inclusion

• A step in the scenario of a use case that is detailed - and might be another use case by itself.
• The main use case "calls" the inclusion use case.
• For e.g. use case for "Edit Document" - might have a step called "Modifies Text" which might be a use case by itself.

Extension

• Sort of an interruption to to the Main use case.
• For e.g. if the main use case is "Check Balance" and if the balance > 5000$, the "Enrol as privilege customer" use case can kick in.
• Note that the main use case has no control over the special use case.

Use Case Diagrams

• Is a summary of the functionality of the whole system.
• Gives an overview of the relationships between all the actors and all the use cases.
• Not meant to record details of use cases - for that text is best, but rather as a sort of visual guide to the various use cases in the system.