TK2023 Object-Oriented Software Engineering

CHAPTER 4REQUIREMENTS AND USE CASES

REQUIREMENTS

Requirements are capabilities and conditions to which the system must conform.

A prime challenge of requirements work is to find, communicate, and remember (record) what is really needed, in a form that can be understood by the client and development team members.

UP promotes a systematic approach to finding, documenting, organizing, and tracking the changing requirements of a system.

THE REQUIREMENTS DISCIPLINE IN UP

Iterations

SampleUP Disciplines

Business Modeling

Requirements

Design

Implementation

Test

Deployment

Configuration & ChangeManagement

Project Management

Environment

Requirements

UP categorizes requirements according to the FURPS+ model: Functional - features, capabilities, securities Usability - human factors, help, documentation Reliability - frequency of failure, recoverability,

predictability Performance - response times, throughput,

accuracy, availability, resource usage Supportability - adaptability, maintainability,

internationalization, configurability

TYPES OF REQUIREMENTS

Ancillary and sub-factors, such as Implementation - resource limitations, languages and

tools, hardware, … Interface - constraints imposed by interfacing with

external systems Operations - system management in its operational

setting Packaging Legal - licensing, etc

Requirements are sometimes broadly categorized as functional (behavioural) and non-functional (everything else).

INTRODUCTION TO USE CASES Customers and end users have goals and want

computer systems to help meet them. Informally, use cases are stories of using a system

to meet goals. Example (brief format):

Process Sale: A customer arrives at a checkout with items to purchase. The cashier uses the POS system to record each purchased item. The system presents a running total and line-item details. The cashier enters payment information, which the system validates and records. The system updates inventory. The system produces a receipt. The customer receives the receipt from the cashier and then leaves with the items.

The essence of use cases is the discovering and recording of functional requirements through writing stories of using a system to help fulfill various stakeholder goals.

The idea of use cases to describe functional requirements was introduced by Ivar Jacobson in 1986.

ACTOR

An actor is an external entity which interacts with the SuD (System under Discussion) to achieve a desired goal. It can be a person (identified by its role), computer system or organization.

Actors are basically users of the SuD. For example, cashier.

SCENARIO

A scenario is a specific sequence of actions and interactions between actors and the SuD. It is also called a user story or a use case instance.

Example,Use case: Process Sale

Possible scenarios: Successfully purchasing items with cash Failure to purchase items because credit card is

rejected by the system.

In other words, a use case is a collection of related success and failure scenarios that describe actors using a system to support a goal.

ANOTHER EXAMPLE (CASUAL FORMAT)Handle Returns

Main Success Scenario:

A customer arrives at a checkout with items to return. The cashier uses the POS system to record each returned item …

Alternate Scenarios: If the credit authorization is rejected, inform the

customer and ask for an alternate payment method.

If the item identifier is not found in the system, notify the Cashier and suggest manual entry of the identifier code.

If the system detects failure to communicate with the external tax calculator system, …

…

ANOTHER FORMAT (TWO-COLUMN FORMAT)Process Sale

Main Success Scenario: Actor Action (or Intention) System Responsibility

1. Customer arrives at a POS checkout with goods

2. Cashier starts a new sale

3. Cashier enters item identifier

Cashier repeats 3-4 until indicates done

6. Cashier tells Customer the total, and asks for payment.

7. Customer pays

4. Records each sale line item and presents item description and running total.

5. System presents total with taxes calculated

8. Handles payment

BLACK-BOX USE CASES

Black-box use cases are use cases that do not describe the internal workings of the SuD, its components or design.

They specify what the SuD must do (the functional requirements) without deciding how it will do it (the design).

Black-box use cases should be written during requirements analysis.

Black-box style Not

The system records the sale. The system writes the sale to a database. …

The system generates an SQL INSERT statement for the sale …

USE CASE FORMATS

The format used for writing a use case depends on the current need. brief

Terse one-paragraph summary, usually of the main success scenario.

casualInformal paragraph format. Multiple paragraphs that cover various scenarios.

fully dressedThe most elaborate format. All steps and variations are written in detail, and there are supporting sections, such as preconditions and success guarantees. EXAMPLE

GOAL LEVELS

Use cases can be expressed at different levels, depending on the system boundary, actors and goals.

