Systems Analysis and Design of a Business Event Driven System

1
Systems Analysis and Design of a Business Event
Driven System

• Chapter 4

2
Objective

• The objective of this chapter is to help you
  understand the key steps in analyzing and
  designing information technology (IT)
  applications.

3
Analysis and Design of a Business Event-driven IT
Application

• Designing quality IT applications requires a
  thorough understanding of the organization
  including its current and desired objectives,
  strategies, value chains, risks, and business
  processes
• There are a variety of methods for analyzing and
  designing information systems.
• How do professionals move from a business need
  for information to creating the physical IT
  infrastructure that can provide that information?

4
Systems Analysis and Design Methods

• Exhibit 1 presents a systems analysis and design
  life cycle (SDLC) by J.A. Hoffer, J.F. George,
  and J.S. Valacich
• Exhibit 2 displays the systems development
  process presented by J.L. Whitten, L.D. Bentley,
  and V.M. Barlow
• Other analysis and design approaches, including
• object-oriented analysis and design,
• prototyping,
• systems engineering,
• joint application design,
• participatory design,
• essential system design,
• automating the SDLC using CASE tools

5
Steps of a Systems Analysis and Design Life Cycle
(SDLC)
J.A. Hoffer, J.F. George, and J.S. Valacich,
Modern Systems Analysis and Design, Reading,
Massachusetts Addison Wesley, 1999.
6
The Systems Development Process
J.L. Whitten, L.D. Bentley, and V.M. Barlow,
Systems Analysis and Design, instructors ed., 3rd
ed. Burr Ridge, Ill. Richard D. Irwin, 1994.
7
Phase 1 Systems Analysis

• Step 1-A Defining systems requirements
• Step 1-B Structuring systems requirements using
  process modeling
• Step 1-C Structuring systems requirements using
  logical models
• Step 1-D Structuring systems requirements using
  conceptual data modeling
• Step 1-E Selecting a design strategy

Process Modeling
Logical Models
Conceptual data modeling
8
STEP I-A Systems Analysis - Defining Systems
Requirements

• After an organization has
• identified the need for a system project and
• has successfully made a business case to justify
  investing the time and funds necessary to
  undertake the project,
• a project team organizes and plans the work to be
  completed.
• The team considers the costs, benefits,
  feasibility, responsibilities, and project
  timeline.
• After completing these details they define the
  system requirements
• What are the expectations of this system?
• What work and decisions will it support?
• What objectives will it help the organization to
  accomplish?

9
Defining Systems Requirements

• Your business analysis highlights the activities
  that an organization needs to perform effectively
  and efficiently to accomplish its objectives.
• An information system should support these
  activities.
• Add information processes, including data
  stores, and data flows, to the analysis
• Consider the desired environment and envision
  innovative ways for the system to enable
  organization objectives and desired processes.

10
Exhibit 4-3 Christopher Inc. REAL Model
Resources
Agents
Events
Christopher Inc. provides baseball caps to major
league baseball teams to sell in their ballparks.
While analyzing their business process,
Christophers analysis team identified three key
operating activities receive orders from
baseball teams (who are Christophers customers),
package and ship caps to the teams (the sale of
merchandise), and receive payment from the teams
11
The Structure of Information Processes
12
STEP I-B Systems Analysis - Structuring Systems
Requirements Using Process Modeling

• Some analysis methods create several versions of
  data flow diagrams, including
• context data flow diagrams,
• data flow diagrams of the current physical
  system, data flow diagrams of the current logical
  system, and
• data flow diagrams of the proposed logical
  system.
• Often, each data flow diagram includes a
  thorough description of each data flow.

13
Exhibit 4-4Christopher Inc., Context Diagram
O Sales / collection system

• A context diagram shows the sources and
  destinations of the data that are outside the
  boundaries or scope of the system being analyzed.
  
• You do not show the data stores and data flows
  within the boundaries of the system.

