kipram 1

BAB IIIDATA MODELING dan

ANALYSIS

kipram 2

Performing Requirements Determination

Gather information on what system should do from many sources� Users� Reports

� Forms� Procedures

A. Determining System Requirements

kipram 3

Performing Requirements Determination

Characteristics for gathering requirements� Impertinence

� Question everything

� Impartiality� Find the best organizational solution

� Relaxation of constraints� Attention to detail� Reframing

� View the organization in new ways

kipram 4

Deliverables and OutcomesTypes of deliverables:� Information collected from users� Existing documents and files� Computer-based information� Understanding of organizational components

� Business objective� Information needs� Rules of data processing� Key events

kipram 5

Traditional Methods for Determining Requirements

Interviewing and Listening� Gather facts, opinions and speculations� Observe body language and emotions� Guidelines

� Plan� Checklist� Appointment

� Be neutral� Listen� Seek a diverse view

kipram 6

Traditional Methods for Determining Requirements

Interviewing (Continued)� Interview Questions

� Open-Ended� No pre-specified answers

� Close-Ended� Respondent is asked to choose from a set of specified

responses

� Additional Guidelines� Do not phrase questions in ways that imply a wrong or

right answer� Listen very carefully to what is being said� Type up notes within 48 hours� Do not set expectations about the new system

kipram 7

Traditional Methods for Determining Requirements

Administering Questionnaires� More cost-effective than interviews� Choosing respondents

� Should be representative of all users� Types of samples

� Convenient� Random sample� Purposeful sample� Stratified sample

kipram 8

Traditional Methods for Determining Requirements

Questionnaires� Design

� Mostly closed-ended questions� Can be administered over the phone or in

person

� Vs. Interviews� Interviews cost more but yield more information� Questionnaires are more cost-effective� See table 7-4 for a complete comparison

kipram 9

Traditional Methods for Determining Requirements

Interviewing Groups� Advantages

� More effective use of time� Enables people to hear opinions of others and to agree

or disagree

� Disadvantages� Difficulty in scheduling

� Nominal Group Technique� Facilitated process to support idea generation by groups� Individuals work alone to generate ideas which are

pooled under guidance of a trained facilitator

kipram 10

Traditional Methods for Determining Requirements

Directly Observing Users� Serves as a good method to supplement

interviews� Often difficult to obtain unbiased data

� People often work differently when being observed

kipram 11

Analyzing Procedures and Other Documents

Types of information to be discovered:� Problems with existing system� Opportunity to meet new need� Organizational direction� Names of key individuals� Values of organization� Special information processing circumstances� Reasons for current system design� Rules for processing data

kipram 12

Analyzing Procedures and Other Documents

Four types of useful documents� Written work procedures

� Describes how a job is performed� Includes data and information used and created in the

process of performing the job or task

� Business form� Explicitly indicate data flow in or out of a system

� Report � Enables the analyst to work backwards from the report to

the data that generated it

� Description of current information system

kipram 13

Modern Methods for Determining Requirements

Joint Application Design (JAD)� Brings together key users, managers and systems

analysts� Purpose: collect system requirements

simultaneously from key people� Conducted off-site

Prototyping� Repetitive process� Rudimentary version of system is built� Replaces or augments SDLC� Goal: to develop concrete specifications for

ultimate system

kipram 14

Joint Application Design (JAD)Participants� Session Leader� Users� Managers� Sponsor� Systems Analysts� Scribe� IS Staff

kipram 15

Joint Application Design (JAD)End Result� Documentation detailing existing system

� Features of proposed system

CASE Tools During JAD� Upper CASE tools are used � Enables analysts to enter system models directly into CASE

during the JAD session� Screen designs and prototyping can be done during JAD

and shown to users

Supporting JAD with GSS� Group support systems (GSS) can be used to enable more

participation by group members in JAD� Members type their answers into the computer� All members of the group see what other members have

been typing

kipram 16

Prototyping

Quickly converts requirements to working version of systemOnce the user sees requirements converted to system, will ask for modifications or will generate additional requestsMost useful when:� User requests are not clear� Few users are involved in the system� Designs are complex and require concrete form� History of communication problems between

analysts and users� Tools are readily available to build prototype

kipram 17

Prototyping

Drawbacks� Tendency to avoid formal documentation� Difficult to adapt to more general user

audience

� Sharing data with other systems is often not considered

� Systems Development Life Cycle (SDLC) checks are often bypassed

kipram 18

Business Process Reengineering (BPR)Search for and implementation of radical change in business processes to achieve breakthrough improvements in products and services