Generally, there are 3 goal levels: Summary Level User Level Subfunction Level

SUMMARY GOAL LEVEL

Example (Handle a Claim):1. Customer reports a claim (paper, phone or fax) to Clerk.

2. Clerk finds the policy, registers loss in System, and assigns an Adjuster.

3. Adjuster investigates the claim and updates the claim with additional information.

4. Adjuster enters progress notes over time.

5. Adjuster corrects entries and sets monies aside over time.

…

USER GOAL LEVEL

Example:The manager requests for a hardcopy of a certain report from his personal assistant. The personal assistant turns to his computer to accomplish a goal i.e. to print the document. He works with the computer for a while and finally accomplishes the goal. He then passes the hardcopy to the manager.

SUBFUNCTION LEVEL

Subfunction-level goals are normally referred to by user-level goals.

Examples: Open a file Find a product Find a customer Log into system

Actors have goals (or needs) and use computer applications to help satisfy them.

A user goal-level use case is one that serves to fulfill a goal of a user of the SuD.

When identifying such use cases, one should first ask

Example:Goal: capture or process a saleUse case: process sale

What are the goals of the primary actors?

USER GOAL-LEVEL USE CASES

Some guidelines in identifying user goal-level use cases: A use case should yield an observable result of

value to a particular actor (refer Boss Test). Is “Log In” a use case at the user goal level?

The use case should not be just a single small step. The main success scenario is probably 5 to 10 steps.

The use case can be executed in a single session (probably between a few minutes to an hour). It should not take days and multiple sessions.

USE CASE EXAMPLE: ATM Some user goal-level use cases:

Start Up ATM Shut Down ATM Deposit Fund Withdraw Fund Transfer Fund Check Account Balance

PROCEDURE FOR DEFINING USE CASES The basic procedure:

Choose the system boundary Identify the primary actors Identify user goals Define the use cases

STEP 1: CHOOSE SYSTEM BOUNDARY Can be done by determining what is outside

the boundary of the SuD i.e what are the primary and supporting actors? Primary actors have user goals fulfilled through

using the SuD. Supporting actors provide services to the SuD.

For the case study, the POS system itself is the SuD. Cashiers, payment authorization service, inventory control system, etc are outside the system boundary.

STEPS 2 & 3: IDENTIFY PRIMARY ACTORS AND GOALS There are three types of actors:

Primary actor has user goals fulfilled through services of the SuD Example: cashier

Supporting actor provides a service to the SuD Example: printer subsystem

Offstage actor has an interest in the behaviour of the use case but is not

primary or supporting Example: customer

Note that the SuD itself is an actor (when it calls upon the services of other systems).

Recall that primary actors can be other than persons.

Record the primary actors and their user goals in an actor-goal list. For example,

Actors Goals

Cashier Process sale

Process rentals

Process returns

…

System Administrator Add users

Modify users

…

Questions that can help in brainstorming actors and goals: Who starts and stops the system? Who does user and security management? Who does system administration? Is there a monitoring process that restarts the

system if it fails? Who evaluates system activity or performance? … (refer textbook p 83)

The identification of primary actors and user goals depends on the system boundary. Why is Customer not the primary actor in the use case

Process Sale?

Cashier

POS System

Goal: Process sales

Checkout Service

Sales ActivitySystem

Goal: Analyze salesand performance data

Customer

Goal: Buy items

Sales TaxAgency

Goal: Collecttaxes on sales

Enterprise Selling Things

STEP 4: DEFINE USE CASES In general, define one use case for each user

goal. A common exception is to combine CRUD (Create, Retrieve, Update, Delete) separate goals into one CRUD use case (Manage <X>).

Example: Define “Manage Users” use case to satisfy the goals “create user”, “delete user”, “edit user”, etc.

Name the use case similar to the user goal. Make sure use case names start with a verb.

Examples: Process Sale, Handle Returns, Start System

USE CASE LEVEL FOR REQUIREMENTS ANALYSIS What is a useful level to express use cases

for application requirements analysis?

For requirements analysis for a computer application, focus on use cases at the user goal level.

WRITING USE CASES

Use cases written at the start of development are always imperfect and incomplete.

Writing use cases is not a “waterfall” process. There needs to be an ongoing personal communication between the developers and those who understand the domain (domain experts) and can make requirement decisions.

