Chapter 1 Introduction to Systems Design and Analysis

Systems Analysis and Design Kendall and Kendall Sixth Edition

Readings & Major Topics

Readings
Chapter 1 (p. 1) in the textbook

Major Topics
Information systems SDLC (Systems Development Life Cycle) Phases of analysis and design CASE tools
1-2

Information
What is information? Domain dependent Facts, concepts, or instructions; any sort of knowledge or supposition which can be communicated. Organizational resource Must be managed as carefully as other resources (e.g., raw material, labor) Costs are associated with information processing Production, distribution, security, storage, retrieval, Information processing must be managed to take full advantage of its potential
1-3

Systems Analysis & Design

Goals
Analyze data input, processing or transforming data, data storage, and information output within the context of a particular business Analyze, design, and implement improvements in the functioning of a business via the use of computerized information systems
1-4

How can we Analyze and Design Systems?

Intuitive approach
Pros and Cons?

Systematic approach
Pros and cons?

1-5

Systems Analysis and Design in this Course

Systematic approach to identifying problems, opportunities, and objectives; analyzing the information flows in organizations; and designing computerized information systems to solve a problem

1-6

Systems Analyst
Performs systems analysis and design Assesses how businesses function by examining the inputting and processing of data and the outputting of information with the intent of improving organizational processes

1-7

Different Types of Systems Analysts

Two major types
Outside consultants to businesses Hired specifically to address information systems issues within a business Supporting experts (within a business you are regularly employed) Not a full-blown systems project, but rather entails a small modification or decision affecting a single department

Your role as a systems analyst: agent of change

Catalyst for change (i.e., improvements to the business that can be done via information systems)
1-8

Interactions of a Systems Analyst

A systems analyst interacts with users at different levels in the organization
User managers Operations workers Systems managers Systems designers Programmers .
1-9

Qualities of a Systems Analyst

Analysts are problem solvers. Communication skills Analysts must be ethical with users and customers
ACMs (Association of Computing Machinery) code of ethics respect the privacy of others
Give comprehensive and thorough evaluations of computer systems and their impacts, including analysis of possible risks

..

1-10

Systems Development Life Cycle (SDLC)

SDLC is a systematic approach to solving business problems It is divided into seven phases Each phase has unique activities A phase is never accomplished as a separate phase
Several activities can occur simultaneously Activities may be repeated
1-11

Phase 1: Identifying problems, opportunities, and objectives

Identifying Problems: dont want to address the wrong problems Opportunities: situations that can be improved Objectives: how can the organization reach its objectives via computerized IS Personnel involved Analyst User managers Systems managers

1-12

Phase 2: Determining Information Requirement

Understand how the business functions and have complete information on the people, goals, data, and procedures Interview management, operations personnel Gather systems/operating documents Use questionnaires Observe the system and personnel involved Learn the details of the current system functions: who (people involved), what (business activities), where (environment in which the work takes place), when (timing), how (procedures), and the why (why is it done this way) 1-13

Phase 2: Determining Information Requirement (contd)

Personnel involved
Analyst User managers Operations workers Systems managers

Information Analyst (phases 1 and 2)

1-14

Phase 3: Analyzing Systems Needs

Analyzing system needs
Create data flow diagrams Document procedural logic for data flow diagram processes Complete the data dictionary Analyze structured decisions Make semistructured decisions (decisions taken under risk) Prepare and present the system proposal Recommend the optimal solution to management
1-15

Phase 3: Analyzing Systems Needs (contd)

Analyst makes recommendations to management
Management decide whether to continue or not

Personnel involved
Analyst User managers Systems managers
1-16

Phase 4: Designing the Recommended System

Accomplish the logical design of the information system
Design the user interface
Design output Design input

Design files and/or database Design control and backup procedures Produce decision trees or tables Produce program specifications
1-17

Phase 4: Designing the Recommended System (contd)

Personnel involved
Analyst System designer User managers Operations workers Systems managers

1-18

Phase 5: Developing and Documenting Software

Develop any original software that is needed Design computer programs using structure charts, Nassi-Schneiderman charts, and pseudocode Walkthrough program design Write computer programs Document software with help files, procedure manuals, and Web sites with Frequently Asked Questions (FAQs)
1-19

Phase 5: Developing and Documenting Software (contd)

Personnel involved
Analyst System designer Programmers Systems managers

1-20

Phase 6: Testing and Maintaining the system

Testing and maintaining the system
Test and debug computer programs Test the computer system Enhance system

Personnel involved
Analyst System designer Programmers Systems management
1-21

System Maintenance
Maintenance: starts in phase 6 but carried out routinely throughout the life of the IS System maintenance is
Removing undetected errors, and Enhancing existing software

Time spent on maintenance typically ranges from 48-60 percent of total time
1-22

System Enhancements
Systems are enhanced for the following reasons:
Adding additional features to the system Business and governmental requirements change over time Technology, hardware, and software are rapidly changing

1-23

Phase 7: Implementing and Evaluating the System

Implementing and evaluating the system Plan conversion from the old system to the new one Train users Purchase and install new equipment Convert files Install system Review and evaluate system: whether the intended users are indeed using the system
1-24

Phase 7: Implementing and Evaluating the System (contd)

Personnel involved
Analyst System designer Programmers User managers Operations workers Systems managers

1-25

CASE Tools
Computer-Aided Software Engineering (CASE) CASE tools are automated, microcomputer-based software packages for systems analysis and design Four reasons for using CASE tools are:
To increase analyst productivity Facilitate communication among analysts and users Providing continuity between life cycle phases To assess the impact of maintenance

1-26

CASE Tool Categories

CASE tools may be divided into several categories
Upper CASE (also called front-end CASE) tools, used to perform analysis and design Lower CASE (also called back-end CASE). These tools generate computer language source code from CASE design Integrated CASE, performing both upper and lower CASE functions
1-27

