Requirements Use Cases Software Lifecycle Activities Software - - PDF document

SLIDE 1

CSI3372 1

Requirements Use Cases

Eunjee Song Use Cases-1

Eunjee Song Computer Science Department Baylor University

Requirements Engineering

 Software Lifecycle Activities

System Engineering Requirements Analysis Software Design Implementation Eunjee Song Use Cases-2 System Engineering Testing Deployment Evolution

Requirements Use Cases

 A use case is the specification of a set of

actions performed by a system, which yields an observable result that is, typically, of value for one or more actors or

• ther stakeholders of the system

UML

Eunjee Song Use Cases-3

• ther stakeholders of the system – UML

Specification

What is use case modeling?

 use case model: a view of a system

that emphasizes the behavior as it appears to outside users. A use case model partitions system functionality

Eunjee Song Use Cases-4

p y y into transactions (‘use cases’) that are meaningful to users (‘actors’).

Use Cases in UML 2.0

 Use cases are associated with subjects

 A subject can be a system, a subsystem in a

system, or a class

 A use case describes interactions between

Eunjee Song Use Cases-5

A use case describes interactions between users (clients) and a subject

 At the requirements level the subject is the

system under development

Use Case Modeling: Core Elements

Construct Description Syntax

use case A sequence of actions, including variants, that a system (or other entity) can perform, interacting with actors of the system. actor A role played by an entity that interacts with the subject (e.g.,

UseCaseName

Eunjee Song Use Cases-6

interacts with the subject (e.g., system, subsystem, class). System/sub ject boundary Represents the boundary between the subject and the actors who interact with the subject.

ActorName

SLIDE 2

CSI3372 2

Depicting actors

Eunjee Song Use Cases-7 Payment Authorization Service

Use Case Diagram

NextGen POS Cashier actor communication system boundary Payment Authorization Service «actor» Tax Calculator alternate notation for a computer system actor Customer Process Sale Handle Returns

Eunjee Song Use Cases-8

Manage Users

. . .

System Administrator use case «actor» Accounting System «actor» HR System Cash In «actor» Sales Activity System Manage Security Analyze Activity Manager

Use Cases as requirements

 Use cases can be used to capture functional

requirements

 System attributes associated with a system

• peration can be documented in a use case

Eunjee Song Use Cases-9

 Not all requirements can be captured by use

cases

 System attributes that span use cases are

documented as supplementary requirements

Simple Use Case example

System Response

• 2. If customer is authenticated,

then request rental items

• 4. Display calculated price.

Actor Inputs 1. Customer submits identification information 3. Customer submits items to be rented

Eunjee Song Use Cases-10

• 6. Inform customer that

payments is authorized 5. Customer pays.

Actor types

 Primary: actor whose goal is

accomplished by the use case

 Supporting: actor that provides services

to the system

Eunjee Song Use Cases-11

y

 E.g., authorization service

 Offstage: an actor that has an interest in

the use case but is not primary or supporting

 E.g., regulating agency

Use Case instance (scenario)

 A scenario is a particular sequence of

actions in a use case.

 A use case is a related set of scenarios that yields

an observable result of value to a particular actor

A i t i ti f

Eunjee Song Use Cases-12

 A use case instance is an execution of a

scenario.

 Often use case instance and scenario are used

synonymously in informal discussions.

SLIDE 3

CSI3372 3

Levels of rigor

 Brief: One paragraph summaries of

functionality

 Casual: Multiple paragraphs that cover

multiple scenarios

Eunjee Song Use Cases-13

multiple scenarios

 Fully-dressed (Detailed): Structured,

detailed description of scenarios

Essential vs. Concrete Use Cases

 Essential Use Cases describe functionality

in implementation independent terms

 Requirements level use cases must be essential

 Concrete Use Cases describe external

Eunjee Song Use Cases-14

 Concrete Use Cases describe external

functionality in system dependent terms

 Use cases can be used during design to

document externally observable behavior of subsystems

Requirements Use Case template

Use Case Number: EU-xxxx : Indicates an essential use case, i.e., a use case that describes activity in system independent terms Use Case Name: Enter name of Use Case. Overview: Describe the purpose of the Use Case and give a brief description. Type: Enter Use Case priority (primary, secondary, optional) Actors: List all actors that participate in this Use Case. Indicate the actor that initiates the use case by placing “initiator” in brackets after the actor name. Also, indicate primary actors by placing “primary” in Eunjee Song Use Cases-15 f , p y y p g p y brackets after actor name. Properties: Performance: Security: Other:

Analysis Use Case template – cont’d

Pre condition: Enter the condition that must be true when the main flow is initiated. This should reference the conceptual model. Flow: Main Flow: Steps should be numbered. Subflows: Break down of main flow steps

Eunjee Song Use Cases-16

Alternate Flows: Include the post condition for each alternate flow if different from the main flow. Post Condition: Enter the condition that must be true when the main flow is completed. This should reference the conceptual model. Include the following information in this section: Cross References: References to other Use Cases or textual requirements that relate to this Use Case.

Goals and Use Cases

 Interactions usually take place to satisfy

system goals.

 Identifying goals is important because it can

lead to consideration of more effective

Eunjee Song Use Cases-17

lead to consideration of more effective alternatives.

 For each interaction ask “why?” - the answer

should lead to a system goal.

Determining Use Case scope

 A use case should describe end-to-end

functionality

 Should describe a task carried in response to an

event generated by an actor that produces a

Eunjee Song Use Cases-18

g y result of value to a subset of its actors and leaves the system in a stable state (one in which it is not waiting for a restricted set of inputs)

SLIDE 4

CSI3372 4

Identifying Use Cases and Actors

 Approaches to identifying use cases

 Actor-first: Identify actors first and consider the

ways they interact with the system

 Operation-first: Identify system-level operations

Eunjee Song Use Cases-19

p y y p and then identify actors that interact with

• perations

 Event-first: Identify external events and develop

use cases that handle the events

Developing Use Cases

 Scope system and identify primary actors

that interact with the system

 Determine goals of primary actors (can be

documented in an Actor-Goal list)

Eunjee Song Use Cases-20

)

 For each actor, consider the ways that the