the circle represents computer processing
Christopher Inc. needs a system that enables
communication with customers several times during
the process (e.g., customers send in order data
as well as payment data, and Christopher Inc.
sends back shipping, sales, billing, and payment
data).
Christopher Inc. needs a system that allows them
to send shipping data to their carriers and
receive shipment confirmations from their
carriers.
Finally, Christopher Inc.s systems should allow
access by internal agents (such as management and
other decision-makers) to critical data and
information.
14
Exhibit 4-5 Christopher, Inc. Level 0 Data Flow
Diagram
1.0 Process customer orders
Desired information
Orders
Shipping request data
2.0 Process shipments to customers
Desired information
Decision makers
Bill
Customers
Payments due data
Payment
Desired information
3.0 Process payments from customers
15
Exhibit 4-6 Christopher Inc., Level 1 Data Flow
Diagram
Customer order data
Approved Order
Order
1.1 Approve and record customer order data
Order data
1.2 Generate information about orders
Desired information
Shipping Request Data
16
Context Dictionary

• Some analysts like to add more detail to context
  and other data flow diagrams, by providing the
  data elements that comprise the data flows on the
  diagram. We will refer to these data flow details
  as the context dictionary. Each entry in the
  context dictionary is separated from its
  definition by an equal sign () and is defined
  using the following set of symbols
• To connect elements of the definition
• To identify repeating elements of the
  definition

17
Sample Context Dictionary Entries

• Sales-Invoice Invoice Sale-Date Register
  Customer Name Salesperson Name
  Merchandise Name Qty-Sold Price
  Item-Total Sale-Total
• Customer-Profile Report-Date Name State
  Birth date Telephone Merchandise Description
  Qty-Sold
• Product-Sales Report-Date Merchandise
  Merchandise Description Qty-Sold Margin
  Contribution
• Accounting-Revenue Report-Date
  Reporting-Period Revenue for Reporting-Period
• Sales-by-Salesperson Report-Date Salesperson
  Name Merchandise-Description Qty-Sold
  Contribution Total Sales Total Contribution

18
Additional Prototyping Steps
When you are creating data flow diagrams or
work-flows for a business process, how do you
know how many recording, maintaining, and
reporting processes you need for an IT
application? You can use your REAL model and
the context diagram as a guide.
The number of reporting processes required for
an application is a function of the number of
views required by information customers. You will
need one reporting process for each required
output view. To help you plan, determine how many
of the following three types of reporting output
views your information customers need - Source
documents printed or electronic transmission
of event data documentation - Preformated
reports reports that are regularly used by
information customers -Ad hoc reports reports
that information customers design and request to
provide a new view or a view that is rarely used

• context diagram
• inflows and outflows to
• Record event data
• Maintain resource, agent, location data
• Report source documents, queries, reports

You need one recording process in your IT
application for each business event object in the
applications REAL model
You need one maintenance process in your IT
application for each resource, agent, and
location object in the applications REAL model
19
McKell's Retail Sale Store Case Checkpoint

• Reporting processes to handle key management
  functions
• Sales Invoice - the customer's bill
• Customer Profile - a report that provides
  information about customers and their purchasing
  habits
• Product Sales - a report that provides the
  margin and contribution for each merchandise
  items type sold
• Accounting Revenue - a report that provides a
  calculation of sales revenue for a specific
  period
• Sales by Salesperson - a report that details the
  merchandise and contribution to sales revenue for
  each salesperson)

• Four maintenance processes
• Maintain Customer Data,
• Maintain Merchandise Data,
• Maintain Salesperson Data, and
• Maintain Register Data
• to keep our resource, agent, and location data up
  to date and valid

• Using our retail sale example, the IT application
  would have
• One recording process (i.e., Record Sale Data) to
  record the one event of interest

20
Step 1-C Structuring Systems Requirements Using
Logical Models

• After completing data flow diagrams that
  graphically show the flow of data to fulfill the
  system requirements, many analysts use logic
  models to represent the logic of the information
  processes denoted in the data flow diagram(s).
• Their objective is to produce structured
  descriptions and diagrams that enumerate the
  logic contained in each process denoted in the
  data flow diagram(s).
