System Analysis Overview Document functional requirements by

creating models

Two concepts help identify functional requirements in the traditional approach and object-oriented approach

Events that trigger use cases

Things in the users’ work domain

Models and Modeling Analyst describes information system

requirements using a collection of models Complex systems require more than one type of

model Models represent some aspect of the system

being built Process of creating models helps analyst clarify

and refine design Models assist communication with system users

Why modeling? Learning from modeling process Reduce complexity by abstraction Remembering the details Communicating with other team

members, users, and stakeholders Documenting what was done for

future maintenance/enhancement

Types of Models Different types of models are used in

information systems development Mathematical – formulas that describe

technical aspects of the system Descriptive – narrative memos, reports, or

lists that describe aspects of the system Graphical – diagrams and schematic

representations of some aspect of the system

Events

Business events trigger elementary business processes (EBPs)

EBPs are at correct level of analysis for use cases

Business events are memorable, can be described, and occur at a specific time and place

Sequence of “Transactions” for One Specific Customer Resulting in Many Events

Types of Events

External Outside system Initiated by external agent or actor

Temporal Occur as result of reaching a point in time Based on system deadlines

State Something inside system triggers

processing need

Events Affecting a Charge Account Processing System

Events modeling Identify business events to decompose system

into activities/use cases Use cases (activities) are identified from user

goals and business events that trigger elementary business processes

Event decomposition is, therefore, used by Traditional approach to identify activities OO approach to identify use cases

Event table records event, trigger, source, use case, response, and destination

Information about Each Event

in an Event Table

Things “Things” are what user deals with and

system remembers, such as an order placed by a customer

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?

Types of Things

Modeling things Traditional approach uses entity-

relationship diagrams (ERD) for data entities, attributes of data entities, and relationships between entities

Object-oriented approach uses UML class diagrams for classes, attributes, methods of class, and associations among classes

Traditional and OO Approach

Components of a Traditional Analysis Model

Data Flow Diagrams (DFDs) Graphical system model that shows all

main requirements for an IS in one diagram Inputs/outputs Processes Data storage

Easy to read and understand with minimal training

Data Flow Diagram Symbols

DFD Integrates Event Table and ERD

DFD and Levels of Abstraction Data flow diagrams (DFDs) are

decomposed into additional diagrams to provide multiple levels of detail

Higher-level diagrams provide general views of system

Lower-level diagrams provide detailed views of system

Differing views are called levels of abstraction

Layers of DFD Abstraction for Course Registration

Context Diagrams DFD that summarizes all processing

activity for the system or subsystem Highest level (most abstract) view of

system Shows system boundaries System scope is represented by a

single process, external agents, and all data flows into and out of the system

Context Diagram

External entity

External entity

External entity

The System

Data Flow

Data Flow

Data Flow

Data Flow

DFD Fragments Created for each use case in the event

table Represent system response to one

event within a single process symbol Self-contained models Focus attention on single part of system Show only data stores required in the

use case

Three Separate DFD Fragments for Course

Registration System

Event-Partitioned System Model

DFD to model system requirements using single process for each use case/activity in system or subsystem

Combines all DFD fragments together to show decomposition of the context-level diagram

Sometimes called “diagram 0” Used primarily as a presentation tool Decomposed into more detailed DFD fragments

Combining DFD Fragments to Create Event- Partitioned System Model

Decomposing DFD Fragments

Most DFD fragments can be further described using structured English

Sometimes DFD fragments need to be diagrammed in more detail

Decomposed into subprocesses in a detailed DFD

Layers of DFD Abstraction for Course Registration

DFD Practice Precision tools sells a line of high-quality

woodworking tools. When customers place orders on the company’s web site, the system checks to see if the items are in stock, issues a status message to the customer, and generates a shipping order to the warehouse, which fills the order. When the order is shipped, the customer is billed. The system also produces various reports.

DFD Practice Draw a context diagram

System scope is represented by a single process, external agents, and all data flows into and out of the system

Draw Level-0 diagram Identify the major use cases Draw DFD fragment for each use case Combine DFD fragments together at the

same level of detail

Context Diagram

Five Separate DFD Fragments

Detailed DFD for Create new order

Evaluating DFD Quality Readable Internally consistent and balanced Accurately represents system

requirements Reduces information overload –

rule of 7 +/- 2 Minimizes required number of

interfaces

Data Flow Consistency Problems Differences in data flow content

between a process and its process decomposition

Data outflows without corresponding inflows

Data inflows without corresponding outflows

Results in unbalanced DFDs

Consistency Rules All data that flows into a process must

Flow out of the process, or Be used to generate data that flows out of

the process All data that flows out of a process

must Have flowed into the process, or Have been generated from data that

flowed into the process

Unnecessary Data Input: Black Hole

Process with Impossible Data Output: A Miracle

Process with Unnecessary Data Input

Process with Impossible Data Output

Documentation of DFD Components

Lowest-level processes need to be described in detail

Data flow contents need to be described Data stores need to be described in terms

of data elements Each data element needs to be described Various options for process definition exist

Structured English

Method of writing process specifications Combines structured programming

techniques with narrative English Well-suited for lengthy sequential

processes or simple control logic (single loop or if-then-else)

Ill-suited for complex decision logic or few (or no) sequential processing steps

Structured English Process Description

Decision Tables and Decision Trees Can summarize complex decision logic better than

structured English Incorporate logic into the table or tree structure to

make descriptions more readable

Decision Tables

Decision Tree

Decision Tables for Calculating Shipping Charges

Decision Tree for Calculating Shipping Charges

Data Flow Definitions Textual description of data flow’s content and internal structure Often coincide with attributes of data entities included in ERD plus

computed values Algebraic notion describes data elements on data flow plus data

structure

Data Element Definitions Data type description

String, integer, floating point, Boolean Sometimes very specific written

description Length of element Maximum and minimum values Data dictionary – repository for

definitions of data flows, data stores, and data elements

Data Element Definition

Physical and Logical DFDs Logical model

Assumes implementation in ideal situation Does not tell how system is implemented

Physical model Describes assumptions about

implementation technology Developed in last stages of analysis or in

early design Current physical -> Current logical -> New

logical -> New physical

Summary Data flow diagrams (DFDs) are used in

combination with event table and entity-relationship diagram (ERD) to model system requirements

DFDs model system as set of processes, data flows, external agents, and data stores

DFDs easy to read – graphically represent key features of system using small set of symbols

Assignment 2 Draw a context diagram of the proposed

student housing system Draw a level-0 data flow diagram.

Specify the main functions of the system (data flow, process, and data store).

Draw a level-1 data flow diagram for the process of student searching for houses.

Use of drawing tools

http://www.homes4students.ca/add_a_listing.html

http://www.homes4students.ca/ontario.html