Upper CASE
Upper CASE tools
Create and modify the system design Store data in a project repository The repository is a collection of records, elements, diagrams, screens, reports, and other project information These CASE tools model organizational requirements and define system boundaries
1-28

Lower CASE
Lower CASE tools generate computer source code from the CASE design Source code may usually be generated in several languages

1-29

Lower CASE: Advantages of Generating Code

Time to develop new systems decreases The time to maintain generated code is less than to maintain traditional systems Computer programs may be generated in more than one language CASE design may be purchased from thirdparty vendors and tailored to organizational needs Generated code is free from program coding errors
1-30

Reverse Engineering
Reverse engineering is generating the CASE design from computer program code Source code is examined, analyzed, and converted into repository entities Uses Computer-Assisted Reengineering (CARE) software
1-31

Reverse Engineering Produces

Depending on the tool set used:
Data structures and elements, describing the files, records, and field Screen designs, if the program is online Report layouts for batch programs A structure chart showing the hierarchy of the modules in the program Database design and relationships
1-32

Advantages of Reverse Engineering

It has the following advantages:
Reduced system maintenance time Program documentation is produced for loosely documented programs Structured programs may be generated from unstructured, older programs Future system maintenance is easier to implement Unused portions of programs may be eliminated 1-33

Chapter 2 Information Gathering: Interactive Methods

Systems Analysis and Design Kendall and Kendall Sixth Edition

Readings & Major Topics

Readings
Chapter 4 in the textbook (p. 89)

Major Topics
Interviewing techniques Joint Application Design (JAD) Questionnaires

4-35

Information Gathering in SDLC

Phase 1 Identifying problems, opportunities, and objectives Phase 7 Implementing and evaluating the system

Phase 2 Determining information requirements Phase 6 Testing and maintaining the system

Phase 3 Analyzing systems needs

Phase 5 Developing and documenting software Phase 4 Designing the recommended system
4-36

Information Gathering: Two Approaches

Interactive: talking with and listening to people in the organization through a series of carefully composed questions

Unobtrusive: do not require the same degree of interactivity between analysts and users
Our focus: Interactive methods
Interviewing JAD Questionnaires Example: observing

Example: interviewing

4-37

Interviewing
Important method for collecting data on information system requirements Directed conversation with a specific purpose that uses Q&A format Reveals information about
Interviewee opinions Feelings about the current state of the system Organizational and personal goals Informal procedures
4-38

Planning the Interview

Five steps in planning the interview are
Reading background material Establishing interview objectives Deciding whom to interview Preparing the interviewee Deciding on question types and structure

4-39

Before the Interview

Contact the interviewee and confirm the interview Dress appropriately Arrive a little early Affirm that you are present and ready to begin the interview

4-40

Recording the Interview

Interviews can be recorded with tape recorders or notes Audio recording should be done with permission and understanding

4-41

Advantages of Audio Recording the Interview

Providing a completely accurate record of what each person said Freeing the interviewer to listen and respond more rapidly Allowing better eye contact and better rapport Allowing replay of the interview for other team members
4-42

Disadvantages of Audio Recording the Interview

Possibly making the interviewee nervous and less apt to respond freely Difficulty in locating important passages on a long tape

4-43

Note Taking During Interviews: Pros and Cons

Pros
Keeping the interviewer alert Aiding recall of important interview trends Showing interviewer interest in the interview

Cons
Losing vital eye contact Losing the train of conversation Causing excessive attention to facts and less attention to feelings
4-44

Beginning the Interview

Shake hands Remind them of your name and why you are there Take out note pad or tape recorder Make sure tape recorder is working correctly

4-45

Opening Questions
Start with pleasant conversation Listen closely to early responses
Pick up on vocabulary

Look for metaphors

The accounting department is a zoo Were one big family here

4-46

During the Interview

The interview should not exceed 45 minutes to one hour Make sure that you are understanding what the interviewee is telling you Ask for definitions if needed

4-47

Closing the Interview

Always ask Is there anything else that you would like to add? Ask whom you should talk with next Set up any future appointments Thank them for their time and shake hands

4-48

Interview Report
Write as soon as possible after the interview Provide an initial summary, then more detail Review the report with the respondent

4-49

Question Types
There are two basic types of interview questions:
Open-ended Closed

4-50

Open-Ended Questions
Allow interviewees to respond how they wish, and to what length they wish
E.g.: Once the data is submitted via the Web site, how is it processed?

Appropriate when the analyst is interested in breadth and depth of reply

4-51

Advantages of Open-Ended Questions

Putting the interviewee at ease Allowing the interviewer to pick up on the interviewee's vocabulary Providing richness of detail Revealing avenues of further questioning that may have gone untapped Allows more spontaneity Useful if the interviewer is unprepared
4-52

Disadvantages of Open-Ended Questions

May result in too much irrelevant detail Possibly losing control of the interview May take too much time for the amount of useful information gained Potentially seeming that the interviewer is unprepared Possibly giving the impression that the interviewer is on a "fishing expedition
4-53

Closed Interview Questions

Limit the number of possible responses
E.g.: On average, how many calls does the call center receive monthly?

Appropriate for generating precise, reliable data which is easy to analyze

4-54

Advantages of Closed Interview Questions

Saving interview time Easily comparing interviews Getting to the point Keeping control of the interview Covering a large area quickly Getting to relevant data

4-55

Disadvantages of Closed Interview Questions

Boring for the interviewee Failure to obtain rich detail Missing main ideas Failing to build rapport between interviewer and interviewee

4-56

Bipolar Questions
Questions that may be answered with a yes or no or agree or disagree
E.g.: Do you want to receive a printout of your account status every month? E.g.: Do you agree or disagree that ecommerce on the Web lacks security?

4-57

Probing Questions
Elicit more detail about previous questions The purpose of probing questions is
To get more meaning To clarify To draw out and expand on the interviewee's point

E.g.: Please give an illustration of the security problems youre experiencing with your online systems?
4-58

Tradeoffs: Open-ended and Closed Questions