Goals� Reorganize complete flow of data in major sections of an

organization� Eliminate unnecessary steps� Combine steps� Become more responsive to future change

7.187.18

Identification of processes to reengineer� Key business processes

� Set of activities designed to produce specific output for a particular customer or market

� Focused on customers and outcome� Same techniques are used as were used for requirements

determination

kipram 19

Business Process Reengineering (BPR)

Identify specific activities that can be improved through BPRDisruptive technologies� Technologies that enable the breaking of

long-held business rules that inhibit organizations from making radical business changes

�

kipram 20

B. Structuring System Requirements:1. Process Modeling

kipram 21

Process ModelingGraphically represent the processes that capture, manipulate, store and distribute data between a system and its environment and among system components

Data flow diagrams (DFD)� Graphically illustrate movement of data between

external entities and the processes and data stores within a system

Modeling a system’s process� Utilize information gathered during requirements

determination� Structure of the data is also modeled in addition to the

processes

Deliverables and Outcomes� Set of coherent, interrelated data flow diagrams

kipram 22

Process Modeling

Deliverables and outcomes (continued)� Context data flow diagram (DFD)

� Scope of system� DFDs of current system

� Enables analysts to understand current system� DFDs of new logical system

� Technology independent� Show data flows, structure and functional requirements of

new systemProject dictionary and CASE repository

kipram 23

Data Flow Diagramming Mechanics

Four symbols are used� See Figure 8-2� Two different standard sets can be used

� DeMarco and Yourdan� Gane and Sarson

kipram 24

Figure 8-2Comparison of DeMarco & Yourdan and Gane &

Sarson DFD symbol sets

kipram 25

Data Flow Diagramming MechanicsData Flow� Depicts data that are in motion and moving as a unit from

one place to another in the system.� Drawn as an arrow� Select a meaningful name to represent the data

Data Store� Depicts data at rest� May represent data in

� File folder� Computer-based file� Notebook

� The name of the store as well as the number are recorded in between lines

kipram 26

Data Flow Diagramming MechanicsProcess� Depicts work or action performed on data so that they are

transformed, stored or distributed� Number of process as well as name are recorded

8.268.26

Source/Sink� Depicts the origin and/or destination of the data� Sometimes referred to as an external entity� Drawn as a square symbol� Name states what the external agent is� Because they are external, many characteristics are not of

interest to us

kipram 27

Data Flow Diagramming Definitions

Context Diagram� A data flow diagram (DFD) of the scope of an

organizational system that shows the system boundaries, external entities that interact with the system and the major information flows between the entities and the system

Level-O Diagram� A data flow diagram (DFD) that represents a

system’s major processes, data flows and data stores at a high level of detail

kipram 28

Developing DFDs: An Example

Hoosier Burger’s automated food ordering systemContext Diagram (Figure 8-4) contains no data storesNext step is to expand the context diagram to show the breakdown of processes (Figure 8-5)

kipram 29

Figure 8-4Context diagram of Hoosier Burger’s

food ordering system

kipram 30

Figure 8-5Level-0 DFD of Hoosier Burger’s food ordering system

kipram 31

Data Flow Diagramming Rules

Basic rules that apply to all DFDs� Inputs to a process are always different

than outputs� Objects always have a unique name

� In order to keep the diagram uncluttered, you can repeat data stores and sources/sinks on a diagram

kipram 32

Data Flow Diagramming RulesProcess� No process can have

only outputs (a miracle)

� No process can have only inputs (black hole)

� A process has a verb phrase label

Data Store� Data cannot be moved

directly from one store to another

� Data cannot move directly from an outside source to a data store

� Data cannot move directly from a data store to a data sink

� Data store has a noun phrase label

kipram 33

Data Flow Diagramming RulesSource/Sink� Data cannot move

directly from a source to a sink

� A source/sink has a noun phrase label

Data Flow� A data flow has only one

direction of flow between symbols

� A fork means that exactly the same data goes from a common location to two or more processes, data stores or sources/sinks

kipram 34

Data Flow Diagramming RulesData Flow (Continued)L. A join means that exactly the same data comes

from any two or more different processes, data stores or sources/sinks to a common location

M. A data flow cannot go directly back to the same process it leaves

N. A data flow to a data store means updateO. A data flow from a data store means retrieve or

useP. A data flow has a noun phrase label

kipram 35

Decomposition of DFDsFunctional decomposition� Act of going from one single system to many

component processes� Repetitive procedure� Lowest level is called a primitive DFD