actor typically interacts with the system to accomplish goals

 Consider exceptional behaviors

Use Case Exercise 1

University library system requirements Books and journals – the library contains books and journals. It may have several copies of a given book. Some of the books are for short term loans only. All other books may be borrowed by any library member for three weeks. Only members of staff may borrow journals. Members of the library can normally borrow up to six items at a time, but members

• f staff can borrow up to 12 items at a time. New books and journals

arrive regularly, and old ones are sometimes disposed of. The current year’s journals are sent away to be bound into volumes at the end of

Eunjee Song

each year. Borrowing – it is essential that the system keeps track of when books and journals are borrowed and returned. The new system should also produce reminders when a book is overdue. There may in future be a requirement for uses to be able to extend the loan of a book if it is not reserved. Browsing – this system should allow users to search for a book on a particular topic, by a particular author, etc., to check whether a copy of the book is available for loan and, if not ,to reserve the book. Anybody can browse in the library.

• P. Stevens, R. Pooley. Using UML: Software Engineering with Objects and Components. Addison-Wesley, 2000.

Use Cases-21 Borrow journal Book Borrower Borrow copy of book Journal Borrower Reserve book Return journal

Use Case Exercise 1 – Use Case Diagram of University Library System

Eunjee Song Borrow copy of book Return copy of book Extend loan Browser Librarian Browse Update catalog Use Cases-22

Borrow copy of book

A BookBorrower presents a book The system checks that the

Use Case Exercise 2 – Use Cases

 Construct an essential use case that represents

borrowing a copy of book from the university library in a brief level rigor.

Eunjee Song

A BookBorrower presents a book. The system checks that the potential borrower is a member of the library, and that s/he does not already have a maximum permitted number of books on

• loan. This maximum is six unless the member is a staff member

in which case it is twelve. If both checks succeed, this system records that this library member has this copy of the book on loan.

Use Cases-23

Use Case Exercise 3 - Use Cases

 Construct essential use cases that represent