• Techniques used during this step include
  structured English, decision tables, decision
  trees, and state-transition diagrams or tables.
• We will overview just one of these techniques
  Structured English.

21
Structured English

• Structured English is used to plan and document
  the steps of a computer instruction set (a
  program) without using a programming language.
  Structured English is used to define the detailed
  logic of each information process (Exhibit 4-7).
• Structured English focuses on conciseness and
  clarity to document the essence of an information
  process and eliminates
• Adjectives.
• Adverbs.
• Compound sentences.
• Non-imperative expressions.
• All but a limited set of conditional and logic
  structures.
• Most punctuation.
• Footnote type details.

22
Exhibit 4-7 Structured English Example
Process
Data
Input
For each Customer-Order do the following 1.
Search for Customer-Name if found Confirm
customer info with customer if not found Enter
customer data 2. Check for availability of
inventory requested if available Confirm
ship-to-information if not available Inform
customer with Order-Confirmation 3. Provide
customer with Order-Confirmation 4. Send
notification to packing agents
Output
23
Business Event Risks

• In addition to including the logic for completing
  a desired task, this step provides an opportunity
  for thinking about ways information technology
  can be used to help reduce business and
  information risks
• An operating event occurring at the wrong time or
  sequence.
• An operating event occurring without proper
  authorization.
• An operating event involving the wrong internal
  agent.
• An operating event involving the wrong external
  agent.
• An operating event involving the wrong resource.
• An operating event involving the resource amount.
• An operating event occurring at the wrong
  location.

24
Information Event Risks

• Information event risks include the risks
  associated with incomplete, inaccurate, or
  unauthorized recording, maintaining, and
  reporting information activities
• Recording risks - Recording risks include
  recording incomplete, inaccurate, or invalid data
  about an operating event. Incomplete data results
  in not recording all of the relevant
  characteristics about an operating event in the
  data stores. Inaccuracies arise from recording
  data that does not accurately represent the
  event. Invalid refers to data that are recorded
  about a fabricated event.
• Maintaining risks - Maintaining risks are
  essentially the same as recording risks. The
  only difference is that the data maintained
  relates to resources, agents, and locations
  rather than operating events.
• Reporting risks - Reporting risks include data
  that are improperly classified, improperly
  summarized, provided to unauthorized parties, or
  not provided in a timely manner.

25
STEP I-D Systems Analysis Structuring Systems
Requirements Using Conceptual Data Modeling

• To focus on the specific data you want to capture
  to describe reality and generate needed outputs
  we use a conceptual data model.
• Conceptual data models represent the entities or
  objects you want to collect data about, and rules
  about the meaning and interrelationships among
  these data objects.
• To complete this step, most analysts use one of
  two modeling techniques Entity-Relationship
  (E-R) or Object Oriented (OO).

26
ERD

• Data Entity
• anything, real or abstract, about which we want
  to store data.
• synonyms include entity type, entity class or
  object
• Data relationship
• a natural association that exists between one or
  more entities
• business activities or events that link one or
  more entities

EntityName
RelationshipName
27
Example
Customer
Orders
Supplies
28
Entities

• AGENTS
• Entities that describe roles played in a system.
  They usually represent people or organizations.
• ACCOUNT, AGENCY, ANIMAL, APPLICANT, BORROWER,
  CHILD, CLASS, CLIENT, CONTRACTOR, CREDITOR,
  DEPARTMENT, EMPLOYEE, EMPLOYER, INSTRUCTOR,
  MANAGER, OFFICE, SALESPERSON, SUPPLIER, TEAM,
  VENDOR

29
Entities

• RESOURCES
• Entities that describe tangible things. Most
  tangible things are easy to identify because you
  can see them.
• BOOK, CHEMICAL, COURSE, DISK, EQUIPMENT, MACHINE,
  MATERIAL, METAL ,PART, PRODUCT, PROGRAM, SERVICE,
  SUBSTANCE, VEHICLE

30
Entities

• EVENTS
• Most events are easy to identify because the
  business records data on forms or files.
• Events are characterized by the fact that they
  happen or have duration
