Use Case Modeling Techniques

Use Cases

• Interaction between a user and a system
• A complete and meaningful use
• Focus on value – how the system will be used to satisfy a specific user goal
• Observable and testable functionality – “black box” view of the system
• The first system of functional decomposition
• All use cases = {all things the system must do}
• Understand the big picture

Use-Case Modeling Phases

Three phases of requirements analysis:
1. Model the user roles – detailed actor descriptions

•  Identify user goals for system interaction

2. Model (specify) requirements as use cases

• Use case diagrams – for context and reference
• Use case descriptions

3. Model use-case realizations

• An interaction of objects that realize the requirements
• Class diagrams and object interaction diagrams
• (Also known as robustness analysis, use case analysis, task modeling, or scripting)

Use case diagram

A use case diagram is a graphical depiction of a user’s possible interactions with a system. A use case diagram shows various use cases and different types of users the system has and will often be accompanied by other types of diagrams as well. The use cases are represented by either circles or ellipses. The actors are often shown as stick figures.

Application

While a use case itself might drill into a lot of detail about every possibility, a use-case diagram can help provide a higher-level view of the system. It has been said before that “Use case diagrams are the blueprints for your system”.

Due to their simplistic nature, use case diagrams can be a good communication tool for stakeholders. The drawings attempt to mimic the real world and provide a view for the stakeholder to understand how the system is going to be designed. Siau and Lee conducted research to determine if there was a valid situation for use case diagrams at all or if they were unnecessary. What was found was that the use case diagrams conveyed the intent of the system in a more simplified manner to stakeholders and that they were “interpreted more completely than class diagrams”.

Use Case Descriptions

For each use case describe functional steps in sufficient detail to …

• Enable (or represent) requirement specification
• Begin early design work
• Achieve stakeholder and user understanding and approval

The details …

• Name and description
• Actors
• Primary flow of events (as related stories)
• Secondary alternative and/or exception flow of events
• System preconditions
• System post conditions
• Supplemental information – non-functional requirements

“Why Use Cases at All?”

• A good compromise – use cases are semi-formal, structured, but understandable stories (people like stories)
• Use cases add value to analysis
  -At first as a succinct outline of mainline features and capabilities (get your head around the functionality)
  -Later a basis for innovation, extension, revision of requirements
• Address exceptions – a large source of system complexity
• Start functional decomposition that transitions to requirement specifications and early design
• Good basis for pursuing related project information – estimates, plans, user interface design, software design, testing