MODELING SYSTEM REQUIREMENTS

WITH USE CASES

Modeling System Requirements
with Use Cases
Describe
• the benefits of use-case modeling.
• actors and use cases.
• the relationships that can appear on a use-case model diagram.
• the steps for preparing a use-case model.
• how to construct a use-case model diagram.
• the various sections of a use-case narrative and be able to
prepare one.
• the purpose of the use-case ranking and priority matrix and the
use-case dependency diagram.
 Significance
The hardest single part of building a software system is deciding precisely
what to build. No other part of the conceptual work is a difficult as
establishing the detailed technical requirements, including all the
interfaces to people, to machines, and to other software systems. No
other work so cripples the resulting system if done wrong. No other
part is more difficult to rectify later. Fred Brooks
 An Introduction to Use-Case
Modeling
• One of the primary challenges in a system design
process: the ability
• to elicit the correct and necessary system
requirements from the stakeholders and
• specify them in a manner understandable to them so
those requirements can be verified and validated.
– Data and process models, prototypes, requirement
specifications.
– Understood by designers but not by users.
– Leads to scope creep, schedule creep, cost overruns.
IS Development Project Track Record

canceled Over budget,

before late, or without
completion needed features

Source: The Standish Group International, Inc., “Chaos: A Recipe for Success”
User-Centered Development and Use-
Case Modeling
User-centered development – a process of systems
development based on understanding the needs of the
stakeholders and the reasons why the system should be
developed.
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.
– Use-case modeling has roots in object-oriented modeling.
– Gained popularity in nonobject development environments
because of its usefulness in communicating with users.
– Compliments traditional modeling tools.
 Benefits of Use-Case Modeling
• Provides a tool for capturing functional requirements.
• Assists in decomposing system scope into more manageable pieces.
• Provides a means of communicating with users and other stakeholders
concerning system functionality in a language that is easily understood.
• Provides a means of identifying, assigning, tracking, controlling, and
management system development activities, especially incremental and
iterative development.
• Provides an aid in estimating project scope, effort, and schedule.
• Provides a baseline for testing in terms of defining test plans and test
cases.
• Provides a baseline for user help systems and manuals as well as system
development documentation.
• Provides a tool for requirements traceability.
• Provides a starting point for the identification of data objects or entities.
• Provides functional specifications for designing user and system
interfaces.
• Provides a means of defining database access requirements.
• Provides a framework for driving the system development project.
 System Concepts for Use-Case
Modeling
Use-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 event 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.
Sample Use-Case Model
Diagram
 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.
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.
 Four Types of Actors
• Primary business actor
– The stakeholder that primarily benefits from the execution
of the use case.
• e.g. the employee receiving the paycheck
• Primary system actor
– The stakeholder that directly interfaces with the system to
initiate or trigger the business or system event.
• e.g. the bank teller entering deposit information
• External server actor
– The stakeholder that responds to a request from the use case.
• e.g. the credit bureau authorizing a credit card charge
• External receiver actor
– The stakeholder that is not the primary actor but receives
something of value from the use case.
• e.g. the warehouse receiving a packing slip
 Use Case Association
Relationship
Association – a relationship between an actor and a use
case in which an interaction occurs between them.
– Association is 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.
 Use Case Extends Relationship
Extension use case – a use case consisting of steps
extracted from a more complex use case in order to
simplify the original case and thus extend its functionality.
– Relationship between the extension use case and the use case it
is extending is called an extends relationship.
– Represented as an arrowheaded line beginning at the extension
use case and point to the use case it is extending.
– Each extends relationship line is labeled “<<extends>>.”
 Use Case Uses Relationship
Abstract use case – a use case that reduces redundancy
among two or more other use cases by combining the
common steps found in those cases.
– An abstract case is available for use by any other use case that
requires its functionality.
– Relationship between the abstract use case and the use case that
uses it is called a
uses (or includes)
relationship.
– Depicted as an
arrowheaded line
beginning at the
original use case
and pointing to the
use case it is using.
– Uses relationship line is
labeled “<<uses>>.”
 Use Case Depends On
Relationship
Depends On – a use case relationship that specifies which
other use cases must be performed before the current use
case.
– Can help determine sequence in which use cases need to be
developed.
– Depicted as an
arrowheaded line
beginning at one use
case and pointing to
a use case it is
dependent on.
– Each depends on
relationship line is
labeled
“<<depends on>>.”
 Use Case Inheritance