• AGREEMENT, APPLICATION, APPOINTMENT, ASSIGNMENT,
  BACKORDER, BUDGET, CLAIM, CONTRACT, DEPOSIT,
  DISBURSEMENT, FORECAST, INVOICE, JOB, LICENSE,
  PAYMENT, PURCHASE ORDER, REGISTRATION,
  RESERVATION, RESUME, SEMESTER, SHIPMENT, STEP,
  TASK, TEST, WORK ORDER

31
Entities

• LOCATIONS
• Entities that describe locations
• BRANCH, BUILDING, CAMPUS, CITY, COUNTRY, COUNTY,
  ROOM, ROUTE, SALES REGION, SCHOOL ZONE, PROVINCE,
  STORAGE BIN, VOTER DISTRICT, WAREHOUSE ZONE

32
Entities and Entity Classes or Groups

• Entities of a given type are grouped into an
  entity class
• Thus, the EMPLOYEE entity class is the collection
  of all EMPLOYEE entities
• Entity classes are described by their structure
• An instance of an entity is the representation of
  a particular entity such as Customer 1234 and is
  described by its values of the attributes
• Name entities with nouns that describe above
  (singular) INVOICE
• Instances of the entity are referred to in the
  plural - Invoices

33
Attributes

• Data attributes are characteristics that are
  common to all or most all instances of a
  particular entity.
• Synonyms include properties, data elements,
  descriptors, and fields
• Attributes take on values for each occurrence of
  an entity. An attribute must have more than one
  legitimate value otherwise it is a constant.

34
Identifier

• Identifier is an attribute or combination of
  attributes that uniquely identifies one, and only
  one occurrence of an entity.
• Synonyms include key or primary key
• For example, Employee instances could be
  identified by a SocialInsuranceNumber,
  EmployeeNumber or EmployeeName
• Identifiers of an entity instance consists of one
  or more of the entitys attributes
• An identifier may be either unique or non-unique
• Identifiers that consist of two or more
  attributes are called composite identifiers

35
Relationships

• Entities can be associated with one another in
  relationships.
• A relationship can include many entities and the
  number of entities in a relationship is a degree
  of the relationship.
• Degree 2 relationships are common and are called
  binary relationships
• 11 one to one AUTO-ASSIGNMENT
• 1N one to many DORM-OCCUPANT
• NM many to many STUDENT-CLUB

36
Relationship Degree
37
Three Types of Binary Relationships
These are often called HAS A relationships
38
Other relationships
Weak Relationships
EMPLOYEE
DEPENDENT
1N
ID Dependententity
BUILDING
APARTMENT
1N
39
ERD
Semantic Object Model (SALSA)
40
Access Database Relationships
41
REAL Diagram
(1,1)
Product-Item (Resource)
Customer(Agent)
(0,)
(0,)
(1,1)
Take Order (Event)
(0,)
SalesPerson (Agent)
(1,)
List Items Ordered (Event)
(1,1)
(0,)
42
Exhibit 4-8 Recursive Relationship Example
manages
Employee
Employee
manages
43
Relationships

• Described by verbs or verb phrases
• Multiple relationships are possible between two
  entities

Is Being Taken by
COURSE
STUDENT
Was Taken by
44
Ordinality

• Defines whether the relationship between entities
  is mandatory or optional.
• Ordinality determines the minimum number of
  occurrences of one entity relative to another.
• Ordinality must be defined in both directions

45
Cardinality

• Defines the maximum number of occurrences of one
  entity for a single occurrence of the related
  entity
• This is the number to the right of the colon
  below. Ordinality is the number to the left of
  the colon.

0M
Order
Products
Customer
11
0M
Places
1M
46
Relationships That Can Be Described by Data

• Normally relationships are not described by data
  attributes
• However if Cardinality is many in both
  directions, the relationship itself is frequently
  described by data attributes.
• Many to Many relationship
• An associative entity is a data entity whose
  attributes describe a relationship between two or
  more fundamental entities