Reliability of data Efficient use of time Precision of data Breadth and depth Interviewer skill required Ease of analysis

4-59

Question Pitfalls
Leading questions: imply an answer
Tend to guide interviewees into responses apparently desired by the interviewer Should be avoided to reduce bias and improve reliability and validity E.g.: You agree with other managers that inventory control should be computerized, dont you?

Double-barreled questions: two questions in one

Interviewees may answer only one question, leading to difficulties in interpretation E.g.: What decisions are made during a typical day and how do you make them?
4-60

Question Sequencing
There are three basic ways of structuring interviews:
Pyramid Funnel Diamond

4-61

Pyramid Structure
Begins with very detailed, often closed questions Expands by allowing open-ended questions and more generalized responses Is useful if interviewees need to be warmed up to the topic or seem reluctant to address the topic
4-62

Funnel Structure
Begins with generalized, open-ended questions Concludes by narrowing the possible responses using closed questions Provides an easy, non-threatening way to begin an interview Is useful when the interviewee feels emotionally about the topic
4-63

Diamond Structure
A diamond-shaped structure begins in a very specific way Then more general issues are examined Concludes with specific questions Is useful in keeping the interviewee's interest and attention through a variety of questions
4-64

Joint Application Design (JAD)

Can replace a series of 1-on-1 interviews Allows the analyst to accomplish requirements analysis and design the user interface with the users in a group setting Systems analysts (SAs): passive role
SAs Should be present May give expert opinions about any disproportionate costs of solutions

4-65

Topics Discussed in JAD

Requirements analysis and user interface design
But could be used at any appropriate phase of SDLC

Address topics such as

Planning, receiving, receipt processing/tacking, monitoring and assigning, processing, recording, sending, and evaluating

For each topic, ask:

Who, what, how, where, and why
4-66

JAD Personnel
Analysts Users, executives, (8 to 12) Observers (technical experts) A scribe: write down everything A session leader
Senior person: visible symbol of organizational commitment May be outside management consultant
4-67

Preparing a JAD Session

Two-to-four-day sessions offsite If possible, away from the organization, in comfortable surroundings
Minimize the daily distractions and responsibilities of the participants regular work Use of group decision support facilities (e.g., networked computers, projection system, )

Make use everybody will be able to attend Orientation meeting (1/2 day) a week before the workshop
4-68

When to Use JAD

Users are restless and want something new The organizational culture supports joint problem-solving behaviors Analysts forecast an increase in the number of ideas using JAD Personnel may be absent from their jobs for the length of time required
4-69

Benefits of JAD
Time is saved, compared with traditional interviewing (15%) Rapid development of systems Improved user ownership of the system Creative idea production is improved

4-70

Drawbacks of Using JAD

Requires a large block of time be available for all session participants If preparation is incomplete, the session may not go very well If the follow-up report is incomplete, the session may not be successful The organizational skills and culture may not be conducive to a JAD session
4-71

Questionnaires
Also called Surveys Respondent: person answering a questionnaire (or survey) Useful in gathering information from key organization members about

Attitudes: what people say they want (in the new system) Beliefs: what people think is actually true Behaviors: what organizational members do Characteristics: properties of people or things

4-72

When to Use Questionnaires

Organization members are widely dispersed Many members are involved with the project Exploratory work is needed: quantify what was found in interviews

Problem solving prior to interviews is necessary May be used in conjunction with interviews

How widespread or limited an opinion expressed in an interview really is Raise important issues before interviews are scheduled Follow-up unclear questionnaire responses with interviews Design questionnaires based on what was discovered in interviews
4-73

Question Types
Questions are designed as either
Open-ended
Try to anticipate the response you will get Well suited for getting opinions Useful in explanatory situations Useful when it is impossible to list effectively all possible responses to a question

Closed
Use when all the options may be listed When the options are mutually exclusive

4-74

Open-Ended vs. Closed Questions

Openended Slow High High Easy Difficult Closed Fast Low Low Difficult Easy
4-75

Speed of completion Exploratory nature Breadth and depth Ease of preparation Ease of analysis

Questionnaire Language
Simple: use the language of respondents whenever possible Specific and short questions Free of bias Not patronizing: avoid low-level language choices Technically accurate Right question to the right person: addressed to those who are knowledgeable Appropriate for the reading level of the respondent
4-76

Using Scales in Questionnaires

Assigning numbers or other symbols to an attribute/characteristic for the sake of measuring that attribute/characteristic Devised to have respondents act as judges for the subject of the questionnaire

4-77

Measurement Scales
There are four different forms of measurement scales:
Nominal Ordinal Interval Ratio

4-78

Nominal Scales
Nominal scales are used to classify things into categories
What type of software do you use the most? 1 = Word Processor 2 = Spreadsheet 3 = Database 4 = An Email Program

4-79

Ordinal Scales
Allow classification Ordinal scales also imply rank ordering
The support staff of the Technical Support Group is: 1. Extremely Helpful 2. Very Helpful 3. Moderately Helpful 4. Not Very Helpful 5. Not Helpful At All
4-80

Interval Scales
An interval scale is used when the intervals are equal There is no absolute zero
How useful is the support given by the Technical Support Group? NOT USEFUL EXTREMELY AT ALL USEFUL 1 2 3 4 5
4-81

Ratio Scales
The intervals between numbers are equal Ratio scales have an absolute zero
Approximately how many hours do you spend on the Internet daily? 0 2 4 6 8

4-82

Guidelines for Using Scales

Use a ratio scale when intervals are equal and there is an absolute zero Use an interval scale when intervals are equal but there is no absolute zero Use an ordinal scale when the intervals are not equal but classes can be ranked Use a nominal scale when classifying but not ranking
4-83

Validity and Reliability

Reliability: Consistency in response
Getting the same results if the same questionnaire was administered again under the same conditions

Validity: Degree to which the question measures what the analyst intends to measure
4-84