Use cases are said to be written in an essential style if the narrative is expressed at the level of user's intentions and system's responsibilities rather than their concrete actions.Compare the following actor's action

2. Cashier enters ID and passwordwith

2. Cashier identifies self

Use cases written in an essential style are free of technology and mechanism details, especially those related to the UI (User Interface). They focus on the real user intent.

If user interface decisions are embedded in the text of a use case then that use case is said to be written in a concrete style.

Example (Concrete form/Not in essential form):

…

1. Administrator enters ID and password in dialog box

(see Picture 3).

2. System authenticates Administrator

3. System displays the “edit users” window (see Picture 4).

…

Example (Written in essential/abstract form):

…

1. Administrator identifies self

2. System authenticates identity

…

Use cases should be written in an essential style during early requirements work. Why?

Use cases written in a concrete style are useful later in design work.

USE CASE DIAGRAMS The UML provides a notation called the use case

diagram to illustrate use cases, actors and the relationships between them.

NextGen POS

Manage Users

. . .

Cashier

SystemAdministrator

actor

use case

communicationsystem boundary

PaymentAuthorization

Service

«actor»Tax Calculator

«actor»Accounting

System

alternatenotation for a computer system actor

«actor»HR System

Cash In

«actor»Sales Activity

System

Manage Security

Analyze Activity

Customer

Manager

Process Sale

Handle Returns

REMEMBER THIS…

A use case diagram makes a good context diagram. It is a communication tool that summarizes the behaviour of a system and its actors.

Use case diagrams and use case relationships are secondary in use case work. Focus on writing use cases.

Actors can be represented using the following notation

or as below

Inventory Control System

«actor»

Inventory Control System

stereotype

Actors are associated with use cases by solid lines. It is optional to put an arrowhead at the end of the

line to indicate the direction of the initial invocation or to indicate the primary actor in the use case.

USE CASES ARE NOT OBJECT-ORIENTED It needs to be understood that there is

nothing object-oriented about use cases. They are a requirements analysis tool that

can also be applied to non-object-oriented projects.

USE CASES WITHIN THE UP Use cases are very important in the UP. In

fact, UP encourages use-case driven development. Requirements are primarily recorded in use

cases; other requirement techniques are secondary.

Use cases play an important role in iterative planning.

Use-case realizations drive the design. Use cases often influence the organization of user

manuals.

USE CASES IN THE INCEPTION PHASE User goal-level use cases are identified in this

phase. Most of the interesting, complex or risky use cases are written in brief format. Through this exercise, the team should have a high-level picture of the system's functionalities.

10% to 20% of the use cases that represent core complex functions or risky ones are rewritten in fully dressed format. This is done to better comprehend the magnitude and complexities of the project.

inc. construction transitionelaboration

USE CASES IN THE ELABORATION PHASE In the elaboration phase, risky, high-value,

and architecturally significant parts of the system are incrementally built. Also, majority of the requirements are identified and clarified in this phase.

Use cases are prioritized and each iteration focuses on a subset of the most important ones.

inc. construction transitionelaboration

The team's understanding of the requirements increases after each iteration through feedback from previous iterations. Requirements are iteratively and adaptively refined and becomes stable gradually.

More and more use cases are written, and rewritten, in fully dressed format. By the end of the elaboration phase, 80% - 90% of the use cases should have been written in detail.

USE CASES IN THE CONSTRUCTION PHASE The construction phase focuses on completing the

system, once the risky and core unstable issues have settled down in elaboration.

There will be some minor use case writing but much less so than in the elaboration phase.

Majority of core functional and non-functional requirements should have iteratively and adaptively stabilized.

inc. construction transitionelaboration

YOUR FIRST ASSIGNMENT Suppose you are involved in a project to develop an online cinema

reservation system. Identify three user goal-level use cases. Draw a use case diagram

showing those use cases and the actors involved. Determine which of those use cases you think is the most complex

one and do the following tasks: Write the use case in the casual format with at least two alternate

paths. Write a happy path for that use case in the two-column format. Write one success scenario and one failure scenario for that use

case. The use cases you write must be black-box use cases and

written in essential style. Your handwritten assignment must be submitted by 10:00 am, 1

February 2010 (Monday).