1. Systems Analysis and Design of a Business Event-Driven System
CHAPTER 4
Systems Analysis and Design of a Business Event-Driven System

2. The objective of to help you understand the key steps in analyzing and designing information Technology (IT) applications.
In this chapter, we explain how to use the REAL business process model to analyze and design IT application that support those responsible for defining and managing organization activities.
The key to better information systems is not simply understanding the current business operations and information processing, but understanding the organization’s objectives and desired business process.

3. EXHIBIT 4-1 Systems Development Process : Method One
Project
Initiating
And Planning
Analysis
Logical
Design
Physical
Identification
And Selection
Implementation
Maintenance

4. Existing system details
EXHIBIT 4-2
System Development Process: Method Two
Existing system details
and limitations
System
Design
support
analysis
Implementation
Planning
Planned application
development project
Business
requirements
statements
Production
information
system
Technical
statement

5. The chapter introduce you to each of the following systems analysis and design phases, with emphasis on Phases I, II, III:
I. The analysis Phase
II. The Logical Design Phase
III. The Physical Design Phase
IV. The Implementation and Maintenance Phase
Your business analysis highlights the activities that an organization needs to perform effectively and efficiently in order to accomplish its objectives.

6. Christopher, Inc, REAL Model
EXHIBIT 4-3
Christopher, Inc, REAL Model
Order
personnel
Customer
Shipping
Personnel
Firm
Cashier
Receive
order
Ship
Collect
Payment
Inventory
Cash
Bank
Is kept at
Increases
Takes in
Sends
includes
Takes
Places
Goes to
Executes
Carried by
Is made
up of

7. Processing instructions and data flows are necessary to support the operating and decision-making. Includes the major components: (1) the data and organization chooses to record and maintain and (2) the processing instructions used to record data, maintain data, and report useful information.
The workflow to support a business process involves three types of information events: Recording, Maintaining, Reporting.
Recording operating event data involves capturing data about each operating event. When data are captured while the operating events occurs, the recording process the execute business rules specified by management for each operating event. These rules are the guidelines standards, policies, and/or procedures intended to increase operational and information quality by reducing such as errors, irregularities and fraud.

8. Maintaining reference data involves adding, deleting or modifying data about resources, agents and locations. The objectives is to maintain accurate, complete and timely data about the resources, agents, and locations involved in operating events for the process you are modeling.
The reporting processes extract and covert stored data about events, resources, agents and locations into information, and format the information for presentation to information customers.
In this step, analysts use process-modeling techniques to graphically represent the system requirements.
Will focus on data flow diagrams of smple business event-driven systems.

9. Context diagram-the highest level logical view of a system
Context diagram-the highest level logical view of a system. When creating a context diagram, you do not show the data stores and data flows within the boundaries of the system. This diagram is consistent with the REAL model.
As you create more detailed data flow diagrams, remember that each information process (recording, maintaining, and reporting)

10. Christopher, Inc, Context Diagram
EXHIBIT 4-4
Christopher, Inc, Context Diagram
Customers
Sales/Collection
System
Decision
Makers
Order
Bill
Payments
Desired
Information

11. Christopher, Inc, Level 0 Data Flow Diagram
EXHIBIT 4-5
Christopher, Inc, Level 0 Data Flow Diagram
Customers
2.0
Process
shipments to
customers
Decision
Makers
Order
Bill
Payments
Desired
Information
1.0
orders
3.0
from
Due data

12. Christopher, Inc, Level 1 Data Flow Diagram
EXHIBIT 4-6
Christopher, Inc, Level 1 Data Flow Diagram
1.1
Approve and
record customer
order data
1.2
Generate
information
about orders
Customer order data
Order
Shipping
Request
data
Approved order
Order data
Desired Information

13. Techniques used during this step include structured English, decision Tables, decision trees and state transition diagrams or tables.
Structured English is a code-independent way of communicating program logic. It is used to plan and document the steps of a computer instruction set (a program) without using a programming language.

14. Structured English Example
EXHIBIT 4-7
Structured English Example
Process
Output
Input
Data
For each customer-order do the following:
Search for Customer-Name
If found
Confirm customer info with customer
Enter customer data
2. Check for availability of inventory requested
If available
Confirm ship to information
If not available
Inform customer the inventory is not available
3. Provide customer with order confirmation
4. Send notification to packing agents

15. Business event risk results in errors and irregularities having one or more of the following characteristics.
Information event risks include
Recording risk include
Maintaining risk
Reporting risk
To focus on the specific data you want to capture to describe reality and generate needs outputs. Conceptual data model.
A relationship is an association between the instances of one or more entity groups of interest to the organization

16. We focus on the business activities that compose the information represented in the views (the business processes)
The model from Chapter 2 includes what we call binary relationships. Binary relationships are relationships between instances of two different entity group.
A recursive relationship is the relationship between instances of a single entity group. There is a third type relationship, the ternary relationship that we will not discuss at this time.
Analyst use cardinalities to accomplish this task. The purpose of relationship cardinalities is to enrich our language for describing and more precisely representing business process rules.