47
Many to Many
Service
Shipment
IsPlacedFor
0M
Requested Service
1M
0M
11
Order
OR
AND
11
Is Placed For
1M
Ordered Product
0M
0M
Product
Invoice
48
Linking Objects with Many to Many ()
Relationships
Create a separate table that includes the key
attributes from both object tables.
49
Linking Objects with One to One (11)
Relationships
Create a separate table that includes the key
attributes from both objects
Put the key attribute of either object in the
table of the other
OR
When you are linking two events with a 11
relationship, either put the key of the prior
event table into the subsequent event table or
create a third table.
50
Linking Objects with One to Many (1) or Many
to One (1) Relationships
Post the key attribute of the object with the 1
side of the cardinality into the table of the
many () side of the cardinality.
If you follow the specified rule and find that
you would post the key of the event that occurs
second into the table of the event that occurs
first, create a separate table that includes the
key attributes from both event tables.
51
Exhibit 4-9 Christopher Inc. REAL Model
Resources
Events
Agents
Order personnel
(1,1)
Receive customer order
takes
(0,)
(0,)
(1,)
(1,1)
(1,1)
Customer
(0,)
Inventory
includes
places
(1,1)
(1,)
(1,1)
goes to
is made up of
(0,)
(0,)
Shippingpersonnel
Ship Order
(1,1)
(0,)
executes
(0,)
(0,)
(1,)
(1,1)
carried by
Shipping firm
(0,)
is kept at
increases
Collect payment
sends
(0,)
Cash
Bank
(0,)
(0,)
(1,1)
(1,1)
(0,)
takes in
Cashier
(1,1)
52
Exhibit 4-10 Different Notations to Represent
Relationships Cardinalities
(1,1)
(1,)
(0,1)
(0,)
53
Exhibit 4-11 Entity Attributes in an ER diagram
Inventory Item
Inventory Item
Inventory Item
Inventory Item
Inventory Item
Inventory
Inventory Item
Inventory Item
54
Exhibit 4-12Example Relational Database Table
Customer Table
55
SALES table (without a separate table for the
sale-inventory relationship)
56
Sales Event Table
() Sale-Inventory Table
57
Exhibit 4-13 Christopher Inc. Event Logical
Structures - Order Taking
RECEIVE CUSTOMER ORDER Sales Order , Customer
,Customer Order Representative Employee ,
Date, Time, Instructions, Cancel by Date,
Location or order
CUSTOMER Customer , Name,Street
Address, City, State, Zip, Telephone Credit
Rating, Credit Limit
ORDER/INVENTORY Sales Order , Inventory item
, Quantity Ordered
Legend
EMPLOYEE, Employee , Name, Address Telephone
, BirthDate Start date, Salary,
INVENTORY Inventory Item , Description, Product
Specification, Reorder Point, Current
Price, Beginning Quantity, Beginning Quantity Date
RELATION
Primary Key
Foreign Key
58
Exhibit 4-13 Christopher Inc. Event Logical
Structures - Shipping
SHIP ORDER Invoice , Sales Order ,
Customer , Shipping Personnel Employee ,
Shipping Firm ID , Date, Time, Shipment
tracking , Sales Tax
SHIP/INVENTORY Invoice , Inventory Item ,
Quantity Shipped, Price Each
Sales Order
Customer
Employee
SHIPPING FIRM, Shipping Firm ID, Shipping Firm
Name, Address Telephone , Contact Person Rate
Information
Inventory
59
Exhibit 4-13 Christopher Inc. Event Logical
Structures - Cash Collection
BANKBank , Bank Name, Address
CASHCash Account , Bank , Type of
Account Beginning Balance Date
Shipping Order
SHIP/COLLECT PAYMENTInvoice , Cash Receipt
, Amount applied to this Invoice
COLLECT PAYMENT Cash Receipt , Cash Account
, Customer , Cashier Employee ,Date,
Time, Amount Received, Electronic Funds Transfer
Customer
Employee
60
Exhibit 4-14 Linking the Order Recording Process
with the Data Repository
INVENTORY
Record Sale
ORDER
Order-Data
CUSTOMER
ORDER PERSONNEL
ORDER-INVENTORY
61
Exhibit 4-15 Sample Maintenance Processes and
Data Access
Update Bank Data
Register-Data
BANK
Update Customer Data
Customer-Data
CUSTOMER
Update Shipping firm Data
Salesperson-Data
SHIPPING FIRM
Update Inventory Data
Merchandise-Data
INVENTORY
62
Exhibit 4-16Example fo Generating a
Sales-by-Salesperson Report
MERCHANDISE
Request Sales-by- Salesperson report
Report Sale
SALE
Sales-by- Salesperson
SALESPERSON
SALE-MERCHANDISE
Sales-by-Salesperson Report-Date Salesperson
Name Merchandise-Description Qty-Sold
Contribution Total Sales Total Contribution
63
Exhibit 4-17 Evolution Of AIS Modeling
Stage 1
Stage 2
Stage 3
Manual Systems
Automated Systems
Event Driven IT Applications
Resources Manual Process Acct Cycle Data
Stores (Files) Journals Ledgers
Resources Information Technology Process Acct
Cycle Data Stores (Files) Journals Ledgers
Resources Information Technology Process
Record, Maintain, Report Business Activity
Data Data Stores Business Activity
Data Integrated Stores
Bias Support Planning, Control Evaluation
Activities of Various Information Customers
Bias Generate financial statements
Bias Generate financial statements
64
Prototyping Preliminary Steps
Step 1 Review the business process and identify
the business events of interest.
65
Prototyping Preliminary Steps
Step 1 Review the business process and identify
the business events of interest.
Step 2 Analyze each event to identify the event
resources, agents, and locations.
66
Prototyping Preliminary Steps
Step 1 Review the business process and identify
the business events of interest.
Step 2 Analyze each event to identify the event
resources, agents, and locations.
Step 3 Identify the relevant behaviors,
characteristics, and attributes of the event,
resources, agents, and locations.
67
Prototyping Preliminary Steps
Step 1 Review the business process and identify
the business events of interest.
Step 2 Analyze each event to identify the event
resources, agents, and locations.
Step 3 Identify the relevant behaviors,
characteristics, and attributes of the event,
resources, agents, and locations.
Step 4 Identify the direct relationships
between objects.
68
Prototyping Preliminary Steps
Step 1 Review the business process and identify
the business events of interest.
Step 2 Analyze each event to identify the event
resources, agents, and locations.
Step 3 Identify the relevant behaviors,
characteristics, and attributes of the event,
resources, agents, and locations.
Step 4 Identify the direct relationships
between objects.
Step 5 Validate the model with the business
person.
69
Planning an Event-Driven Application

