Business information systems analysis

1BIS AnalysisCopyright © 2003 Abou-Bakr Zayd

SYST 430: BIS Analysis & Development

Business Information Systems

Analysis

Abou-Bakr Zayd

[email protected]

Spring 2003


BIS & e-commerce Quality Life-Cycle

Qu

ality Life-C

ycle


AN

AL

YS

IS: D

ata & P

rocess M

od

eling

Data Flow Diagrams (DFD):

• DFD shows how data moves through an IS (what the system does) but doesn’t show program logic or processing steps (how it does it)

• That distinction is important because focusing on implementation issues at this point would restrict the search for the most effective system design


AN

AL

YS

IS: D

ata & P

rocess M

od

eling

Data Flow Diagrams (DFD): Symbols

Gane & Sarson Symbols Symbol Name Yourdon Symbols

Process

Bank Deposit Bank Deposit

Students Students

Apply

Payment

Apply

Payment

Customer Customer

Data Flow

Data Store

External Entity


AN

AL

YS

IS: R

equ

iremen

ts Mo

delin

g

Data Flow Diagrams (DFD): Process Symbol

• A Process receives I/P data & produces O/P data that has a different content

• Processes are black boxes that contain the business logic/rules that transforms the data & produce required results

Calculate

Gross

Pay

Hours Worked

Pay Rate

Gross Pay

Calculate

Gross

Pay

Hours Worked Pay Rate

Black Hole


AN

AL

YS

IS: R

equ

iremen

ts Mo

delin

g

Data Flow Diagrams (DFD): Data Flow Symbol

• A Data Flow is a path for data to move from one part of the IS to another

• A Data Flow in a DFD represent one or more data items; the diagram doesn’t show its structure & detailed contents

Grade Student Work

Submitted Work

Graded Work

Date of Birth Final GradeGrade Student Work

Student Grade

Gray Hole


AN

AL

YS

IS: R

equ

iremen

ts Mo

delin

g

Data Flow Diagrams (DFD): Data Store Symbol

• A Data Store is used to retain data because processes need to use the stored data at a later time

• DFD doesn’t show the detailed contents of a data store; the specific structure & data elements are defined in data dictionary

Create Invoice

Post Payment

Accounts Receivable

Invoice

Invoice Detail

Payment Detail

Courses

Students

Post Payment

Book Flight

Payments Passengers

Class List

Customer Payment

Flight Request


AN

AL

YS

IS: R

equ

iremen

ts Mo

delin

g

Data Flow Diagrams (DFD): External Entity Symbol

• An External Entity is a person, department, outside organization, or other IS that provides data or receives O/P

• External Entities show the boundaries of the IS and how it interacts with the outside world

Verify Order

Invoice

Customer Bank

Accounts Payments

Order

CustomerPayroll

Department

Employee

PaycheckPayment Bank

Deposit


AN

AL

YS

IS: D

ata & P

rocess M

od

eling

Data Flow Diagrams (DFD): Context Diagrams

• Based on fact-finding results gathered during requirements modeling (through different fact finding techniques), information about how various people, departments, data, and processes fit together to support business operations can now be represented graphically

• Context Diagram: is a top level view of an IS that shows system boundaries & scope

• To draw a context diagram, a single process symbol (process 0) that represents the entire IS is placed in the center of the page and all external entities are placed around the perimeter of the page then data flows are used to connect the entities to the central process


AN

AL

YS

IS: R

equ

iremen

ts Mo

delin

g

Data Flow Diagrams (DFD): Context Diagram

Grading System

Students Records System

Student

Instructor

0Graded Work

Class Roster

Submitted Work

Final Grade

Grade Report

Grading Parameters


AN

AL

YS

IS: R

equ

iremen

ts Mo

delin

g

Data Flow Diagrams (DFD): Diagram 0

Assign Final

Grade

Students Records System

Student

Instructor

2

Graded Work

Class Roster

Submitted Work

Final Grade

Grade Report

Grading Parameters

Establish Grade Book

Grade Student Work

Produce Grade Report

Grade Book

1 3

Grading Detail

Class Detail

Grade Book Student Grade

4


AN

AL

YS

IS: D

ata & P

rocess M

od

eling

Data Flow Diagrams (DFD): Strategies & Rules

• There are different strategies for developing a set of DFDs: – Top-Down– Bottom-Up