17. Recursive Relationship Examples
EXHIBIT 4-8
Recursive Relationship Examples
Employee
Manages
Managers

18. Many people overlook the power of cardinalities as a tool to understand electronic audit trails, as well as the logic that should appear in information system processing instruction. The cardinalities represent how a business desires its business activities to occur, you information system should reflect this reality.

19. Christopher, Inc, REAL Model with Cardinalities
EXHIBIT 4-9
Christopher, Inc, REAL Model with Cardinalities
Order
personnel
Customer
Shipping
Personnel
Firm
Cashier
Receive
order
Ship
Collect
Payment
Inventory
Cash
Bank
Is kept at
Increases
Takes in
Sends
includes
Takes
Places
Goes to
Executes
Carried by
Is made
up of

20. EXHIBIT 4-9
Different Notation to Represent Relationship Cardinalities
(1,1)
(1,*)
(0,1)
(0,*)

21. System analysts consider the various hardware, software, processing modes and so on that will be most effective and efficient in designing a system that full fills the stipulated requirements.
The architecture guiding these concept can be implemented using a variety of technology platforms (both hardware and software).
The logical design phase involves several major components including designing form and reports, designing interface and dialogues and designing database using logical data modeling techniques.
A table is a two-dimensional array having columns and rows. Each column or field of a table is called and attribute, and each row of the table is called a record.

22. EXHIBIT 4-11
Entity Attributes in an ER Diagram
Reorder
point
Current
price
Product
Specification
Beginning
Quantity
Quantity date
Description
Inventory
Item #

23. The data tables will contain the recorded and maintained data that describe the essential components of an organization and its activities. These data will then be used the report information about and measurements of organizations events, resources, agents and locations.
Deciding how many relations are needed within the logical data repository. This decision is greatly simplified by reviewing the REAL conceptual data model and applying the following rule:
Each entity object (event, resource, agent and location) in the REAL model becomes a relation.
When you use the relational logical design, you link relations by placing the key attribute of one entity into the relation of the related entity. To key attributes hat are placed in another relation as foreign keys or posted keys. Purpose of foreign keys is to link relations so that the resulting relational tables can be used collectively to store business data and to generate useful information.

24. When defining relation attributes
Composite attributes
When defining relation attributes
Each relation should include only those attributes that describe the entity represented by the relation.
Second guideline for defining event-driven logical designs is :
Avoid including derivable non-key attributes in the relations
Derivable attributes are information items that can be calculated using other data items, so there is no need to store them as relation attributes
In the physical design phase we create the physical files, database, and programmed instructions. The implementation and maintenance phase of a systems project involve coding, testing, installing, documenting, training users, supporting users, and maintaining the system.

25. There are three parts to an IT application prototype:
The data storage structure
The forms and reports used for the recording maintaining, and reporting process
The detailed logic underlying the forms and reports that implement the business and information process rules
The following are typical steps in building an IT application prototype.

26. EXHIBIT 4-14
Linking an Order Recording Process With a Data Repository
Record
order
Order-Data
ORDER-INVENTORY
ORDER PERSONNEL
CUSTOMER
ORDER
INVENTORY

27. Sample Maintenance Processes and Data Access
EXHIBIT 4-15
Sample Maintenance Processes and Data Access
Update
Bank
data
Customer
Shipping
firm
Inventory
Bank-data
Customer-data
Shipping firm-data
Inventory data
BANK
CUSTOMER
SHIPPING FIRM
INVENTORY

28. Example of Generating a Sales by Sales Person Report
EXHIBIT 4-16
Example of Generating a Sales by Sales Person Report
Record
order
Request sales by-
sales person report
SALE-MERCHANDISE
SALES PERSON
SALE
INVENTORY
Sales by-
Sales person
Sales by salesperson = Report-Date + {Salesperson Name +
{Merchandise-Description + Qty-Sold + $ Contribution} } +
Total Sales + Total Contribution

29. These steps facilitate the development of a business event driven IT application prototype that can control the business process and perform the information processing required to support decision makers who are responsible for managing the process.
Some guidelines for developing prototypes:
Computer should display user-friendly interface
When instructing a computer to access a data pool, the program instructions should specify details regarding where the data area stored, the format of the data pool, and which field to access.
Most processing code should begin only after reviewing and validating the accessibility of the computer user
Source data automation techniques, copying data from existing data pools and having the computer automatically generate some fields, such as the data field or a sequentially numbered field, are methods to reduce human input error.
Programmers should ensure that proper backups and electronic audit trails are maintained at all times.

30. Reference
Hollander, A. S. Eric L. Denna, J. Owen Cherrington Accounting Information Technology, And Business Solutions. Irwin McGraw-Kill, New York-USA.