• Identifying the business events of interest
• Identifying the resources, agents, and locations
  of each event of interest
• Identifying the relevant behaviors,
  characteristics and attributes of the events,
  resources, agents, and locations
• Identifying the direct relationship between
  objects
• Validating your business process model with
  business persons

Chapter 2
70
Planning an Event-Driven Application

• Defining the scope of the IT application
• Enhancing the relationships of the REAL model by
  defining their cardinalities
• Designing the data repository
• Linking the recording, maintaining, and reporting
  process to the data repository
• Constructing the prototype

Chapter 4
71
McKells Retail Sale Store
72
Application Context Diagram
EVENT-DATA Definitions of various data flows for
each business event within the application
scope MAINTENANCE-DATA Definitions of various
data flows for maintaining application reference
data RESPONSES Definitions of various
responses provided by the application NOTIFICATIO
NS Definitions of various notifications
provided by the application REPORTS
Definitions of various reports provided by the
application
73
McKells Retail Sale Context Diagram
EVENT-DATA Example Sale-Data Sale-Date
Register Customer Employee
Merchandise Qty-Sold MAINTENANCE-DATA
Example Definitions of various data flows for
maintaining customer, salesperson, and register
reference data RESPONSE Example
Sales-Invoice Invoice Sale-Date Register
Customer Name Salesperson Name
Merchandise Name Qty-Sold Price
Item-Total Sale-Total NOTIFICATION Example
Warehouse-notification InvoiceMerchandise
Qty-Sold REPORT Example Product-Sales
Report-Date Merchandise Merchandise
Description Qty-Sold Margin
Contribution Accounting-Revenue Report-Date
Reporting-Period Revenue for Reporting-Period S
ales-by-Salesperson Report-Date Salesperson
Name Merchandise-Description Qty-Sold
Contribution Total Sales Total
Contribution Customer-Profile Report-Date
Name State Birthdate Telephone
Merchandise Description Qty-Sold
74
Additional Prototyping Steps
Step 6 Define the scope of the application.
Step 7 Enhance the relationships of the REAL
model by defining their cardinalities.