Problems Associated With Poorly Constructed Scales

Leniency: caused by easy raters Central tendency: respondents rate everything as average Halo effect: impression formed in one question carries into the next question

4-85

Questionnaire Format
Allow ample white space Allow enough space for responses to be typed for open-ended questions Ask respondents to clearly mark their answers Be consistent in style

4-86

Order of Questions
Most important questions go first Similar topics should be clustered together Controversial questions should be positioned after less controversial questions

4-87

Methods of Administering Questionnaires

Convening All concerned respondents together at one time Personally administering the questionnaire Allowing respondents to self-administer the questionnaire Mailing questionnaires: supply deadlines, instructions, and return postage Administering over the Web or via email
4-88

Chapter 3 Data Flow Diagrams

Systems Analysis and Design Kendall and Kendall Sixth Edition

Readings & Major Topics

Readings
Chapter 7 in the textbook (p. 191)

Major Topics
Data flow diagram symbols Data flow diagram levels Creating data flow diagrams Physical and logical data flow diagrams Partitioning
90

Data Flow Diagrams in SDLC

Phase 1 Identifying problems, opportunities, and objectives Phase 7 Implementing and evaluating the system

Phase 2 Determining information requirements Phase 6 Testing and maintaining the system

Phase 3 Analyzing systems needs

Phase 5 Developing and documenting software Phase 4 Designing the recommended system
91

Data Flow Diagrams (DFDs)

One of the main methods available for analyzing data-oriented systems DFD: a graphical representation of data movement through the organization
Processes
Transforming of data as it moves through a variety of processes within the enterprise

Inputs/outputs Data storage

92

Why DFDs?
Freedom from committing to the technical implementation too early Understanding of the interrelationships of systems and subsystems Communicating current system knowledge to users

93

Basic Symbols in DFDs

A double square for an external entity--a source or destination of data An arrow for movement of data from one point to another A rectangle with rounded corners for the occurrence of transforming process An open-ended rectangle for a data store
94

External Entities
Represent people or organizations outside of the system being studied Shows the initial source and final recipient of data and information Should be named with a noun, describing that entity
Customer

95

External Entities (contd)

External entities may be
A person, such as CUSTOMER or STUDENT A company or organization, such as BANK or SUPPLIER Another department within the company, such as ORDER FULFILLMENT Another system or subsystem, such as the INVENTORY CONTROL SYSTEM
96

Processes
Represent either:
A whole system A subsystem Work being done, an activity
1 Add New Customer
2 Customer Inquiry Subsystem

Names should be in the form verbadjective-noun

The exception is a process that represents an entire system or subsystem
97

Data Stores
Name with a noun, describing the data Data stores are usually given a unique reference number, such as D1, D2, D3 Include any data stored, such as:
A A A A computer file or database transaction file D1 set of tables manual file of records
Customer Master

98

New Customer

Data Flow

Customer Record

Shows the data about a person, place, or thing that moves through the system Names should be a noun that describes the data moving through the system Arrowhead indicates the flow direction Use double headed-arrows only when a process is reading data and updating the data on the same table or file
99

Data Flow Diagram Levels

Data flow diagrams are built in levels The top level is the Context level DFD Each process may explode to a lower level The lower level diagram number is the same as the parent process number Processes that do not create a child diagram are called primitive
100

Data Flow Diagram Levels (contd)

Different levels of DFDs
One (1) Context level DFD One (1) Diagram 0 One or more Child Diagrams

101

Context Level DFD

Contains only one process, representing the entire system to be designed/analyzed
Highest-level diagram Overview including basic inputs, the general system, and basic outputs

The process is given the number zero (0) Includes all external entities as well as major data flow to and from them The diagram does not contain any data stores
102

Diagram 0
Diagram 0 is the explosion of the context level diagram (i.e., process 0) Should include up 9 processes
Any more will result in a cluttered diagram

Processes are numbered with an integer The major data stores and all external entities are included in Diagram 0
103

Child Diagrams
Each process on diagram zero may be (if not primitive) exploded to create a child diagram Each process on a lower-level diagram may be (if not primitive) exploded to create another child diagram A diagram found below Diagram 0 is given the same number as its parent process
Process 3 in Diagram 0 would explode to Diagram 3
104

Child Diagrams (contd)

Each process is numbered with the parent diagram number, a period, and a unique child number Examples are:
On Diagram 3, the processes would be numbered 3.1, 3.2, 3.3 and so on 3.2 on Diagram 3, a child of process 3 5.2.7 on Diagram 5.2, a child of process 5.2
3.2 Edit Customer 5.2.7

Calculate Customer Discount

105

Child Diagrams (contd)

External entities are usually not shown on the child diagrams below Diagram 0 If the parent process has data flow connecting to a data store, the child diagram may include the data store as well

106

Child Diagrams (contd)

A lower-level diagram may contain data stores not shown on the parent process, such as A file containing a table of information (such as a tax table) A file linking two processes on the child diagram Minor data flow, such as an error line, may be included on a child diagram Handling of exceptions is generally ignored for the first two levels
107

Child Diagrams (contd)

Vertical Balancing rule
A child diagram cannot produce output or receive input that the parent process does not also produce or receive

Must be respected while designing DFDs

108

Child Diagrams (contd)

An interface data flow is data that are input or output from a child diagram that matches the parent diagram data flow Processes that do not create a child diagram are called primitive processes
Logic is written for these processes (will be discussed in another chapter)
109

Data Flow Diagram Errors

A process with only input data flow or only output data flow from it
1 Add New Customer 2 Add New Customer

110

Data Flow Diagram Errors (contd)

Data stores or external entities are connected directly to each other, in any combination
Customer

D1

Customer

Vendor

D2

Vendor Master

111

Data Flow Diagram Errors (contd)

Incorrectly labeling data flow or objects
Examples are
Labels omitted from data flow or objects Data flow labeled with a verb Processes labeled with a noun

Too many processes on a data flow diagram