Relationship
Inheritance – a use case relationship in which the common
behavior of two actors initiating the same use case is
extrapolated and assigned to a new abstract actor to reduce
redundancy.
– Other actors can inherit the interactions of the abstract actor.
– Depicted as an
arrowheaded line
beginning at one
actor and pointing
to the abstract
actor whose
interactions the
first actor inherits.
 The Process of Use-Case Modeling
• Objective: to elicit and analyze enough requirements
information to prepare a model.
– The model communicates what is required from a user
perspective.
– The model is free of specific details about how the system
will be built or implemented.
• To effectively estimate and schedule project, a
preliminary “system implementation assumptions”
may be needed.
Steps:
1. Identify business actors.
2. Identify business use cases.
3. Construct use-case model diagram.
4. Documents business requirements use-case narratives.
 Step 1: identify Business Actors
When looking for actors, ask the following
questions:
• Who or what provides inputs to the system?
• Who or what receives outputs from the system?
• Are interfaces required to other systems?
• Are there events that are automatically triggered at
a predetermined time?
• Who will maintain information in the system?
Sample List of Actors
 Step 2: Identify Business
Requirements Use Cases
• During requirements analysis, strive to identify and
document only the most critical, complex, and important
use cases, often called essential use cases.
When looking for use cases, ask the following questions:
• What are the main tasks of the actor?
• What information does the actor need form the system?
• What information does the actor provide to 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?
Sample Context Diagram
Sample Use-Case Glossary

continued
Sample Use-Case Glossary

continued
Sample Use-Case Glossary
Step 3: Construct Use-Case Model
Diagram
 Step 4: Document Business
Requirements Use-Case Narratives
• Use-Case Model Diagram documents 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.
Sample High-Level Version of a
Use-Case Narrative
Sample Expanded Version of a
Use-Case Narrative

continued
Sample Expanded Version of a
Use-Case Narrative (cont)

continued
Sample Expanded Version of a
Use-Case Narrative (cont)
 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.
• To determine importance of the use cases, will create:
– Use-case ranking and evaluation matrix
– Use-case dependency diagram
 Use-Case Ranking and Priority
Matrix
• In most projects, the most important use cases are
developed first.

Use-case ranking and priority matrix – a tool used to evaluate use

cases and determine their priority.

• Evaluates use cases on a scale of 1 to 5 against six criteria.

1. Significant impact on the architectural design.
2. Easy to implement but contains significant functionality.
3. Includes risky, time-critical, or complex functions.
4. Involves significant research or new or risky technology.
5. Includes primary business functions.
6. Will increase revenue or decrease costs.
Sample Use-Case Ranking and
Priority Matrix
Use-Case Dependency Diagram
Use-case dependency diagram – a graphical depiction of
the dependencies among use cases.

– Provides the following benefits:

• Graphical depiction of the system’s events and their states
enhances understanding of system functionality.
• Helps identify missing use cases.
• Helps facilitate project management by depicting which use
cases are more critical.
Sample Use-Case Dependency
Diagram
• UML
http://www.youtube.com/watch?v=2yoahl1H
f5U&feature=related
• MicroSoft Visio
• http://www.youtube.com/watch?v=gCMWCB
Ll7Q4&feature=related
• http://www.youtube.com/watch?v=xmDjmm
0btO8&feature=related
Dr Manolya Kavakli
Department of Computing
Macquarie University
Sydney, Australia

DATA AND PROCESS

MODELLING

Reading: Chapter 4
(7th Edition, Shelly)
 Chapter Objectives
• Describe data and process modeling concepts
and tools, including data flow diagrams, a data
dictionary, and process descriptions
• Describe the symbols used in data flow
diagrams and explain the rules for their use
• Draw data flow diagrams in a sequence, from
general to specific
• Explain how to level and balance a set of data
flow diagrams
39
 Chapter Objectives
• Describe how a data dictionary is used and
what it contains
• Use process description tools, including
structured English, decision tables, and
decision trees
• Describe the relationship between logical
and physical models

40
 Introduction
• Chapters 5 & 6 cover the logical model of a
proposed system and how to document the
system requirements
• Logical model
– shows what the system must do
• Physical model
– describes how the system will be constructed

41
 Overview of Data and Process Modeling
Tools
• Systems analysts use many graphical
techniques to describe an information system
• Data and process modeling involves three main
tools:
– data flow diagrams,
– data dictionary, and
– process descriptions
• A data flow diagram (DFD) uses various
symbols to show how the system transforms
input data into useful information
42
 Data Flow Diagrams
