1

Modeling System Requirements with Use Cases

2

Why Do We Need Use Cases?

• Primary challenge in a system design process – ability to elicit correct and necessary system

requirements from stakeholders– specify requirements in a manner

understandable to users so they can be verified and validated.

– SDLC models understood by designers not by users.– Leads to scope creep, schedule creep, cost overruns.

3

IS Development Project Track Record

Source: The Standish Group International, Inc., “Chaos: A Recipe for Success”

canceled before

completion

Over budget, late, or without needed features

4

Introduction

Use-case modeling – the process of modeling a system’s functions in terms of business events, who initiated the events, and how the system responds to those events.– roots in object-oriented modeling (question1 )– Gained popularity in non-object development

environments because of its usefulness in communicating with users

– Compliments traditional modeling tools• Focuses on Users and their tasks• Logical model

5

Role of Use Cases

• Describes how system reacts to an event that triggers the system– Trigger – event that causes the use case to

be executed (opening the app, pushing a button)

– Event-driven modeling • All possible system responses are

documented

6

Use Case

• Process– Gather requirements from users– Prepare Use-Case Diagram– Prepare Use-Case Narratives (describes what

happens in each step in the app)• Deliverables:

– Use-Case Diagram– Use-Case Narratives

7

Advantages (question 2)• Tool for capturing and tracking functional requirements• System scope decomposition• Easily understood user communication of

functionality(primary advantage)• Incremental and iterative development.• Aids estimating project scope• Provides testing baseline (test plans and test cases)• Provides documentation baseline (user and system)• Aids in data object or entity identification & db access• Provides functional specifications for user and system

interface design

8

DefinitionsUse-case diagram – a diagram that depicts the

interactions between the system and external systems and users. – It graphically describes who will use the system and in what

ways the user expects to interact with the system.

Use-case narrative – a textual description of the business even and how the user will interact with the system to accomplish the task.

Use case – a behaviorally related sequence of steps (a scenario), both automated and manual, for the purpose of completing a single business task.– Description of system functions from the perspective of external

users in terminology they understand.

9

Sample Use-Case Diagram

10Use-Case Diagram for a Hoosier Burger’s System

11

Basic Use-Case Symbols

Use case – subset of the overall system functionality– Represented graphically by a horizontal

ellipse with the name of the use case appearing above, below, or inside the ellipse.

– Describes ONE and ONLY ONE function– Associated with ONE and ONLY ONE role

that a user can play

12

Basic Use Case Symbols

Actor – anything that needs to interact with the system to exchange information. – Could be a human, an organization, another

information system, an external device, or even time.

Temporal event – a system event triggered by time.– The actor is time.

13

Four Types of Actors

• Primary business actors• Primary system actors• External server actor• External receiver actor• Remember an Actor is a ROLE not an

individual– A given individual can have multiple roles– Multiple individuals can have the same role

14

Relationships

• Association – relationship between an actor and a use case – only one we will use

• Others – Extend – relationship between use cases– Includes – relationship between use cases– Depends-on – relationship between use

cases

15

Association RelationshipDefinition and modeling rules– Modeled as a solid line connecting the actor and the

use case.– Association with an arrowhead touching the use case

indicates that the use case was initiated by the actor.– Association lacking arrowhead indicates a receiver

actor.– Associations may be bidirectional or unidirectional.

16

Objectives of Use-Case Modeling

• Elicit and analyze enough requirements & information to prepare a model that:– Communicates what is required from a user

perspective.– Is free of specific details about how the

system will be built or implemented.

17

Use-Case Technique Steps

• Steps1.Identify business actors.

2.Identify business use cases.

3.Construct use-case model diagram.

4.Documents business requirements use-case narratives

18

Identifying Business Actors

• Ask the following questions:– Who or what provides inputs to the system– Who or what receives output from the system– Are there interfaces with other Information Systems– Are there automatically triggered events (temporal

events)– Who will maintain the information in the system

• Create an Actor Glossary

19

Sample Actor Glossary

20

Identifying Business Requirements Use Cases

• Identify and document critical or important use cases, often called essential use cases.

• Ask questions on next slide• Look at DFD (good match between them)• Summarize information in a Use Case

Glossary

21

Use Case Identification

• Ask the following questions:– What are the main tasks of the actor– What information does the actor need from

the system– Does the system need to inform the actor of

any changes or events that have occurred– Does the actor need to inform the system of

any changes or events that have occurred

22

Sample Use Case Glossary

23

Sample Use Case Glossary Continued

24

Sample Use Case Glossary Continued

25

Event Response List

• Prepare for your Use Case Diagram and Use Case Narrative by creating an Event Response list.– Actor– Event (or use case)– Trigger (typically an input)– Reponses (system responses)

• Sample on Moodle

26

Construct Use-Case Diagram

• Depicts Scope and Boundaries of system• Outside system boundaries – draw and

label primary actors• Inside system boundaries – draw and label

primary use cases• Show relationships between actors and

use cases and between the use cases

27

Guidelines for Use-CaseDiagram Construction

• Identify system’s boundaries – scope• List primary actors (stakeholders & users is

good place to start) – remember actors are ROLES

• List goals of primary actors – Functionality required of system – Tasks (update, read, create, delete)– Communication of external conditions to system– Extraction of information from system

• Identify major use cases• Use glossaries and event table to help you• Review (iterative process)

28

Sample Use Case Diagram

29

Create Use-Case Narratives

• Document first at high level to quickly obtain an understanding of the events and magnitude of the system.

• Then expand to a fully-documented business requirement narrative.– Include the use case’s typical course of

events and its alternate courses.

30

Sample Use-Case Narrative

31continued

Sample Expanded Use-Case Narrative

32continued

Sample Expanded Use-Case Narrative

33

Sample Expanded Use-Case Narrative

34

Guidelines for Writing Use Cases

• Focus on Flow of Events – critical to get it right (Event table should help)

• Write each step in form of Subject-Verb-Direct Object– The patient contacts the office regarding an

appointment• Identify initiator (trigger) of the action and

the receiver of the action

35

Guidelines continued

• Write each step from an independent observer perspective

• Write each step at same level of abstraction (try to accomplish equal amounts in each step)

• Sensible set of actions• KISS• Iterate until comfortable

36

Parts of a Use Case

• Think of each one as a ‘transaction’• Should have 4 parts

– Primary actor triggers (sends data or request)– System ensures request/data sent is valid– System processes request/data – may result

in a change to the internal state of system– System sends result of processing to an actor

(results may include data)

37

Expanding Use Case Narratives

• Choose major use case and expand it• Fill in details

– Identify all stakeholders– Identify all relationships

• Expand on the normal flow of events• Identify all alternate or exception flows• Confirm (typically with user)

38

Expanding Use Case Narratives

• Simplify– Decompose into smaller use cases– Combine or merge too simple or too small use

cases– Look for generic, common or general syntax– Look for ways to extend, include or generalize

use cases• Iterate

39

Extension of Use Cases

• Use the basic Use Case diagram and some of the Use Case narratives to build DFDs (that is where we will go next)

• Identify data required by each use case – use to build data models

• Refer to Use Cases and data models when doing form and report design and system navigation

40

Use Cases and Project Management

• Use-case model can drive the entire development effort.

• Project manager or systems analyst uses business requirements use cases to plan (estimate and schedule) the build cycles of the project.– Build cycles are scoped on the basis of the

importance of the use case and the time it takes to implement the use case.