Nine is the suggested maximum
112

Data Flow Diagram Errors (contd)

Omitting data flow from the diagram Unbalanced decomposition between a parent process and a child diagram
The data flow in and out of a parent process must be present on the child diagram

113

Guidelines for Developing DFDs

Create the context level diagram, including all external entities and the major data flow to or from them Create Diagram 0 by analyzing the major activities within the context process
Include the external entities and major data stores

Create a child diagram for each complex process on Diagram 0

114

Guidelines for Developing DFDs (contd)

Detailed DFDs (child or Diagram 0) may be developed by
Making a list of business activities Analyzing what happens to an input data flow from an external entity Analyzing what is necessary to create an output data flow to an external entity Examining the data flow to or from a data store Unclear areas of a data flow diagram should be noted and investigated
115

Event Driven DFDs

An input flow from an external entity is called a trigger
It starts processes

Events are activities that happen within the system

116

Event Driven DFDs (contd)

Another approach used to create a data flow fragment
Analyze events, which are summarized in an event table

Events are either

External, coming from outside the system, or Temporal, which occur at fixed times

117

Event Tables
An event table is used to create a data flow diagram by analyzing each event and the data used and produced by the event Every row in an event table represents a unique activity and is used to create one process on the data flow diagram
118

DFD Progression
The progression of creating DFDs is
Create a logical DFD of the current system Next add all the data and processes not in the current system which must be present in the new system Finally derive the physical data flow diagram for the new system

119

Logical DFDs
Logical data flow diagrams show how the business operates Represent features that would exist no matter what the physical means of doing business are. Processes that would exist regardless of the type of system implemented
120

Logical DFDs Advantages

Better communication with users More stable systems, since the design is based on a business framework Increased understanding of the business by analysts Elimination of redundancy

121

Physical DFDs
Show how the system operates or how the new system will be implemented Physical DFDs include
Clarifying which processes are manual/automatic Describing processes in greater detail Sequencing processes to rearrange the order of records Validation processes for ensuring accurate data input Intermediate data stores Actual document and file names Controls to ensure accuracy and completeness
122

CRUD Matrix
Physical DFDs include processes for adding, reading, changing, and deleting records CRUD is an acronym for Create, Read, Update, Delete A CRUD matrix shows which processes add, read, update, or delete master file records
123

Partitioning
Process of analyzing a DFD and deriving a series of manual procedures and computer programs A dashed line is drawn around a group of processes that are included in each computer program or manual procedure

124

Manual Procedures
Performed by people Have manual input and manual output Computer processing not used with manual processes

125

Batch Processes
If the data flow into and out of a process is entirely computer information, the process is called a batch process Batch processes do not require any human intervention A job stream is several separate programs running back-to-back, usually a series of batch processes 126

User Interface
A user interface represents a screen, a data entry operation, a report, or some other means for persons to interact with a computer It occurs when the data flow links a manual and an automated process

127

Reasons for Partitioning

Different user groups should have different programs Processes that execute at different times must be in separate programs Processes may be separated into different programs for security Similar tasks may be included in the same program Several batch processes may be included in the same program for efficiency Several processes may be included in the same program or job stream for consistency of data
128

Using DFDs
Unexploded data flow diagrams are useful to identify information requirements Exploded data flow diagrams can be used for presentation, education, and gathering feedback information from users DFDs may be used to analyze the system to ensure that the design is complete DFDs are used to partition the system into programs Data flow diagrams can be used for the system documentation

129

Chapter 4 Analyzing Systems Using Data Dictionaries

Systems Analysis and Design Kendall and Kendall Sixth Edition

Readings & Major Topics

Readings
Chapter 8 in the textbook (p. 245)

Major Topics
Data dictionary concepts Defining data flow Defining data structures Defining elements Defining data stores
131

Data Dictionaries in SDLC

Phase 1 Identifying problems, opportunities, and objectives Phase 7 Implementing and evaluating the system

Phase 2 Determining information requirements Phase 6 Testing and maintaining the system

Phase 3 Analyzing systems needs

Phase 5 Developing and documenting software Phase 4 Designing the recommended system
132

Data Dictionary
Reference work of data about data (metadata) Main method for analyzing data flows and data stores Collects, coordinates, and confirms what a specific data term means to different people in the organization
133

Reasons for Using a Data Dictionary

Some reasons
Provide documentation Eliminate redundancy Validate the data flow diagram Provide a starting point for developing screens and reports Develop the logic for DFD processes

Automated dictionaries (CASE tools)

Cross-reference data items
134

The Repository
A data repository is a large collection of project information It includes
Information about system data Procedural logic Screen and report design Project requirements and deliverables Project management information (e.g., delivery schedules, achievements, )
135

Data Dictionary Contents

Data dictionaries contain data about
Data flow
Data flow description form

Data structures Data Elements

Element description form

Data stores
Data store description form
136

Data Flow Description Form

Each data flow should be defined with descriptive information and it's composite structure or elements Includes:
ID - identification number Unique name for the data flow: should appear on the DFD A general description of the data flow
137

Data Flow Description Form (contd)

Includes:
The source of the data flow
This could be an external entity, a process, or a data flow coming from a data store

The destination of the data flow Type of data flow, either

A record entering or leaving a file Containing a report, form, or screen Internal - used between processes
138

Data Flow Description Form (contd)

Includes:
The name of the data structure or elements The volume per unit time
This could be records per day or any other unit of time

An area for further comments and notations about the data flow
139

Data Flow Description Form Example

Name Description Customer Order Contains customer order information and is used to update the customer master and item files and to produce an order record. Source Customer External Entity Destination Process 1, Add Customer Order Type Screen Data Structure Order Information Volume/Time 10/hour Comments An order record contains information for one customer order. The order may be received by mail, fax, or by telephone.
140

Defining Data Structures

Data structures are a group of smaller structures and elements An algebraic notation is used to represent the data structure

141

