“Systems Analysis and Design, I”

LECTURE 5:
Modeling System
Requirements

1
Lecture Outline

 Defining System Requirements

 CRUD Operations
 Events and Use Cases
 Things and System Requirements
 Data Entities
 Entity-Relationship Diagram (ERD)
 Class Diagram

2
The Activities of the Analysis Phase

3
Define System Requirements

 Activity of the analysis phase

 Involves a variety of models to document
requirements
 Two key concepts identifying functional
requirements (in traditional approach and
object-oriented approach):
Use cases and the events that trigger them

Things in the users’ work domain

4
Definitions

 Use Case -- An activity the system performs in

response to a user request
 Techniques for identifying use cases
User goal technique – by talking to users to get their
description of goals in using the system
• Identify categories of users
• Each goal at the elementary business process (EBP) level
is a use case
• EBP – a task performed by one user, in one place in
response to a business event, that adds measurable
business value, and leaves system and data in consistent
state
5
Identifying Use Cases with the
User Goal Technique

6
CRUD Technique

 Four operations with data:

Create
Read
Update
Delete
 By looking at types of data (data entities or
domain classes), e.g., Customer, OrderItem
identify use cases that support CRUD
operations
7
Use Case Based on CRUD
Technique

8
Event Decomposition Technique

 Event – an occurrence at a specific time

and place and which requires system to
respond
 Business events trigger elementary
business processes (EBPs)
 EBPs are at correct level of analysis for use
cases
 Identify business events to decompose
system into activities/use cases
9
The Background to Event Concept
 Structured analysis first adapted the concept of events
to real-time systems in the early 1980’s.
 Real-time systems (e.g., process control system,
reactors, aerospace, etc.) require the system to react
immediately to events in the environment (events like
“chemical vat is full”, “boiler overflowing”)
 The concept did not find application to business
system at that time, but had been used in technical
systems
 Now the concept extended to business applications
since they have become more interactive (can be
thought of as real-time systems)
– Information engineering approach now uses it
– Very important in object-oriented approach

10
Types of Events

 External
Outside system
Initiated by external agent or actor (e.g.,
“Customer places an Order”)
 Temporal
Occur as result of reaching a point in time
Based on system deadlines (e.g., “Produce a
biweekly payroll”)
 State
Something inside system triggers processing
need (e.g., “Reorder point reached”) 11
Events and Use Cases in Account
Processing System

12
External Event Checklist

13
Temporal Event Checklist

14
Identifying Events

Events versus conditions and responses

 It can be difficult to distinguish between an event and the
sequence of conditions that lead to it (e.g., sequence of
actions leading to buying a shirt – see Figure, next slide)
 Also it may be hard to distinguish between an external event