• object 1(min, max) --- object 2(min, max)
• minimums denote business rules
• maximums help establish data structures
• both help structure your audit trail

75
McKells Retail Sale REAL Model With Cardinalities
Salesperson
Register
(1,1)
(1,1)
(0,)
(0,)
Sale
(0,)
(0,)
Customer
(1,1)
(1,)
Merchandise
76
Additional Prototyping Steps
Step 6 Define the scope of the application.
Step 7 Enhance the relationships of the REAL
model by defining their cardinalities.
Step 8 Design the data repository structure.

• tables or objects
• primary keys
• posted keys
• nonkey attributes

77
McKells Retail Sale Store - Tables
Register (Register,
Merchandise (Merchandise,
Sale (Sale,
Customer (Customer,
Salesperson (Employee,
Sale-Merchandise (Sale, Merchandise,
78
McKells Retail Sale Store - Tables
Register (Register,
Merchandise (Merchandise,
Sale (Sale, Register, Customer,
Employee,
Customer (Customer,
Salesperson (Employee,
Sale-Merchandise (Sale, Merchandise,
79
McKells Retail Sale Store - Tables
Register (Register, Store, Date-Purchased, Cost,
...
Merchandise (Merchandise, Description,
Current-Price, Current-Cost, ...
Sale (Sale, Register, Customer,
Employee, Time, ...
Customer (Customer, Name, Address, State, Zip,
Birthdate, Telephone, Marital-Status, ...
Salesperson (Employee, Name, Commission-Rate, ...
Sale-Merchandise (Sale, Merchandise,
Qty-Sold, Historical-Cost, Historical-Price,
...
80
Additional Prototyping Steps
Step 6 Define the scope of the application.
Step 7 Enhance the relationships of the REAL
model by defining their cardinalities.
Step 8 Design the data repository structure.
Step 9 Link the recording, maintenance, and
reporting processes to the data repository.

• Record events
• Maintain resources, agents, and locations
• Report (source documents, queries, reports)

81
Additional Prototyping Steps
Step 6 Define the scope of the application.
Step 7 Enhance the relationships of the REAL
model by defining their cardinalities.
Step 8 Design the data repository structure.
Step 9 Link the recording, maintenance, and
reporting processes to the data repository.
Step 10 Build the application prototype.
82
McKells Retail Sale UpdatedREAL Model With
Cardinalities
83
McKells Retail Sale Store Tables

• We are able to satisfy multiple views
• by the data we collect
• What happened?
• When?
• What resources were involved and how much?
• Where did it occur?
• Who was involved and what roles did they play?

Sale
Merchandise
Sale-Merchandise
Register
Customer
Salesperson
84
Steps for Building an IT Application
Prototype 1. Build a table for each table
defined using the REAL model, 2. Build a menu
system that has the following choices Record
Event Data, Maintain Data, Reports, and Exit. 3.
Develop the necessary forms and procedures to
collect event data and store it in the
appropriate tables. 4. Develop the necessary
forms and procedures to maintain the resource,
agent, and location tables. 5. Develop queries
required to generate desired information. 6.
Develop report formats for each report. 7. Write
the procedures required to execute the queries
and format the reports. 8. Link each recording,
maintaining, and reporting form to the
application menu defined in step 2. Each form
becomes a choice under either the Record Event
Data, Maintenance, or Reports menu options.
85
REAL Business Process Modeling of Mail Order
Sales/Collection Process