Algebraic Notation
The symbols used are
Equal sign, meaning consists of Plus sign, meaning "and Braces {} meaning repetitive elements, also called repeating groups or tables Brackets [] for an either/or situation
The elements listed inside are mutually exclusive

Parentheses () for an optional element

142

Repeating Groups
A repeating group may be
A sub-form A screen or form table A program table, matrix, or array

There may be one repeating element or several within the group

The repeating group may have

A fixed number of repetitions
12 {Monthly Sales}

Upper and lower limits for the number of repetitions

5 1

{Order Line}

143

Structural Records
A structure may consist of elements or smaller structural records These are a group of fields, such as
Customer Name, Address, Telephone

Each of these must be further defined until only elements remain Structural records and elements used within many different systems should be given a non-systemspecific name

E.g.: street, city, and zip

144

Structural Record Example

Customer Name = First Name + (Middle Initial) + Last Name
Address = Street + (Apartment) + City + State + Zip + (Zip Expansion) + (Country) Area code + Local number
145

Telephone =

Logical Data Structures

Data structures may be either logical or physical Logical data structures indicate the composition of the data familiar to the user

146

Physical Data Structures

Include elements and information necessary to implement the system Additional physical elements include
Key fields used to locate records Codes to indicate record status Codes to identify records when multiple record types exist on a single file Etc.
147

Data Structure Example

Customer Order = Customer Number + Customer Name + Address + Telephone + Catalog Number + Order Date + {Order Items} + Merchandise Total + (Tax) + Shipping and Handling + Order Total + Method of Payment + (Credit Card Type) + (Credit Card Number) + (Expiration Date)
148

Element Description Forms

Data elements should be defined with descriptive information, length and type of data information, validation criteria, and default values Each element should be defined once in the data dictionary

149

Element Description Forms Attributes

Element ID. This is an optional entry that allows the analyst to build automated data dictionary entries The name of the element, descriptive and unique
It should be what the element is commonly called in most programs or by the major user of the element

150

Element Description Forms Attributes (contd)

Aliases, which are synonyms or other names for the element
These are names used by different users within different systems Example, a Customer Number may be called a Client Number

A short description of the element

151

Element Description Forms Attributes (contd)

Whether the element is base or derived
A base element is one that has been initially keyed into the system A derived element is one that is created by a process, usually as the result of a calculation or some logic

152

Element Description Forms Attributes (contd)

The length of an element
Some elements have standard lengths, such as a state abbreviation, zip code, or telephone number For other elements, the length may vary and the analyst and users must decide the final length Numeric amount lengths should be determined by figuring the largest number the amount will contain and then allowing room for expansion Totals should be large enough to accommodate the numbers accumulated into them It is often useful to sample historical data to determine a suitable length
153

Element Description Forms Attributes (contd)

Percent of data that will Length fit within the length (US) 11 18 20 18 17 98% 95% 95% 90% 99%

Element

Last Name First Name Company Name Street City

154

Element Description Forms Attributes (contd)

The length of an element (contd)
Data Truncation
If the element is too small, the data will be truncated The analyst must decide how this will affect the system outputs
If a last name is truncated, mail would usually still be delivered A truncated email address or Web address is not usable
155

Element Description Forms Attributes (contd)

The type of data
Numeric, date, alphabetic or alphanumeric or other microcomputer formats

Input and output formats should be included, using coding symbols:

Z Leading Zeros or spaces 9 - Number X - Character X(8) - 8 characters Etc.
156

Element Description Forms Attributes (contd)

Validation criteria
Discrete, meaning they have fixed values
Discrete elements are verified by checking the values within a program They may search a table of codes

Continuous, with a smooth range of values

Continuous elements are checked that the data is within limits or ranges

157

Element Description Forms Attributes (contd)

Default value
The default value is displayed on entry screens Reduces the amount of keying

Comments
This might be used to indicate the format of the date, special validation that is required, etc.
158

Data Element Example

Name Alias Alias Description Customer Number Client Number Receivable Account Number Uniquely identifies a customer that has made any business transaction within the last five years. 6 9(6) 9(6)

Length Input Format Output Format Default Value Continuous/Discrete Continuous Type Numeric Base or Derived Derived Upper Limit <999999 Lower Limit >18 Discrete Value/Meaning Comments The customer number must pass a modulus-11 check-digit test.
159

Data Store Description Form

Data stores contain a minimal of all base elements as well as some derived elements Data stores are created for each different data entity, that is, each different person, place, or thing being stored Since a data flow may only show part of the collective data, called the user view, you may have to examine many different data flow structures to arrive at a complete data store description
160

Data Store Description Form Attributes

The Data Store ID The Data Store Name: descriptive and unique An Alias for the file A short description of the data store The file type:
Manual or computerized If the file is computerized, the file format designates whether the file is a database file or the format of a traditional flat file
161

Data Store Description Form Attributes (contd)

The maximum and average number of records on the file The growth per year
Predict the amount of disk space required

The data set name specifies the table or file name, if known
In the initial design stages, this may be left blank

The data structure should use a name found in the data dictionary

162

Data Store Description Form Attributes (contd)

Primary and secondary keys must be elements (or a combination of elements) found within the data structure Example: Customer Master File
Customer Number is the primary key, which should be unique The Customer Name, Telephone, and Zip Code are secondary keys

Comments
163

Data Store Example - Part 1

ID Name Alias Description File Type File Format Record Size Maximum Records Average Records Percent Growth/Year D1 Customer Master File Client Master File Contains a record for each customer Computer Database 200 45,000 42,000 6%
164

Data Store Example - Part 2

Data Set/Table Name Customer Copy Member Custmast Data Structure Customer Record Primary Key Customer Number Secondary Keys Customer Name, Telephone, Zip Code Comments The Customer Master file records are copied to a history file and purged if the customer has not purchased an item within the past five years. A customer may be retained even if he or she has not made a purchase by requesting a catalog.
165

Data Dictionary and Data Flow Diagram Levels