and the system’s response (e.g. customer buys the shirt,
system requests credit card number, the customer supplies
the credit card – is not an event for the information system,
but just a part of interaction that occurs while completing the
original transaction, i.e. “the customer buying the shirt”
which is the real event)
 Way to determine whether an occurrence is an event:
 Ask whether any long pauses or intervals occur (i.e., can the
system transaction be completed without interruption? Or, is
the system at rest again waiting for another transaction?
Once a transaction starts there are no significant stops till it
is done.
15
Sequence of Actions Leading Up to
Only One Event Affecting the
System

16
 Identifying Events

The Sequence of Events: Tracing a Transaction’s Life

Cycle
 It is often useful in identifying events to trace the sequence
of transactions for a specific external agent or actor
 For Rocky Mountain Outfitters example: all the possible
transactions resulting from one new customer (see Figure,
next slide)
•Customer wants a catalog
•Customer asks for information about availability
•Customer places an order
•Customer wants to check status of an order
•Customer wants to change his/her address
•Customer may want to return an item

17
Sequence of “Transactions”
for One Specific Customer
Resulting in Many Events

18
Identifying Events

Technology-Dependent Events and System

Controls
 Some important events do not concern directly users or
transactions (e.g., design of system controls)
 System controls are checks or safety procedures to protect
the integrity of the system. For example:
•Logging on to a system (for security reasons)
•Controls for keeping integrity of a database (e.g.,
backing up the data every day)
 Controls are added to the system during design but should
not be considered during analysis (it adds to the
requirements details that the users are not typically very
concerned about)
 To help decide which events apply to controls we assume
that technology is perfect (never the case!)

19
The Perfect Technology
Assumption
 The perfect technology assumption states that:
 During analysis we should focus on events that the system
would be required to respond under “perfect” conditions, i.e.
with equipment never breaking down, capacity for
processing and storage being unlimited and people
operating the system being completely honest and never
making mistakes. Assuming the perfect technology (e.g., the
disk will never crash), the analysts can eliminate events like
“Time to back up the database”.
 During design phase we deal with these issues and events
from a “non-perfect world” point of view, e.g. events like
“Time to back up the database” and add these controls
(Figure, next slide lists some of events that can be deferred
until the design phase).

20
Events Deferred Until the Design
Phase

21
External Events for RMO:
Customers and Departments

22
Temporal Events for RMO

23
Documenting the Events
 An event table represents events and their details: each
row contains information about one event, each column
represents a key piece of information about the event (see
next slide showing event table about an event “Customer
wants to check item available”)
 Each event is characterized by:
• The trigger: an occurrence that tells the system that an
event has occurred (either the arrival of data needing
processing or of a point in time) E.g., a customer places an
order, the new order detail are provided as input
• The source: an external agent or actor that supplies data to
the system
• The activity: behavior that the system performs when an
event occurs (the system’s reaction)
• The response: an output, produced by the system that goes
to a destination
• The destination: an external agent or actor that receives
data from the system 24
Information about Each Event
in an Event Table

25
RMO Event Table

26
Use Case Descriptions

 Use case description – a description of the

processing steps for a use case
 Actor – a person or thing that uses the system and
interacts with the system; always outside of the
automation boundary, but may be part of the
manual portion
 Scenario or Instance – a particular set of internal
steps/activities to complete a business process
representing a unique path of the use case
 Preconditions – conditions that must be true
before a use case begins
 Postconditions - conditions that must be true
upon completion of the use case
27
Use Case Descriptions

 Three levels of details:

Brief description (small, well-understood
applications, simple scenario, no exception
conditions)
Intermediate description (includes internal flow of
activities, each flow of activities is described
individually, exception conditions)
Fully developed description (most formal
method; First and second parts: identify the use
cases and scenarios within use cases; Third part:
triggering event that initiate the use case; Fourth
part: brief description; Fifth part: actors; Sixth part:
cross reference to other use cases; Two Final
compartments: detailed flow of activities, alternative
activities and exception conditions
28
Brief Description

29
Intermediate Description

30
Fully
Developed
Description

31
Things and System Requirements

 Define system requirements by understanding

system information that needs to be stored

 In Traditional approach: store information about

data, i.e., things in the problem domain that
people deal with when they do their work (e.g.,
products, orders, invoices)
 In OOA: similar to the objects, i.e., external
agents or actors that interact with the system
(e.g., customers)

32
Types of Things

33
Just for Fun!

http://www.getfunnypictures.com/crt054.html

A new iMac product 34

Types of Things

• Tangible things are the most obvious (e.g., airplane,

book, vehicle, document, worksheet)
• Roles played (e.g., a role played by a person, such as
employee, customer, doctor or patient, end user)
• Organizational units (e.g., division, department,
section, task force, work group)
• Devices (e.g., sensor, timer, controller, printer, disk
drive)
• Incidents, events, or interactions can be considered
as the things (e.g., information about an order, a service
call, a contract, or an airplane flight; an order is a
relationship between a customer and an item of inventory)
• Sites/locations (e.g., a warehouse, a store, a branch
office)

35
Things in Domain

A way to identify “things” of interest

 The analyst can identify types of things by
thinking about each event in the event list and
asking what types of things are affected that the
system needs to know about, e.g. when a
customer places an order we need to know about
the following:
• The customer
• The items ordered
• Details about the order (e.g., date and payment
terms)

36
Procedure for Developing an
Initial List of Things
 Step 1: Using the event table and information about each
use case, identify all nouns (e.g., customer, product item,
order, transaction, back order, shipping, etc)

 Step 2: Using other information from existing systems,

current procedures, and current reports or forms, add items
or categories of information needed (e.g., price, colour, size,
style, season, inventory quantity, payment method, shipping
address, etc – called attributes)

 Step 3: Refine list and record assumptions or issues to

explore

• Questions to ask: to include it, exclude it, or research it 37

Questions to decide

Questions to ask to decide whether you should include,

are:
- Is it unique thing the system needs to know about?
- Is it inside the scope of the system?
- Does the system need to remember more than one
of these items?
Questions to ask to decide whether you should exclude,
are:
- Is it really a synonym for some other thing you have
identified?
- Is it just an input that results in recording some
other information you have identified?
Questions to ask to decide whether you should research,
are:
- Is it likely a specific piece of information (attribute)
about some other thing you have identified?
–Is it something that you might need if assumptions
change? 38
RMO
Example
“Things”

39
Partial List of Things for RMO

40
Characteristics of Things

 Relationship
Naturally occurring association among specific
things
Occur in two directions
- A customer places an order (one direction)
- An order is placed by a customer (other
direction)
 Number of associations is cardinality or

multiplicity (must be established for each

direction of the relationships)
 Attribute
One specific piece of information about a thing41
Relationships Between Things

42
Cardinality/Multiplicity of
Relationships

• Cardinality means the number of associations that occur between

specific things
• Cardinality is established for each direction of the relationship.
• Multiplicity is a synonym for cardinality often used with the object-
oriented approach
• Also may be important to know the range of possible values of the
cardinality (the minimum and maximum cardinality). E.g., a customer
might not ever place one order (zero associations), or place one order
(one association)
• In some cases, at least one association is required (a mandatory as
opposed to optional relationships)
• A one-to-one relationship can also be refined to include minimum and
maximum cardinality (e.g. the order is placed by one customer – it is
impossible to have an order if there is no customer. Therefore, one is
the minimum cardinality, making the relationship mandatory)

43
Cardinality/Multiplicity of
Relationships

44
Cardinality/Multiplicity of
Relationships

Kinds of Relationships
• Binary relationship is a relationship between two different
types of things (e.g., between a customer and an order)

• Unary (recursive) relationship is a relationship between two

things of the same type (e.g., one person being married to
another person or one department reports to another one)

• Ternary relationship is a relationship between three different

types of things (e.g., one order associated with a specific
customer plus a specific sales representative)

• n-ary relationship is a relationship between n (any number)

different types of things

45
Attributes of Things

• Attribute is one piece of specific information

about a thing (e.g., a customer has a name, phone
number, credit limit, etc. – each of these is an
attribute of a customer)
• The analyst has to identify the attributes of each
thing that the system needs to store
• Identifier (or key) is an attribute that uniquely
identifies a thing (e.g., a person’s social insurance
number, or an invoice or transaction number)
• Compound attribute is an attribute that contains
a collection of related attributes (e.g., a customer
full name is made up of first name, middle name,
last name and possibly nickname)
46
Attributes and Values

47
Data Entities

• Data entities are the things the system needs to store information
about in the traditional approach to information systems (entities
are things like customers and order)
• The data entities, the relationship between data entities and the
attributes of data entities are modeled using an entity-relationship
diagram (ERD)
• Computer processes interact with these data entities, creating them,
updating attribute values and associating one with another
• We can think about things as objects that interact in the system
• Objects in the work environment of the user (called also problem
domain) in the object-oriented approach are often similar to data
entities in the traditional approach
• The main difference: the objects do the work in the system, but do
not just store information (i.e. they have behavior as well as
attributes)

• With the object-oriented approach, each specific thing is an object

(John, Mary, Bill) and the type of thing is called class (in this case,
customer)
48
Data Entities vs. Objects

49
The Entity-Relationship Diagram
(ERD)
• Data storage requirements include the data entities,
their attributes and the relationships among the data
entities.
• The model used to define the data storage
requirements is called the entity-relationship diagram
(ERD)

ERD Notation

• Rectangles represent data entities

• Lines connecting rectangles show relationships
among data entities
50
ERD

51
Cardinality Symbols of
Relationships for ERD

52
Expanded ERD with Attributes

53
Transactions for Expanded ERD

54
ERD with Many-to-Many
Relationship

55
Many-to-Many Relationship
Converted to Associative Entity to
Store Grade Attribute

56
ERD: The RMO Case

• Each customer can place zero or more orders

• Each order can have one or more order items
• Each order item is for specific inventory item
• Each inventory item is associated with a product item that describes
the item generally(vendor, description, season, price, special price)
• Each product item is contained in one or more catalogs
• The catalog offers packages (shirt, pains and belt) at a reduced price
• A package contains product items
• A catalog contains zero or more packages (an optional relationship),
but a package must include at least one product item (a mandatory
relationship)
• Each order item is part of a shipment
• A shipment may contain many order items
• Each shipment is shipped by one shipper
• Each order associated with one or more order transactions (An order
transaction is a record of a payment or a return for the order. One order
transaction is created when the customer initially pays for the order, the
customer might return an item, requiring a refund and another
57
transaction)
RMO Customer Support System
ERD

58
The Domain Model Class Diagram

 Unified Modeling Language (UML) diagram

 de facto standard for models used with
object-oriented system development
 Domain model class diagram is a model to
show classes of objects
Models things in the users’ work domain
Used to define requirements for OO (very similar
to entities in ERD)
Class is the type or classification to which all
similar objects belong (e.g. guitar and violin
objects both belong to class “stringed
instruments”) 59
UML Class Symbol
 The class symbol is a rectangle
 The top section of the rectangle is the
name of the class
 The middle section is the attributes of the
class
 The bottom section lists the methods of
the class (methods define the behavior of
objects of the class). Methods are not
always shown as far as they are standard.

60
UML Class Symbol

61
 Class Diagram
 Classes, associations among classes and
attributes of classes are modeled using a class
diagram
 The class diagram shows some of the behaviors
of objects of the class, called method
 Methods of a class are the behaviors all objects
in the class are capable to do.
 A behavior is an action that the object processes
itself, when asked to do so by sending it a
message from another object
 Since each object contains values for attributes
and methods for operating on those attributes
(plus other behaviors), an object is said to be
encapsulated (i.e., a self-contained and
protected unit) 62
Simple Domain Model Class
Diagram

63
Simple Domain Model Class
Diagram (continued)
 No methods shown in domain model
 Domain classes are not software
classes
 Very similar to ERD
 UML and domain model can be used in
place of ERD in traditional approach

64
Multiplicity of Associations

65
University Course Enrollment
Domain Model Class Diagram

66
Refined Model with Association
Class and Grade Attribute

67
More Complex Class Concepts

 Generalization/specialization
hierarchies
 Inheritance
 Aggregation

68
Generalization/Specialization
 Generalization means grouping similar types of
things (e.g., motor vehicles group cars, trucks and
tanks. They share certain general features (e.g.,
wheels, engine, etc.), so motor vehicle is a more
general class)
 Specializations are judgments that categorize
different types of things (e.g., sports car is a
special type of car)
 A generalization/specialization hierarchy is
used to structure (or rank) things from the more
general down to the more special
 Each class has a more general class above it – a
superclass
 A class may have a more specialized class below –
a subclass
69
A Generalization/Specialization
Class Hierarchy for Motor Vehicles

70
A Generalization/Specialization
Class Hierarchy for RMO Orders

71
 Inheritance
 Inheritance is a concept that allows subclasses
to share characteristics of their superclasses
• E.g. a sports car has everything a car has (e.g., 4
wheels and an engine, which it inherits from the
class car which is above it)
• The sports car then specializes
–E.g., has a sports option, racing wheels, etc.
• In the object-oriented approach, inheritance is a
key concept that is possible because of
generalization/specialization hierarchies (these
hierarchies are often called inheritance
hierarchies)
72
Whole-Part Hierarchies

 Whole-part hierarchies – relationships

that structure classes by components
 Aggregation – whole-part relationships
between and object and its removable parts
Parts can exist separately
Like car and its tires
 Composition – whole-part relationships
between and object and its non-removable
parts.
Parts cannot exist separately
Like Hand is composed of fingers and thumb
73
Whole-Part Aggregation
Relationships

74
Class Diagram Example: Bank
Account
• Bank account system includes a generalization/specialization
hierarchy:
– Account is the superclass
– SavingsAccount and CheckingAccount are subclasses of
Account
– A triangle on the line connecting classes indicates
inheritance (the subclasses inherit attributes and behaviors from
the superclass Account like having an account number)
• But Savings and Checking accounts are also specialized
• A SavingsAccount “knows” how to calculate interest but a
checking account doesn’t (so they have different methods and
attributes, although they share things they inherit from class
Account)

75
Class Diagram Example: Bank
Account
• The Customer class and the Account class are associated
– Each customer can have zero or more accounts (the
diagram shows the minimum and maximum cardinality on the
line connecting the classes, and the asterisk means “many”
– Each account is owned by one and only one customer
• The SavingsAccount and CheckingAccount classes inherit
the association with the Customer class
• The Account class is an abstract class (i.e., the class that
cannot be instantiated, existing only to allow subclasses to
inherit its attributes, methods and associations) – shown in italics
• SavingsAccount, CheckingAccount and Customer are
examples of class are concrete classes that can be
instantiated (i.e., objects can be created)

76
A bank account system class
diagram

77
Association Class

• If the association itself has attributes

and/or methods, it can be represented by
an association class (represents many-
to-many relationships)
• Multiplicity of the association between
CourseSection and Student is many-to-
many. A dashed line connects the
association line to the association class
named CourseEnrollment that has the
grade attributes
78
University course enrollment class
diagram with an association class

79
The RMO Domain Class Diagram

• A generalization/specialization hierarchy
is included to show three types of orders –
web order, telephone order and mail
order, which share the attributer listed for
Order class, but each special type of order
has some additional attributes
• This diagrams shows no methods
• The initial class diagram developed during
the systems analysis phase includes no
methods. As behaviors of objects are
further developed (during analysis and
design) methods are added
80
RMO
Domain
Model
Class
Diagram

81
TA vs. OOA: Requirements modeling
• The requirements models are quite different depending
on approach used by the team: traditional or object-
oriented (the two key concepts – events and things)
• Traditional approach: based on the event table creates
a set of data flow diagrams (DFDs); the entity-relationship
diagram (ERD) defines the data storage requirements that
are included in the DFDs, views a system as a collection of
processes. When the process executes it interacts with
data. So, emphasizes processes, data, input/outputs
• Object Oriented approach: based on the event table
creates class diagrams, views a system as a collection of
interacting objects with their own behaviour (methods).
There are NO conventional processes and data files, just
interacting objects
82
Requirements Models in TA and OOA

83
 Readings

Today’s lecture: Chapter 5 – “Modeling System

Requirements”

!!!
o u
For next lecture: Chapter 6y– “The Traditional
n k
Approach to Requirements”
a
Th

84