Systems Analysis and Design in a Changing World, Thursday, Feb 22

1

• Systems Analysis and Design in a Changing World,
  Thursday, Feb 22

2
Todays Schedule

• Using Events for Requirements
• Using Things for Requirements
• For Tuesday, February 27Finish Reading Chapter
  5, ERDs and Class Diagrams
• Try out ERDs in Visual Paradigm

3
Recall Where You Are Headed
4
Events Affecting a Charge Account Processing
System that Lead to Use Cases
5
Identifying Events

• Can be difficult to determine
• Often confused with conditions and responses
• May be useful to trace a transactions life cycle
• Certain events left to design phase
• System controls to protect system integrity
• Perfect technology assumption defers events

6
Sequence of Transactions for One Specific
Customer gtgt Many Events
7
Defer Some Events Until Design
8
Event Table Catalog of Information about Each
Use Case
How do the events in Activity Diagram fit?
9
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
• What things does the system need to know about
  and store information about?

10
Types of Things
11
Developing an Initial List of Things

• 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

12
Questions for Refining List

• Should you include it?
• A unique thing system needs to know about?
• Inside scope of this system?
• Need to remember more than one of these?
• 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?
• Is it a characteristic of another thing?
• What if assumptions change, is it still needed?

13
Things have

• Relationship
• Naturally occurring association among specific
  things
• Occur in two directions
• Number of associations is cardinality or
  multiplicity
• Binary, unary, ternary, n-ary
• Attribute (characteristic)
• One specific piece of information about a thing

14
Cardinality/Multiplicity of Relationships
15
Attributes and Values
Identifier or Key Attribute that Uniquely
identifies the thing
16
Data Entities

• 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 database

17
Objects

• Objects do the work in a system and store
  information in the object-oriented approach
• Objects have behaviors and attributes
• 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

18
Data Entities Compared with Objects (Figure 5-22)
19
The Entity-Relationship Diagram (ERD)
20
Cardinality Symbols of Relationships for ERD
21
Expanded ERD with Attributes Shown
22
Customers, Orders, and Order Items
23
ERD with Many-to-Many Relationship
24
Many-to-Many Relationship Converted to
Associative Entity to Store Grade Attribute
25
RMO Customer Support System ERD(Figure 5-29)
26
Now you try it

• 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

27
For Tuesday, February 27

• For Tuesday, February 27Finish Reading Chapter
  5, ERDs and Class Diagrams
• Try out ERDs in Visual Paradigm