TK2023 Object-Oriented Software Engineering

CHAPTER 4

REQUIREMENTS 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

Sample UP Disciplines

Business Modeling Design Implementation Test Deployment Configuration & Change Management Project Management Environment

Iterations

TYPES OF 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

 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

computer systems to help meet them.

and want Informally,

use cases

to meet goals.

are stories of using a system 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)

1.

2.

3.

Customer arrives at a POS checkout with goods Cashier starts a new sale Cashier enters item identifier

System Responsibility

Cashier repeats 3-4 until indicates done 6.

Cashier tells Customer the total, and asks for payment.

7.

Customer pays 4.

5.

8.

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

System presents total with taxes calculated 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

The system records the sale.

Not

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.

casual

Informal paragraph format. Multiple paragraphs that cover various scenarios.

fully dressed

The 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

  

USER GOAL-LEVEL USE CASES

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 What are the

goals

of the primary actors?

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

process sale

 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

Cashier System Administrator

Goals

Process sale Process rentals Process returns … 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

?

Enterprise Selling Things Checkout Service Sales Tax Agency POS System Goal:

Collect taxes on sales

Sales Activity System Cashier Customer Goal:

Buy items

Goal:

Analyze sales and performance data

Goal:

Process sales

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

). 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 Cashier enters ID and password with 2.

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. 2. 3. Administrator enters ID and password in dialog box (see Picture 3).

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

…

 Example (Written in essential/abstract form): … 1. 2. Administrator identifies self 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.

system boundary communication

NextGen POS Process Sale Customer

actor

Cashier Manager «actor» Sales Activity System Handle Returns Cash In Analyze Activity Payment Authorization Service «actor» Tax Calculator

alternate notation for a computer system actor

«actor» Accounting System «actor» HR System System Administrator Manage Security Manage Users . . .

use case

 REMEMBER THIS… Use case diagrams and use case relationships are secondary in use case work.

Focus on writing use cases.

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

 Actors can be represented using the following notation Inventory Control System or as below « 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

.

elaboration construction transition

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 .

elaboration

construction transition

 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 .

elaboration

construction

transition

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

alternate paths.

with at least two Write a happy path for that use case

in the two-column format

.

Write

one success scenario

use case.

and

one failure scenario

for that 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).