• Conventions for DFDs:– Each context diagram must fit in one page– The process name in the context diagram should be the name of the IS– Use unique names within each set of symbols– Do not cross lines– Use a unique reference number for each process symbol

• Balancing: preserving the I/P & O/P data flows of the parent on the child DFD


AN

AL

YS

IS: D

ata & P

rocess M

od

eling

Data Dictionary: Overview

• A set of DFDs produces a logical model of the system but the details within those DFDs are documented separately in a Data Dictionary

• A Data Dictionary or Data Repository is a central storehouse of information about the system’s data, where analysts collect, document & organize specific facts about the system including the contents of data flows, data stores, external entities & processes

• Data Dictionary defines & describes all data elements & meaningful combinations of data elements

• Data Element (item or field) is the smallest piece of data that has meaning within an IS (e.g. student grade, salary, social security number, account balance, company name)

• Data Elements are combined into records or data structures, where a Record is a meaningful combination of related data elements that is included in a data flow or data store


AN

AL

YS

IS: D

ata & P

rocess M

od

eling

Data Dictionary: Documenting Data Elements

• Data Element Name / Label• Alternate Names• Type & length• O/P format• Default value• Prompt, Column header, or Field Caption• Source• Security• Responsible user(s)• Acceptable values & data validation• Derivation formula• Description / Comments


AN

AL

YS

IS: D

ata & P

rocess M

od

eling

Data Dictionary: Documenting Data Flows

• Data flow Name / Label• Alternate Names• Description• Origin / Source• Destination• Record• Volume & frequency


AN

AL

YS

IS: D

ata & P

rocess M

od

eling

Data Dictionary: Documenting Data Stores

• Data Store Name / Label• Alternate Names• Description• I/P Data flows• O/P Data flows• Record• Volume & frequency


AN

AL

YS

IS: D

ata & P

rocess M

od

eling

Data Dictionary: Documenting Processes

• Process Name / Label• Purpose / Description• Process Number• I/P Data flows• O/P Data flows• Process Description


AN

AL

YS

IS: D

ata & P

rocess M

od

eling

Data Dictionary: Documenting External Entities

• External Entity Name• Alternate Names• Description• I/P Data flows• O/P Data flows


AN

AL

YS

IS: D

ata & P

rocess M

od

eling

Data Dictionary: Documenting Records

• Records or Data Structure Name• Alternate Names• Definition / Description• Record content or composition


AN

AL

YS

IS: O

bject M

od

eling

Object Oriented Concepts: Overview

• Object Oriented analysis describes IS by identifying things called objects that can represent a real person, place, event or transaction (e.g. patient makes appointment with a doctor: all 3 are objects)

• The Object Oriented analysis is a new approach that sees a system from the viewpoint of the objects themselves as they function & interact with system

• The end product of Object Oriented analysis is an Object Model, which represents the IS in terms of Objects & Object Oriented concepts

• The main benefit of Object Oriented approach is using objects and program code modules that can be reused

• Structured Analysis modeling using DFDs treated data & processes separately, while in Object Oriented analysis, Objects include data & the processes that affect that data; Attributes that characterize the object & Methods that the object performs when it receives a message


AN

AL

YS

IS: O

bject M

od

eling

Object Oriented Concepts: Objects

STUDENT

STUDENT Object

Attributes

Methods

Student NumberNameTelephoneDate of BirthFitness RecordStatus

Add fitness classDrop fitness classChange telephoneChange statusUpdate fitness record

Instances of the STUDENT

Object

970075Soha Sayed010500500010-10-80XCurrent

Characteristics that describe

the STUDENT Object

Tasks that the STUDENT Object can

perform

Encapsulation means that all data & methods

are self contained making the object appear

as a black box


AN

AL

YS

IS: O

bject M

od

eling


INSTRUCTOR

INSTRUCTOR Object

Attributes

Methods

Instances of the INSTRUCTOR

Object

101Zaki Morad0101001000AerobicsPart TimeCurrent

Characteristics that describe the INSTRUCTOR

Object

Tasks that the INSTRUCTOR

Object can perform

Instructor NumberNameTelephoneFitness Class taughtavailabilityStatus

Teach fitness classChange telephoneChange availabilityChange status


AN

AL

YS

IS: O

bject M

od

eling