A data flow diagram (DFD)
• shows how data moves through an information system
• but does not show program logic or processing steps
A set of DFDs
• provides a logical model that
• shows what the system does,
• not how it does it

43
 Data Flow Diagrams
• DFD Symbols: Different symbol sets

44
 Data Flow Diagrams
• DFD Symbols
– Process symbol
• Receives input data and produces output that has a
different content, form, or both
• Contain the business logic, also called business
rules
• Referred to as a black box

45
Data Flow Diagrams
• DFD Symbols
– Data flow symbol
• Represents one or more data
items
• The symbol for a data flow is a
line with a single or double
arrowhead
– Impossible DFDs
– Spontaneous generation produces
output but has no input
– Black hole has input but no output
– Gray hole has both, but input is
not sufficient to create the output

46
 Data Flow Diagrams
• DFD Symbols
– Data store symbol
• Represent data that
the system stores
• The physical
characteristics of a
data store are
unimportant
because you are
concerned only
with a logical
model 47
Data Flow Diagrams
• DFD Symbols
– Entity Symbol
• Name of the entity appears
inside the symbol
• Shows External entitities that
provide data to the system
Also called Terminators:
• Since they are the data
origins or final destinations
• Source: entity supplying data
• Sink: entity that receives data
• Each entity must be
connected to a process by a
data flow 48
 Creating a Set of DFDs
• Create a graphical model of the information
system based on your fact-finding results
• Three-step process
– Step 1: Draw a context diagram
– Step 2: Draw a diagram 0 DFD
– Step 3: Draw the lower-level diagrams

49
 Creating a Set of DFDs
• Guidelines for Drawing DFDs
– Draw the context diagram so that it fits on one page
– Use the name of the information system as the
process name in the context diagram
– Use unique names within each set of symbols

50
 Creating a Set of DFDs
• Guidelines for Drawing DFDs
– Do not cross lines
– Provide a unique name and reference number for
each process
– Obtain as much user input and feedback as possible

51
 Creating a Set of DFDs
• Step 1: Draw a Context Diagram
– Most general view
– Start with process 0 (Black Box)

52
 Creating a Set of DFDs
• Step 2: Draw a Diagram 0 DFD
– Show the detail inside the black box

53
 Creating a Set of DFDs
• Step 2: Draw a Diagram 0 DFD
– If same data flows in both directions, you can use a
double-headed arrow
– Diagram 0 is an exploded view of process 0
• Parent diagram: higher-level diagram of an exploded
DFD
• Child diagram: lower-level diagram of an exploded DFD
– Functional primitive:
• A process that consists of a single function that is not
exploded further
54
 Creating a Set of DFDs
• Step 3: Draw the
Lower-Level
Diagrams
– Must use leveling and
balancing techniques
– Leveling examples
• Uses a series of
increasingly detailed
DFDs until all
functional primitives
are identified
• Exploding, partitioning,
or decomposing

55
Creating a Set of DFDs
• Step 3: Draw the
Lower-Level
Diagrams
– Balancing
• Ensures that the input
and output data flows of
the parent DFD are
maintained on the child
DFD

56
 Data Dictionary
• A data dictionary, or data repository:
– a central storehouse of information about the
system’s data
• An analyst uses the data dictionary to collect,
document, and organize specific facts about
the system
• Also defines and describes all data elements
and meaningful combinations of data
elements
57
 Data Dictionary
• A data element, a data item or field:
– the smallest piece of data that has meaning
• Data structures:
– Data elements combined into records.
• A record:
– a meaningful combination of related data
elements that is included in a data flow or
retained in a data store
58
 Data Dictionary
• Documenting the Data
Elements
– You must document
every data element in
the data dictionary
– The objective is the
same: to provide clear,
comprehensive
information about the
data and processes that
make up the system

59
 Data Dictionary
• Documenting the Data Elements
– The following attributes usually are recorded
and described
• Data element name and label
• Alias (alternate names for the data element)
• Type and length
• Default value
• Acceptable values - Domain and validity rules

60
 Data Dictionary
• Documenting the Data Elements
– The following attributes usually are recorded
and described
• Source
• Security
• Responsible user(s)
• Description and comments