returning a copy of book to the university library in each of the following three levels rigor:

 Brief

Eunjee Song Use Cases-24

 Casual  Fully-dressed

SLIDE 5

CSI3372 5

Use Case Modeling tips



Writing essential use cases: Focus on intent

 Keep user interface terms out  Ask “what is the goal?” 

Write “black-box” use cases

 Do not describe internal operations (e.g., storing to a

data base)



Focus only on interactions between system and actors

Eunjee Song Use Cases-25 

Focus only on interactions between system and actors

 Ignore interactions between actors 

Focus on text description

 Use diagrams for presentation purposes only 

A use case diagram should

 contain only use cases at the same level of abstraction  include only required actors

How do I know I have a good use case?

 Use case should describe an activity that

yields an observable result of value to an actor.

 A use case can describe an elementary

Eunjee Song Use Cases-26

business process (EBP): a sequence of tasks performed to handle a business event

 Use cases are typically not single steps or

single low-level actions.

Good use cases...… are

 Text  No GUI  No data formats

3 9 t i i i

Eunjee Song Use Cases-27

 3 - 9 steps in main scenario  Easy to read  At user’s goal level  A record of decisions made

Good use cases...… aren’t

 UML use case diagrams  describing the GUI  describing data formats

lti l i i

Eunjee Song Use Cases-28

 multiple-page main scenario  complicated to read  at program-feature level  a tutorial on the domain

Use Case role in development

 Functional requirements are primarily

recorded in essential use cases

 The scope of an iteration is usually

expressed in terms of use case scenarios

Eunjee Song Use Cases-29

covered

 Use case realizations drive the design

 Use cases realized as collaborating objects in

designs

The benefits of basing software development on use cases

 They can help to define the scope of the system  They are often used to plan the development

process

 They can be used to both develop and validate

the requirements

Eunjee Song Use Cases-30

the requirements

 They can form the basis for the definition of test

cases

 They can be used to structure user manuals  They can be used during requirements to

prototype user interfaces and during design to design user interfaces

SLIDE 6

CSI3372 6



User interface



• ur task is to build the underlying system providing functionality which

will be invoked through the user interface.



separation between user interface and underlying system.



Beware of making diagrams very complex



A diagram too complex to draw by hand is probably also it too complex to think out clearly.



Split into multiple diagrams; use cases at high level of abstraction.

Some Useful Tips

Eunjee Song 

Split into multiple diagrams; use cases at high level of abstraction.



Update catalog use case: Includes all the librarian’s adding and removal

• f books, sending away of journals etc. When this functionality is

considered in detail we may want to separate these out into multiple use cases.



Short descriptions of use cases



Do not invent requirements!



Can be useful to make a list of questions and possibilities with each use case, for discussion with the customer.

Use cases must not be seen as a panacea

 The use cases must be validated  There are some aspects of development that are

not covered by use case analysis.

 Non-functional requirements are often not covered Eunjee Song Use Cases-32  Non functional requirements are often not covered  Functionality that is not triggered by actors is not covered

 E.g., auditing transactions in a banking

system

 Do not write use cases in terms of how a system

works currently!

Essence of Software Development – Again!

Requirements Statement validatio ver ess

• ndence

Eunjee Song Software Processes - 33

Design Implementation

• n

rification correctn correspo

Evolution of Use Cases

 Inception

 Most interesting and complex or risky use cases written

in brief format

 10-20% of core complex functions rewritten in fully-

dressed format

 Elaboration

Eunjee Song Use Cases-34

 Elaboration

 In each iteration, use cases are prioritized and high

priority use cases are developed in fully-dressed format

 80-90% completed by end of elaboration

 Construction

 Remaining (minor) use cases are developed

Relating Use Cases

 Specializing/generalizing use cases  Including use cases  Extending use cases