Data dictionary entries vary according to the level of the corresponding DFD Data dictionaries are created in a top-down manner
Whole structures, such as the whole report or screen, are used on the top level of the DFD Data structures are used on intermediate-level DFD Elements are used on lower-level data flow diagrams

Data dictionary entries may be used to validate parent and child DFD level balancing
166

Creating Data Dictionaries

1. Information from interviews and JAD sessions is summarized on Input and Output Analysis Forms
This provides a means of summarizing system data and how it is used

2. Each structure or group of elements is analyzed

167

Creating Data Dictionaries

3. Each element should be analyzed by asking the following questions:
A. Are there many of the field?
If the answer is yes, indicate that the field is a repeating field using the { } symbols

B. Is the element mutually exclusive of another element?

If the answer is yes, surround the two fields with the [ | ] symbols
168

Creating Data Dictionaries

C. Is the field an optional entry or optionally printed or displayed?
If so, surround the field with parenthesis ( )

4. All data entered into the system must be stored

Create one file or database file for each different type of data that must be stored Add a key field that is unique to each file
169

Determining Data Store Contents

Data stores may be determined by analyzing data flows Each data store should consist of elements on the data flows that are logically related, meaning they describe the same entity

170

Maintaining the Data Dictionary

To have maximum power, the data dictionary should be tied into other programs in the system When an item is updated or deleted from the data dictionary it is automatically updated or deleted from the database
171

Using the Data Dictionary

Data dictionaries may be used to
Generate computer program source code Create reports, screens, and forms Analyze the system design for completion and to detect design flaws

172

Creating Reports, Screens, Forms

To create screens, reports, and forms
Use the element definitions to create fields Arrange the fields in an aesthetically pleasing screen, form, or report, using design guidelines and common sense Repeating groups become columns Structural records are grouped together on the screen, report, or form
173

Data Dictionary Analysis

The data dictionary may be used in conjunction with the data flow diagram to analyze the design, detecting flaws and areas that need clarification

Some considerations for analysis are

All base elements on an output data flow must be present on an input data flow to the process producing the output Base elements are keyed and should never be created by a process A derived element should be output from at least one process that it is not input into The elements that are present on a data flow into or coming from a data store must be contained within the data store

174

Chapter 5 Describing Process Specifications and Structured Decisions

Systems Analysis and Design Kendall and Kendall Sixth Edition

Readings & Major Topics

Readings
Chapter 9 in the textbook (page 283)

Major Topics
Process specifications Decision tables

Other Types of Specifications

Structured English Decision trees
176

Process Specification in SDLC

Phase 1 Identifying problems, opportunities, and objectives Phase 7 Implementing and evaluating the system

Phase 2 Determining information requirements Phase 6 Testing and maintaining the system

Phase 3 Analyzing systems needs

Phase 5 Developing and documenting software Phase 4 Designing the recommended system
177

Process Specifications
Process specifications (minispecs) are created for primitive processes and some higher level processes on a DFD Documenting and analyzing the logic of structured decisions
Structured English Decision trees Decision tables
178

Goals of Creating Process Specifications

Reduce process ambiguity Obtain a precise description of what is accomplished Validate the system design, including data flow diagrams and the data dictionary
179

No Process Specifications For

Physical input and/or output processes Processes that represent simple data validation Processes for which prewritten code already exists
180

Process Logic
Process descriptions may exist on a form or within a CASE tool repository Process logic may be represented as
Structured English A decision table A decision tree Any combination of the above

181

Process Specification Format

The process number, which must match the process ID on the data flow diagram
This allows an analyst to work or review any process and easily locate the DFD containing the process

The process name, the same as displays within the process symbol on the DFD A brief description of what the process accomplishes
182

Process Specification Format (contd)

A list of input and output data flow, using the names found on the data flow diagram
Data names used in the formulae or logic should match the data dictionary, for consistency and good communication

An indication of the type of process

Batch, online or manual All online processes require screen designs All manual processes should have well-defined procedures for employees performing the process tasks 183

Process Specification Format (contd)

If the process has prewritten code for it, include the name of the subprogram or function A reference to further information, such as a structured English description, a decision table or tree depicting the logic List any unresolved issues
These form the basis of the questions used for a follow-up interview
184

Process Specification Example Part 1

Number Name 1 Add Customer Order

Description Key and add the Customer Order. The order should be edited for correct information. Customer and Item master files are updated. Input Data Flow Customer Order Form from the Customer Customer Record from data store D1, Customer Master File Item Record from data store D2, Item Master File
185

Process Specification Example Part 2

Output Data Flow Pending Order to data store D3, Order File Backordered Item Record to the Inventory Control Department Updated Customer and Item records
Type of process Online

186

Decision Tables
Decision tables provide a way to examine, describe, and document decisions using a table They are used to
Describe the conditions Identify possible decision alternatives Indicate actions should be performed, and Describe actions
187

Decision Tables
Decision tables help analysts ensure completeness and accuracy Four main problems that can occur in developing decision tables
Incompleteness Impossible situations Contradictions Redundancy
188

Parent Process Specifications

If a process explodes to a child diagram, the process becomes a control module when the computer program representing the process is written The logic of the process shows the sequence that the child diagram processes must be executed in
189

Program Process Specification

All the process specifications are consolidated for a computer program and are included in the specification packet given to the computer programmer Since they are developed for one process, the logic is easier to understand
190

Horizontal Balancing
Horizontal balancing means that all output data flow must be either on input data flow or described in the process logic It is used to verify that each process has the required data dictionary entries defined and the formulas and logic necessary to produce the output
191

Rules for Horizontal Balancing

Rules for horizontal balancing are
All base elements on an output data flow must be present on an input data flow All derived elements on an output data flow must be either
Present on an input data flow, or Created by the process

192

Chapter 7 Designing Databases

Systems Analysis and Design Kendall and Kendall Sixth Edition

Database Design in SDLC

