Systems Analysis and Design in a
Changing World, Thursday, Feb 22
Today’s Schedule




2
Using Events for Requirements
Using “Things” for Requirements
For Tuesday, February 27
Finish Reading Chapter 5,
ERDs and Class Diagrams
Try out ERDs in Visual Paradigm
Recall … Where You Are Headed
3
Events Affecting a Charge Account
Processing System that Lead to Use Cases
4
Identifying Events
5

Can be difficult to determine

Often confused with conditions and responses

May be useful to trace a transaction’s life cycle

Certain events left to design phase
–
System controls to protect system integrity
–
Perfect technology assumption defers events
Sequence of “Transactions” for One
Specific Customer >> Many Events
6
Defer Some Events Until Design
7
Event Table:
Catalog of Information about Each Use Case
How do the “events” in Activity Diagram fit?
8
“Things” in Problem Domain

Define system requirements by understanding
system information that needs to be stored

Store information about things in the problem
domain that people deal with when they do their
work

Analysts identify these types of things by considering
each use case in the event table
–
9
What things does the system need to know about and store
information about?
Types of Things
10
Developing an Initial List of Things
11

Step 1: Using the event table and information about
each use case, identify all nouns

Step 2: Using other information from existing
systems, current procedures, and current reports or
forms, add items or categories of information needed

Step 3: Refine list and record assumptions or issues
to explore
Questions for Refining List

Should you include it?
–
–
–

Should you exclude it?
–
–
–

Synonym for another thing already in list?
Is it really an output?
Input that results in recording info already in list?
Should you research it?
–
–
12
A unique thing system needs to know about?
Inside scope of this system?
Need to remember more than one of these?
Is it a characteristic of another “thing”?
What if assumptions change, is it still needed?
“Things” have …

Relationship
–
–
–
Naturally occurring association among specific
things
Occur in two directions
Number of associations is cardinality or
multiplicity


Attribute (characteristic)
–
13
Binary, unary, ternary, n-ary
One specific piece of information about a thing
Cardinality/Multiplicity of
Relationships
14
Attributes and Values
Identifier or Key – Attribute that Uniquely identifies the “thing”
15
Data Entities
16

Things system needs to store data about in
traditional IS approach

Modeled with entity-relationship diagram
(ERD)

Requirements model used to create the
database design model for relational


Objects
do the work in a system and store
Objects
information in the object-oriented approach
Objects have behaviors and attributes
–
–
–


17
Class – type of thing
Object – each specific thing
Methods – behaviors of objects of the class
Objects contain values for attributes and methods
for operating on those attributes
An object is encapsulated – a self-contained unit
Data Entities Compared with
Objects
(Figure 5-22)
18
The Entity-Relationship Diagram
(ERD)
19
Cardinality Symbols of
Relationships for ERD
20
Expanded ERD with Attributes
Shown
21
Customers, Orders, and Order
Items
22
ERD with Many-to-Many
Relationship
23
Many-to-Many Relationship Converted
to Associative Entity to Store Grade
Attribute
24
RMO Customer Support System ERD
(Figure 5-29)
25
Now you try it …



26
Case Study: (Page 194-5)
The Spring Breaks ‘R’ Us Travel Service
Booking System
#1 Events and event Table
#2 Data Entities and their relationships
For Tuesday, February 27


27
For Tuesday, February 27
Finish Reading Chapter 5,
ERDs and Class Diagrams
Try out ERDs in Visual Paradigm