Eunjee Song Use Cases-35 C o n s t r u c t D e s c r ip t io n S y n t a x a s s o c ia t io n T h e p a r tic ip a tio n o f a n a c to r in a u s e c a s e . i.e ., in s ta n c e o f a n a c to r a n d in s ta n c e s o f a u s e c a s e c o m m u n ic a te w ith e a c h o th e r . g e n e r a liz a tio n A ta x o n o m ic r e la tio n s h ip b e tw e e n a m o r e g e n e r a l u s e c a s e a n d a m o r e s p e c ific u s e c a s e . e x t e n d A r e la tio n s h ip fr o m a n e x te n s io n u s e c a s e to a b a s e u s e c a s e , s p e c ify in g h o w th e b e h a v io r fo r th e e x te n s io n u s e c a s e a u g m e n ts ( s u b je c t to

Use Case Modeling: Core Relationships

<<extend>>

Eunjee Song Use Cases-36 u s e c a s e a u g m e n ts ( s u b je c t to c o n d itio n s in th e e x te n s io n ) th e b e h a v io r d e fin e d fo r th e b a s e u s e c a s e . T h e b a s e u s e c a s e d o e s n o t d e p e n d o n th e e x te n s io n u s e c a s e . C o m p a r e : in c lu d e . in c lu d e a r e la tio n s h ip fr o m a b a s e u s e c a s e to a n in c lu s io n u s e c a s e , s p e c ify in g h o w th e b e h a v io r fo r th e b a s e u s e c a s e c o n ta in s th e b e h a v io r d e fin e d fo r th e in c lu s io n u s e c a s e . T h e b a s e u s e c a s e d e p e n d s o n th e in c lu s io n u s e c a s e . C o m p a r e : e x te n d .

<<extend>> <<include>>

SLIDE 7

CSI3372 7

Use Case Relationships

Order Product Supply Arrange «include» «include» «include» Payment Customer Data

Eunjee Song Use Cases-37

• Fig. 3-54, UML Notation Guide

additional requests :

Request Catalog «extend»

Extension points after creation of the order

Place Order

1 * the salesperson asks for the catalog

Including Use Cases

 A use case can include another use case at a

specified location.

 Used to avoid writing the same flow of events

across a number of use cases.

Eunjee Song Use Cases-38

 The included use case must not be a stand-alone

use case.

Extending Use Cases

 A use case can extend a base use case by

incorporating additional behavior at specified locations of the base use case.

 The base use case can act as a stand-alone use case.  The base use case can only be extended at specified points

called extension points. Of f

Eunjee Song Use Cases-39  Often used to separate optional behavior from mandatory

behavior.

 Also used to model a separate flow that is executed under

certain conditions.

Example: Online HR System

Online HR System

Locate Employees Update Employee Profile Manager

Eunjee Song Use Cases-40

Update Benefits Access Travel System Access Pay Records Employee Healthcare Plan System {if currentMonth = Oct.} {readOnly} Insurance Plan System

Online HR System: Use Case relationships

Update Medical Plan Update Dental Plan

Update Benefits

______________ E i i Update Insurance Plan <<include>> <<include>> <<include>> Eunjee Song Use Cases-41 Extension points benefit options: after required enrollments Employee Elect Reimbursement for Healthcare Elect Stock Purchase <<extend>> employee requests stock purchase option <<extend>> employee requests reimbursement option extension condition extension point name and location

Online HR System: Update Benefits Use Case

Actors: employee, healthcare plan system, insurance plan system Precondition:

• Employee has logged on to the system and selected ‘update benefits’
• ption

Basic course 1.

System displays employee account.

2.

System asks employee to select medical plan type; include Update Medical Plan

Eunjee Song Use Cases-42

Medical Plan.

3.

System asks employee to select dental plan type; include Update Dental Plan.

4.

…

5.

…

6.

…

7.

System asks user to select benefits options: benefit options

• 7a. Reimbursement option selected: Elect Reimbursement for Healthcare
• 7b. Stock option selected: Elect Stock Purchase

SLIDE 8

CSI3372 8

Specializing Use Cases

 Generalizing/specializing use cases

 A specialized use case inherits the behavior

(sequences of actions) of its parent(s).

 A specialized use case can override some of the

Eunjee Song Use Cases-43

p behavior of its parent(s). It can also add to the behavior.

 A specialized use case can be used anywhere the

general use case is expected.