Level-N Diagrams� A DFD that is the result of n nested

decompositions of a series of subprocesses from a process on a level-0 diagram

kipram 36

Balancing DFDsWhen decomposing a DFD, you must conserve inputs to and outputs from a process at the next level of decompositionThis is called balancingExample: Hoosier Burgers� In Figure 8-4, notice that there is one input to the

system, the customer order� Three outputs:

� Customer receipt� Food order� Management reports

kipram 37

Balancing DFDs

Example (Continued)� Notice Figure 8-5. We have the same

inputs and outputs� No new inputs or outputs have been

introduced� We can say that the context diagram and

level-0 DFD are balanced

kipram 38

Balancing DFDs

An unbalanced example� Figure 8-10� In context diagram, we have one input to

the system, A and one output, B

� Level-0 diagram has one additional data flow, C

� These DFDs are not balanced

kipram 39

Figure 8-10An unbalanced set of data flow diagrams

(a) Context diagram(b) Level-0 diagram

kipram 40

Balancing DFDs

We can split a data flow into separate data flows on a lower level diagram (see Figure 8-11)Balancing leads to four additional advanced rules (See Table 8-3)

kipram 41

Four Different Types of DFDS

Current Physical� Process label includes an identification of

the technology (people or systems) used to process the data

� Data flows and data stores are labeled with the actual name of the physical media on which data flow or in which data are stored

kipram 42

Four Different Types of DFDS

Current Logical� Physical aspects of system are removed as much

as possible� Current system is reduced to data and processes

that transform them

New Logical� Includes additional functions� Obsolete functions are removed� Inefficient data flows are reorganized

New Physical� Represents the physical implementation of the

new system

kipram 43

Guidelines for Drawing DFDsCompleteness� DFD must include all components

necessary for system� Each component must be fully described in

the project dictionary or CASE repository

Consistency� The extent to which information contained

on one level of a set of nested DFDs is also included on other levels

kipram 44

Guidelines for Drawing DFDsTiming� Time is not represented well on DFDs� Best to draw DFDs as if the system has never

started and will never stop.

Iterative Development� Analyst should expect to redraw diagram several

times before reaching the closest approximation to the system being modeled

Primitive DFDs� Lowest logical level of decomposition� Decision has to be made when to stop

decomposition

kipram 45

Guidelines for Drawing DFDs

Rules for stopping decomposition� When each process has been reduced to a

single decision, calculation or database operation

� When each data store represents data about a single entity

� When the system user does not care to see any more detail

kipram 46

Guidelines for Drawing DFDsRules for stopping decomposition (continued)� When every data flow does not need to be split

further to show that data are handled in various ways

� When you believe that you have shown each business form or transaction, on-line display and report as a single data flow

� When you believe that there is a separate process for each choice on all lowest-level menu options

kipram 47

Using DFDs as Analysis Tools

Gap Analysis� The process of discovering discrepancies

between two or more sets of data flow diagrams or discrepancies within a single DFD

Inefficiencies in a system can often be identified through DFDs

kipram 48

Using DFDs in Business Process Reengineering

Example: IBM Credit� See Figure 8-20 – before reengineering� Credit approval process required six days

before BPR� Figure 8-21 depicts DFD after

reengineering� IBM was able to process 100 times the

number of transactions in the same amount of time

kipram 49

Oracle’s Process Modeler and Functional Hierarchy Diagrams

Process Modeler� Unique to Oracle� Similar to DFDS but outputs and methods differ in

several ways.� Table 8-4 illustrates differences

Functional Hierarchy Diagrams� Picture of various tasks performed in a business

and how they are related� Tasks are broken down into their various parts� Does not include data flows

kipram 50

Simple Data Flow Diagram

Data flow

Process

External agent

(entity)

Data store (internal entity)

kipram 51

Process Decomposition

kipram 52

Decomposition Diagrams

kipram 53

Illegal Data Flows

Practice data flow conservation –only data needed should move

kipram 54

SummaryData flow diagrams (DFD)� Symbols� Rules for creating� Decomposition� Balancing

Four different kinds of DFDs� Current Physical� Current Logical� New Logical� New Physical

kipram 55

Summary

DFDs for AnalysisDFDs for Business Process Reengineering (BPR)Oracle’s Process ModelerFunctional Hierarchy Diagrams

8.558.55

kipram 56

2. Logic Modeling

kipram 57

Logic Modeling

Data flow diagrams do not show the logic inside the processesLogic modeling involves representing internal structure and functionality of processes depicted on a DFDLogic modeling can also be used to show when processes on a DFD occur