Phase 1 Identifying problems, opportunities, and objectives Phase 7 Implementing and evaluating the system

Phase 2 Determining information requirements Phase 6 Testing and maintaining the system

Phase 3 Analyzing systems needs

Phase 5 Developing and documenting software Phase 4 Designing the recommended system
194

Readings & Major Topics

Readings
Chapter 13 in the textbook (page 443)

Major Topics
Databases ER Model Relational Model Normalization Key design
195

Objectives of Effective Databases

Ensuring that data can be shared among users for a variety of applications Maintaining data that are both accurate and consistent Ensuring all data required for current and future applications will be readily available Allowing the database to evolve and the needs of the users to grow Allowing users to construct their personal view of the data without concern for the way the data are physically stored
196

Metadata
Metadata is the information that describes data in the database
Used to help users understand the form and structure of the data Also called schema in databases

197

Entity-Relationship (ER) Concepts

Entities are objects or events for which data is collected and stored
person, place, thing, event, unit of time,

Relationships are associations between entities

198

Entities
A distinct collection of data for one person, place, thing, or event

Customer

199

Attributes, Records, and Keys

Attributes are a characteristic of an entity, sometimes called a field
Also called data item

Records are a collection of data items that have something in common

Instance of an entity

Keys are data items in a record used to identify the record

200

Keys
Primary key, unique for the record Secondary key, a key which may not be unique Concatenated key, a combination of two or more data items for the key Foreign key, a data item in one record that is the key of another record

201

Entity Subtype
An entity subtype represents data (fields) about an entity that may not be found on every instance of an entity
Preferred customers may have special fields containing discount information

Eliminates null fields

Preferred Customer
202

Attributive Entity
Attributive Entity - describes attributes, especially repeating elements Attributive entities tables, table files or database code tables
Book Subject

203

Relationships
Relationships may be
One-to-one One-to-many Many-to-many

A single vertical line represents one A circle represents zero or none A crows foot represents many
204

Relationships
Many Many One

O None

205

Ordinality
The ordinality is the minimum number that can occur in a relationship If the ordinality is zero, it means that it is possible to have none of the entity
Item
O

Order

206

Self-Join
A self-join is when a record has a relationship with another record on the same entity
Student partners with another student on a project

207

Associative Entity
Associative Entity - links two entities An associative entity can only exist between two entities The relationship line between a many-to-many relationship becomes an associative entity, sometimes called a composite entity or gerund
Order Item

208

Associative Entity Connections

Each entity end has a one connection The associative entity has a many connection on each side

209

Associative Entity Keys

The key fields for the associative entity are
The primary key for each one end is a foreign key on the associative entity Both foreign keys concatenated together become the primary key

210

ER Diagram and Record Keys

The ER diagram may be used to determine record keys
When the relationship is one-to-many, the primary key of the file at the one end of the relationship should be contained as a foreign key on the file at the many end of the relationship A many-to-many relationship should be divided into two one-to-many relationships with an associative entity in the middle
211

Databases
A database is intended to be shared by many users There are three structures for storing database files:
Hierarchical database structures Network database structures Relational database structures
212

Normalization
Normalization is the transformation of complex user views and data to a set of smaller, stable, and easily maintainable data structures Normalization creates data that are stored only once on a file
The exception is key fields This eliminates redundant data storage
213

Three Steps of Data Normalization

User View

Unnormalized Relationship Remove repeating groups Normalized Relations (1NF) Remove partial dependencies Second Normal Form Relations (2NF) Remove transitive dependencies Third Normal Form Relations (3NF)
214

Data Model Diagrams

Data model diagrams are used to show relationships between attributes An oval represents an attribute A single arrow line represents one A double arrow line represents many
Customer Number Salesperson Number
215

First Normal Form (1NF)

Remove any repeating groups All repeating groups are moved into a new table Foreign keys are used to link the tables When a relation contains no repeating groups, it is in the 1 NF Keys must be included to link the relations, tables
216

Second Normal Form (2NF)

Remove any partial dependencies
A partial dependency is when the data are only dependent on a part of a key field

A relation is created for the data that are only dependent on part of the key and another for data that are dependent on both parts
217

Third Normal Form (3NF)

Remove any transitive dependencies
A transitive dependency is when a relation contains data that are not part of the entity

The problem with transitive dependencies is updating the data A single data item may be present on many records
218

Guidelines for Creating Master Files or Database Relations

Guidelines for creating master files or database relations are
Each separate entity should have it's own master file or database relation A specific, nonkey data field should exist on only one master file or relation Each master file or relation should have programs to create, read, update, and delete records
219

Integrity Constraints
There are three integrity constraints that help to ensure that the database contains accurate data:
Entity integrity constraints, which govern the composition of primary keys Referential integrity, which governs the denature of records in a one-to-many relationship Domain integrity
220

Entity Integrity
Entity integrity constraints are rules for primary keys:
The primary key cannot have a null value If the primary key is a composite key, none of the fields in the key can contain a null value

221

Referential Integrity
Referential integrity governs the denature of records in a one-to-many relationship Referential integrity means that all foreign keys in one table (the child table) must have a matching record in the parent table
222

Referential Integrity
Referential integrity includes
You cannot add a record without a matching foreign key record You cannot change a primary key that has matching child table records
A child table that has a foreign key for a different record

You cannot delete a record that has child records

223

Referential Integrity
A restricted database updates or deletes a key only if there are no matching child records A cascaded database will delete or update all child records when a parent record is deleted or changed The parent triggers the changes
224

Domain Integrity
Domain integrity defines rules that ensure that only valid data are stored on database records
Domain integrity has two forms:
Check constraints, which are defined at the table level Rules, which are defined as separate objects and may be used within a number of fields

225

Retrieving and Presenting Database Data

Guidelines to retrieve and present data
Choose a relation from the database Join two relations together Project columns from the relation Select rows from the relation Derive new attributes Index or sort rows Calculate totals and performance measures Present data
226

Thank you...