FITNESS CLASS SCHEDULE

Fitness Class Schedule Object

Attributes

Methods

Fitness Class NumberDateTimeTypeLocationInstructor NumberMax Enrollment

Add fitness classDelete fitness classChange dateChange timeChange InstructorChange LocationChange Enrollment

REGISTRATION RECORD

Registration Record Object

Attributes

Student NumberFitness Class NumberRegistration DateFeeStatus

Methods

Add StudentDrop StudentNotify Instructor of addNotify Instructor of dropNotify all of fitness-class cancellations


AN

AL

YS

IS: O

bject M

od

eling

Object Oriented Concepts: Attributes

STUDENT Object

State

Future Registered but has not started to attendCurrent Registered attending 1 or more classesPast Attended 1 or more classes in the past

Status


AN

AL

YS

IS: O

bject M

od

eling

Object Oriented Concepts: Methods

Method: Steps

Add Student

1. Add new student instance

2. Record student number

3. Record student name

4. Record student telephone number

5. Record student date of birth

6. Record sex of student

7. Record state of student

8. Save new student data


AN

AL

YS

IS: O

bject M

od

eling

Object Oriented Concepts: Messages

STUDENT

Attributes

Methods


Add studentDelete studentAdd fitness classDrop fitness classChange telephoneChange statusUpdate fitness record

Message: ADD tells the

STUDENT class to perform all the steps needed to add a STUDENT

instance

Message: DELETE tells the STUDENT class to perform all the steps needed to delete a STUDENT

instance

Polymorphism is the concept when a

message gives different meanings to different

objects


AN

AL

YS

IS: O

bject M

od

eling

Object Oriented Concepts: Classes

VEHICULE

Attributes

Methods

MakeModelYearWeightcolor

StartStoppark

Attributes

Car

Attributes

Load Limit

Truck

Attributes

Emergency Exit Location

School Bus

Uncommon Attributes

Uncommon Attributes

Common Attributes

Common Methods


AN

AL

YS

IS: O

bject M

od

eling

Relationship among Objects & Classes: Dependency

School Bus

Attributes

Methods

Bus NumberRoute NumberStart TimeFinish TimeDriver

Pick UpDrop Off

Bus Route

Attributes

Route NumberStop NumberStop LocationStop TimePassengers

Methods

Add StopDelete StopChange Time

Dependency

Follows


AN

AL

YS

IS: O

bject M

od

eling

Relationship among Objects & Classes: Association

Student

Attributes

Methods


Add StudentDelete StudentAdd fitness classDrop fitness classChange telephoneChange statusUpdate fitness record

Registration Record

Attributes

Student NumberFitness Class NumberRegistration DateFeeStatus

Methods

Add StudentDrop StudentNotify Instructor of addNotify Instructor of dropNotify all of fitness-class cancellations

Association

Adds/Drops Fitness Class


AN

AL

YS

IS: O

bject M

od

eling

Relationship among Objects & Classes: Aggregation

Employee

Attributes

Methods

NameDate of BirthSocial Security NumberTelephoneHire DateTitlePay RateDepartment

Get HiredTerminateChange Department

Department

Attributes

Department NumberDepartment NameBudget CodeDepartment HeadEmployees

Methods

Prepare BudgetHire EmployeesDevelop Plans

Aggregation

Belongs To


AN

AL

YS

IS: O

bject M

od

eling

Relationship among Objects & Classes: Inheritance

Employee

Attributes

Methods

Social Security NumberTelephoneHire DateTitlePay Rate

Get HiredGet FiredChange Telephone

Instructor

Attributes

Type of instructorSocial Security NumberTelephoneHire DateTitlePay Rate

MethodsGet HiredGet FiredChange Telephone

Inheritance


UML: Use Case Modeling

AN

AL

YS

IS: O

bject M

od

eling

Produce Fitness Class Roster

StudentAdd Fitness Class

<<uses>>

InstructorChange Availability

<<uses>>

Update Instructor Information

Use Case Modeling Examples


AN

AL

YS

IS: O

bject M

od

eling

UML: Use Case Modeling

Add New StudentAdd New Student Use Case

Name:

Successful Completion:

1. Managers Checks Fitness-Class Schedule object for availability2. Managers notifies student3. Fitness-Class is open and student pays fee4. Manager registers student