kipram 58

Logic Modeling

Deliverables and Outcomes� Structured English� Decision Tables

� Decision Trees� State-transition diagrams

� Sequence diagrams� Activity diagrams

kipram 59

Modeling Logic with Structured English

Modified form of English used to specify the logic of information processesUses a subset of English� Action verbs� Noun phrases

� No adjectives or adverbs

No specific standards

kipram 60

Modeling Logic with Structured English

Similar to programming language� If conditions� Case statements

Figure 9-3 shows Structured English representation for Hoosier Burger

kipram 61

Modeling Logic withDecision Tables

A matrix representation of the logic of a decisionSpecifies the possible conditions and the resulting actionsBest used for complicated decision logic

Consists of three parts� Condition stubs

� Lists condition relevant to decision� Action stubs

� Actions that result from a given set of conditions� Rules

� Specify which actions are to be followed for a given set of conditions

kipram 62

Modeling Logic withDecision Tables

Indifferent Condition� Condition whose value does not affect which

action is taken for two or more rules

Standard procedure for creating decision tables� Name the condition and values each condition can

assume� Name all possible actions that can occur� List all rules� Define the actions for each rule� Simplify the table

kipram 63

Figure 9-4Complete decision table for payroll system example

kipram 64

Modeling Logic with Decision Trees

A graphical representation of a decision situationDecision situation points are connected together by arcs and terminate in ovalsTwo main components� Decision points represented by nodes� Actions represented by ovals

kipram 65

Modeling Logic with Decision Trees

Read from left to rightEach node corresponds to a numbered choice on a legendAll possible actions are listed on the far right

kipram 66

Figure 9-9Decision tree representation of the decision logic in the decision tables in Figures 9-4 and 9-5, with only two choices per decision

point

kipram 67

Deciding Among Structured English, Decision Tables and Decision Trees

BestBestThird BestChecking Consistency and Completeness

BestThird BestBestTransforming Conditions and Actions into Sequence

BestThird BestSecond BestDetermining Conditions and Actions

Decision Trees

Decision Tables

Structured English

Criteria

kipram 68

Summary

Several methods of logic modeling� Structured English

� Primarily communication technique for analysts and users

� Decision Tables� Conditions are listed in condition stubs� Possible actions are listed in action stubs� Rules link conditions with actions

kipram 69

Summary

Decision Tables� Lists all possible rules

Decision Trees� Conditions are portrayed by decision points

� Values are represented by paths between decision points and ovals that contain actions

kipram 70

Summary

Comparison of Structured English, Decision Tables and Decision Trees� Most studies show that decision trees are

best for many criteria� There is no best technique

� Analyst must be proficient in all three

kipram 71

C. Conceptual Data Modeling

kipram 72

Learning Objectives�Define key data modeling terms

� Entity type� Attribute� Multivalued attribute� Relationship� Degree� Cardinality� Business Rule� Associative entity� Trigger� Supertype� Subtype

kipram 73

Conceptual Data Modeling

Representation of organizational dataPurpose is to show rules about the meaning and interrelationships among dataEntity-Relationship (E-R) diagrams are commonly used to show how data are organizedMain goal of conceptual data modeling is to create accurate E-R diagramsMethods such as interviewing, questionnaires and JAD are used to collect informationConsistency must be maintained between process flow, decision logic and data modeling descriptions

kipram 74

Process of Conceptual Data Modeling

First step is to develop a data model for the system being replacedNext, a new conceptual data model is built that includes all the requirements of the new systemIn the design stage, the conceptual data model is translated into a physical designProject repository links all design and data modeling steps performed during SDLC

kipram 75

Deliverables and Outcome

Primary deliverable is the entity-relationship diagramThere may be as many as 4 E-R diagrams produced and analyzed during conceptual data modeling� Covers just data needed in the project’s

application� E-R diagram for system being replaced� An E-R diagram for the whole database from

which the new application’s data are extracted� An E-R diagram for the whole database from

which data for the application system being replaced is drawn

kipram 76

Figure 10-3Sample conceptual data model diagram

kipram 77

Deliverables and OutcomeSecond deliverable is a set of entries about data objects to be stored in repository or project dictionary� Repository links data, process and logic models of

an information system� Data elements that are included in the DFD must

appear in the data model and visa versa� Each data store in a process model must relate to

business objects represented in the data model

kipram 78

Gathering Information for Conceptual Data Modeling

Two perspectives� Top-down

� Data model is derived from an intimate understanding of the business

� Bottom-up� Data model is derived by reviewing