61
Data Dictionary
• Documenting the Data
Flows
• using Visible Analyst
CASE tool
– The typical attributes
are as follows
• Data flow name or label
• Description
• Alternate name(s)
• Origin
• Destination
• Record
• Volume and frequency
62
 Data Dictionary
• Documenting the Data
Stores
– Typical characteristics
of a data store are
• Data store name or
label
• Description
• Alternate name(s)
• Attributes
• Volume and frequency

63
Data Dictionary
• Documenting the
Processes
– Typical characteristics
of a process
• Process name or label
• Description
• Process number
• Process description

64
 Data Dictionary
• Documenting the
Entities
– Typical characteristics
of an entity include
• Entity name
• Description
• Alternate name(s)
• Input data flows
• Output data flows

65
Data Dictionary
• Documenting the
Records
– Typical characteristics
of a record include
• Record or data structure
name
• Definition or
description
• Alternate name(s)
• Attributes

66
 Data Dictionary
• Data Dictionary Reports
– Many valuable reports
• An alphabetized list of all data elements by name
• A report describing each data element and indicating
the user or department that is responsible for data
entry, updating, or deletion
• A report of all data flows and data stores that use a
particular data element
• Detailed reports showing all characteristics of data
elements, records, data flows, processes, or any other
selected item stored in the data dictionary

67
 Process Description Tools
• A process description
• documents the details of a functional primitive,
which represents a specific set of processing
steps and business logic

• It should be noted that this chapter deals with

structured analysis, but the process description
tools also can be used in object-oriented
development, which is described in Chapter 6
68
 Process Description Tools
• When you analyze a functional primitive, you
break the processing steps down into smaller units.
• Modular Design: Based on combinations of three
logical structures, called control structures, which
serve as building blocks for the process.
• Rectangle represents a step or process
• Diamond represents a condition or decision
• The Logic follows the lines in the direction of arrows
– There are three control structures:
• Sequence (completion of steps in sequential order)
• Selection (based on the results of a test or condition)
• Iteration – looping (completion of a process that is repeated)
69
 Process Description Tools
• Typical Process description tools:
– Structured English, decision tables, and decision trees.
• Structured English:
– a subset of standard English
– describes logical processes clearly
– Must conform to the following rules
• Use only the three building blocks of sequence, selection, and
iteration
• Use indentation for readability
• Use a limited vocabulary, including standard terms used in the
data dictionary and specific words that describe the processing
rules
70
 Process Description Tools
• Structured English
– Might look familiar to programming students
because it resembles pseudocode
– The primary purpose of structured English is to
describe the underlying business logic

71
 Process Description Tools
• Decision Tables
– Shows a logical structure, with all possible
combinations of conditions and resulting actions
– It is important to consider every possible outcome to
ensure that you have overlooked nothing

72
 Process Description Tools
• Decision Tables
– The number of rules doubles each time you add a
condition
– Can have more than two possible outcomes
– Often are the best way to describe a complex set of
conditions

73
 Process Description Tools
• Decision Trees
– Graphical representation of the conditions,
actions, and rules found in a decision table

74
 Logical Versus Physical Models
• While structured analysis tools are used to
develop
– a logical model for a new IS,
– such tools also can be used to develop
– physical models of an information system
• A physical model shows how the system’s
requirements are implemented

75
 Logical Versus Physical Models
• Sequence of Models
– Many systems analysts create
– a physical model of the current system and
– then develop a logical model of the current system
– before tackling a logical model of the new system
– Performing that extra step allows them to
understand the current system better

76
 Logical Versus Physical Models
• Four-Model Approach
– Develop
• a physical model of the current system,
• a logical model of the current system,
• a logical model of the new system, and
• a physical model of the new system
– The only disadvantage of the four-model
approach is the added time and cost

77
 Chapter Summary
• During data and process modeling, a systems
analyst develops graphical models to show how
the system transforms data into useful information
• The end product of data and process modeling is a
logical model that will support business operations
and meet user needs
• Data and process modeling involves three main
tools: data flow diagrams, a data dictionary, and
process descriptions

78
 Chapter Summary
• Data flow diagrams (DFDs) graphically
show the movement and transformation of
data in the information system
• DFDs use four symbols
• A set of DFDs is like a pyramid with the
context diagram at the top

79
 Chapter Summary
• The data dictionary is the central
documentation tool for structured analysis
• Each functional primitive process is
documented using structured English,
decision tables, and decision trees
• Structured analysis tools can be used to
develop a logical model during one systems
analysis phase, and a physical model during
the systems design phase
80