Chapter Note

Chapter 8:

Understanding User Requirements

1

© Karl E. Wiegers

 Use Cases

 Use cases came from object-oriented world, extended for general system analysis and UI design.

• Use case describes a sequence of interactions between the software system and an external actor (scenario) to achieve a common goal/purpose.

• There can be multiple scenarios for a use-case • The names of the use cases are typically written in

the form of verb followed by an object.

2

3

(CTS)

Some Airline Use Cases

 Make a reservation.  Cancel a reservation.  Select seats.  Check frequent flyer mileage balance.  Find available flights for a given itinerary.  Print an itinerary.  Print a boarding pass.  Modify a reservation.  View flight details.

4

 Use Case Diagram provides high level visual representation of user requirements

5

Primary actor Initiates

Extend: Can be extended to another usecase

More example: ATM

6

Include: subtask relationship

7

uses = includes

8

Use Case Description

9

 Name: Enter the goal of the use case - preferably as a short, active verb phrase.

 Description: Describe the goal and context of this use case. This is usually an expanded version of what you entered in the “Title” field.

 Primary Actor: A person or a software/hardware system that interacts with your system to achieve the goal of this use case.

 Precondition: Describe the state the system is in before the first event in this use case.

 Postcondition: Describe the state the system is in after all the events in this use case have taken place.

 Main Success Scenario (Normal Flow) : As you can see, this field contains the example from our previous post - i.e. the flow of events from preconditions to postconditions, when nothing goes wrong

 Extensions (Alternative Flow & Exceptions) : Describe all the other scenarios for this use case - including exceptions and error cases.

 Includes: Describe subtasks to be performs.  The other fields are self-explanatory.

10

Activity Diagram to show the flows:

11

12

Use Case Example:

13

Another Example:

14

15

Use Case Description for an ATM Name: Withdraw Cash

Actor: Account Owner

Description: The Account Owner withdraws a specific amount of cash from a specified account.

Preconditions: 1. The Account Owner is logged in to the ATM.

2. The Account Owner has at least 1 account with a positive balance.

3. The ATM contains cash.

Postconditions: 1. The requested amount of cash has been dispensed.

2. The account balance is reduced by the withdrawn amount plus any fees.

3. The ATM cash balance is reduced by the withdrawn amount.

Priority: High

16

Normal Flow: 1. Account Owner selects Withdrawal action.

2. System displays user’s accounts.

3. Account Owner selects desired account.

4. System asks user to choose amount to withdraw from a list.

5. Account Owner chooses amount to withdraw.

6. System dispenses cash.

7. Account Owner removes cash from dispenser.

Alternative Flows: at step 4, actor can choose to enter a custom amount and join at step 6

Exceptions: amount is not a multiple of $20.00

amount exceeds $400

amount exceeds account balance

amount exceeds cash available in ATM

indicate the step number where the exception

could take place and how the system handles it 17

 Use case and BR

 Use Case and BRs are closed related.  Some BR constrain which roles can perform all

or part of the use case, e.g., certain people can perform specific flows (Admin vs, regular user)

• Conversely, from use cases, some BT maybe drawn

18

Identifying Use Cases

• Identify the actors first, then layout the business processes supported by the system and define the use cases for activities where actors and systems interact

E.g., purchase-a-ticket etc

• Create a specific scenario to illustrate each business process, then generalize the scenarios and then identify actors

e.g., assign_a_seat

19

 Using business process description, ask “what task must be performed to complete this process or convert input to specific output”

e.g., generate_profit_report

 Identify the external events to which the system must respond, then relate this

event to an actor e.g., sound-alarm

20

• Use CRUD analysis to identify data entities that require use cases to create, read, update, delete it. e.g., change_reservation,

cancel_reservation

• Examine the context diagram, and ask “what do each external entities want to

achieve with the help of the system?” e.g., order_a_book

21

Use Case Elicitation Work Products

22

Use-Case Traps to Avoid

 “Use cases” that aren’t about user goals.  Too many use cases.  Highly complex use cases.  Including “design details” in use-cases  Including “data definition” in use-cases  Use cases that users don’t understand.  Failing to consider alternative flows and exceptions.  Prematurely detailing low-priority use cases.  Undefined or inconsistent system boundary.

23

Validating Use Cases thru reviews Questions to ask.

 Is the goal (measurable value) of the use case clear?  Is it clear which actor benefits from the use case?  Do the preconditions and postconditions properly frame the

use case?  Could any common action sequences be split out?  Is the use case a standalone activity, which could be chained

with others?  Are all known exceptions documented?  Are the steps complete, correct, unambiguous, consistent,

verifiable, and feasible?

24

 Use Cases and Functional Requirements

 Use case takes actor’s viewpoint, shows external behavior and appearance

 Developers implement from system’s viewpoint, with internal behavior, algorithms, storage

 Use Case/SRS Options ◦ Use cases include functional requirements ◦ SRS document includes the write-up of use cases.

25

 User Stories

User Stories for Agile Development (V)

http://www.youtube.com/watch?v=NzSsE37opB0

26

 Use cases and User Stories

Use Case and User Stories (V)

http://www.youtube.com/watch?v=GoudHe5nxfk

END

27