specifications and business documents

kipram 79

Introduction to Entity-Relationship (E-R) Modeling

Notation uses three main constructs� Data entities� Relationships

� Attributes

Entity-Relationship (E-R) Diagram� A detailed, logical representation of the

entities, associations and data elements for an organization or business

kipram 80

Entity-Relationship (E-R) ModelingKey TermsEntity

� A person, place, object, event or concept in the user environment about which the organization wishes to maintain data

� Represented by a rectangle in E-R diagrams

Entity Type� A collection of entities that share common

properties or characteristics

Attribute� A named property or characteristic of an entity that

is of interest to an organization

kipram 81

Entity-Relationship (E-R) ModelingKey TermsCandidate keys and identifiers

� Each entity type must have an attribute or set of attributes that distinguishes one instance from other instances of the same type

� Candidate key� Attribute (or combination of attributes) that

uniquely identifies each instance of an entity type

kipram 82

Entity-Relationship (E-R) ModelingKey Terms

Identifier� A candidate key that has been selected as the

unique identifying characteristic for an entity type� Selection rules for an identifier

1. Choose a candidate key that will not change its value2. Choose a candidate key that will never be null3. Avoid using intelligent keys4. Consider substituting single value surrogate keys for

large composite keys

kipram 83

Entity-Relationship (E-R) ModelingKey Terms

Multivalued Attribute� An attribute that may take on more than

one value for each entity instance

� Represented on E-R Diagram in two ways:� double-lined ellipse� weak entity

kipram 84

Entity-Relationship (E-R) ModelingKey TermsRelationship

� An association between the instances of one or more entity types that is of interest to the organization

� Association indicates that an event has occurred or that there is a natural link between entity types

� Relationships are always labeled with verb phrases

kipram 85

Conceptual Data Modeling and the E-R Diagram

Goal� Capture as much of the meaning of the data as

possible

Result� A better design that is easier to maintain

kipram 86

Degree of Relationship

Degree� Number of entity types that participate in a

relationship

Three cases� Unary

� A relationship between two instances of one entity type

� Binary� A relationship between the instances of two entity types

� Ternary� A simultaneous relationship among the instances of

three entity types� Not the same as three binary relationships

10.8610.86

kipram 87

Figure 10-6Example relationships of different degrees

kipram 88

Cardinality

The number of instances of entity B that can be associated with each instance of entity AMinimum Cardinality� The minimum number of instances of entity B that

may be associated with each instance of entity A

Maximum Cardinality� The maximum number of instances of entity B that

may be associated with each instance of entity A

kipram 89

Naming and Defining Relationships

Relationship name is a verb phraseAvoid vague names

Guidelines for defining relationships� Definition explains what action is being taken and

why it is important� Give examples to clarify the action� Optional participation should be explained� Explain reasons for any explicit maximum

cardinality

10.8910.89

kipram 90

Naming and Defining Relationships

Guidelines for defining relationships� Explain any restrictions on participation in

the relationship� Explain extent of the history that is kept in

the relationship� Explain whether an entity instance involved

in a relationship instance can transfer participation to another relationship instance

kipram 91

Associative Entity

An entity type that associates the instances of one or more entity types and contains attributes that are peculiar to the relationship between those entity instances

10.9110.91

kipram 92

DomainsThe set of all data types and ranges of values that an attribute can assumeSeveral advantages

1. Verify that the values for an attribute are valid

2. Ensure that various data manipulation operations are logical

3. Help conserve effort in describing attribute characteristics

kipram 93

Triggering Operations

An assertion or rule that governs the validity of data manipulation operations such as insert, update and deleteIncludes the following components:� User rule

� Statement of the business rule to be enforced by the trigger

� Event� Data manipulation operation that initiates the operation

� Entity Name� Name of entity being accessed or modified

� Condition� Condition that causes the operation to be triggered

� Action� Action taken when the operation is triggered

kipram 94

Triggering Operations

Responsibility for data integrity lies within scope of database management system, not individual applications

kipram 95

The Role of CASE in Conceptual Data

CASE tools provide two important functions:� Maintain E-R diagrams as a visual

depiction of structured data requirements� Link objects on E-R diagrams to

corresponding descriptions in a repository

kipram 96

SummaryProcess of conceptual data modeling� Deliverables� Gathering information

Entity-Relationship Modeling� Entities� Attributes� Candidate keys and identifiers� Multivalued attributes

Degree of relationship

kipram 97

Summary

CardinalityNaming and defining relationshipsAssociative entitiesDomainsTriggering OperationsRole of CASE