Alternative: 1. Managers Checks Fitness-Class Schedule object for availability2. Fitness-Class is full3. Managers notifies student

Add New Student

Actor: Student/Manager

Description: Describes the process used to add a student to a fitness class

Precondition: Student requests fitness class

Postcondition: Describes the process used to add a student to a fitness class

Assumptions: None

Use Case Description to document the process


AN

AL

YS

IS: D

ata & P

rocess M

od

eling

UML: Use Case Diagrams

Student Instructor

Manager

Add Fitness Class

Add Instructor

Change Schedule

Adds Notifies

Notifies

NotifiesNotifies

Notifies

Get Assigned

Check and

updateUse Case Diagram a visual summary of several related use

cases within a system or subsystem


AN

AL

YS

IS: D

ata & P

rocess M

od

eling

UML: Class Diagrams

Sales Manager

Attributes

Methods

Sales Rep

Attributes

Methods

Sales Office

Attributes

Methods

Customer

Attributes

Methods

Order

Attributes

Methods

Items Ordered

Attributes

Methods

1

1

11

1

1..*0..*

0..*

0..*

0..*

0..*

1

Manages

Assigned to

AssignedManages

Places

Includes

Class Diagrams a detailed view of a

single use case, and the relationship

among the classes


AN

AL

YS

IS: D

ata & P

rocess M

od

eling

UML: Sequence Diagrams

Student ManagerFitness-Class

ScheduleRegistration

Record

Request Fitness-Class

Notify

Pay

Check

Register

Focus

Sequence Diagrams: a dynamic model of a single use case, showing interaction among

classes during a specified time period

Messages


AN

AL

YS

IS: D

ata & P

rocess M

od

eling

UML: State Transition Diagrams

Future Current Past

EnrollsAttends

Fitness-Class

Drops Fitness-Class

Drops Fitness-Class

Fitness-Class Canceled

Inactivity for 12 months

State Transition Diagram: shows how an object changes

from one state to another, depending on events that affect

the object


AN

AL

YS

IS: D

ata & P

rocess M

od

eling

UML: Activity Diagrams

Customer inserts

ATM card

Customer enters PIN

Customer requests

cash

Customer needs cash

Card is accepted

PIN is accepted

ATM adjusts balance

ATM provides

cash

ATM notifies

customer

Sufficient funds available

Sufficient funds not available

Activity Diagrams: resembles a horizontal flow chart that shows

the actions & events as they occur, their order and outcomes


AN

AL

YS

IS: D

ata & P

rocess M

od

eling

Completion of Systems Analysis:

• Systems Requirements Document: – contains the requirements for the new system, describes the alternatives

that were considered and makes a specific recommendation to management.

– This important document is the starting point for measuring the performance, accuracy & completeness of the finished system before entering the system design phase

– It represents the contract that identifies what must be delivered by system developers to users

• Presentation to Management– Begin with purpose & primary goals & objectives of the system– Summarize the primary viable alternatives including cost, advantages &

disadvantages– Chosen alternative and explanation

• Management decision: – Develop in-house system– Modify current system– Purchase / customize S/W package– Perform additional systems analysis work– Stop all further work


AN

AL

YS

IS: D

ata & P

rocess M

od

eling

Transition to Systems Design

• The transition from systems analysis to design is the transition from the logical design to the physical design of the system

• Logical Design (conceptual design or essential model): defines the functions & features of the system and the relationships among its components. It includes the system’s O/P produced, I/P needed, and processes performed without regard to how tasks will be accomplished physically and methods of implementation (What? Completed in Analysis Phase)

• Physical design (functional design): is a plan for the actual implementation of the system. It is built on the system’s logical design and describes the implementation of a specific set of systems components (How? Completed in Design Phase)

• Logical & Physical Design are closely related as good systems design is impossible without careful & accurate systems analysis. In fact, the design phase typically cannot begin until analysis work is complete


AN

AL

YS

IS: R

eferences

• H. Deitel, P. Deitel & K. Steinbuhler, e-Business and e-Commerce for Managers, 2001

• G. Shelly, T. Cashman & H. Rosenblatt, Systems Analysis and Design (4th), 2000

• J. Whitten, L. Bentley & K. Dittman, Systems Analysis and Design Methods (5th), 2000

Business information systems analysis

Technology

Transcript of Business information systems analysis