3/23/2008

IFS310: Week 2BIS310: Structured Analysis and Design

Fact Finding Techniquesand

Structured Methodology

3/23/2008

IFS310: Week 2

OUTLINE OF CLASS

• Discussion– Fact Finding– Interviews, Questionnaires, Prototypes etc.– Ethics and Strategy– Structured Analysis and Design– Structured Programming (COBOL)– Systems Analysis Strategies

3/23/2008

IFS310: Week 2

What is Fact-Finding?

• Fact-finding is the formal process of using research, interviews, questionnaires, sampling, and other techniques to collect information about systems, requirements, and preferences. It is also called information gathering or data collection.

3/23/2008

IFS310: Week 2

When do you perform fact-finding?

• Fact-finding is most crucial to the systems planning and systems analysis phases that the analyst learns about the vocabulary, problems, opportunities, constraints, requirements, and priorities of a business and a system.

3/23/2008

IFS310: Week 2

What Fact-Finding Methods are Available?

1. Sampling of existing documentation, forms, and databases

2. Research and site visits

3. Observation of the work environment

4. Questionnaires

5. Interviews

6. Prototyping

3/23/2008

IFS310: Week 2

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

3/23/2008

IFS310: Week 2

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

3/23/2008

IFS310: Week 2

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

3/23/2008

IFS310: Week 2

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

3/23/2008

IFS310: Week 2

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

3/23/2008

IFS310: Week 2

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

3/23/2008

IFS310: Week 2

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

3/23/2008

IFS310: Week 2

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

3/23/2008

IFS310: Week 2

What is Prototyping?

– The prototyping approach is an iterative process involving a close working relationship between the designer and the users.

Prototyping is an engineering technique used to develop partial, but functional versions of a system or applications. When extended to system design and construction, a prototype can evolve into the final, implemented system.

3/23/2008

IFS310: Week 2

Two ‘flavors’ of prototyping are applicable to systems analysis:

Feasibility prototyping is used to test the feasibility of a specific technology that might be applied to the business problem.

Discovery prototyping (sometimes called requirements prototyping) is used to ‘discover’ the users’ business requirements by having them react to a ‘quick-and-dirty’ implementation of those requirements.

3/23/2008

IFS310: Week 2

– Prototypes can be quickly developed using many of the 4GLs and object-oriented programming languages available today.

– Prototypes can be built for simple outputs, computer dialogues, key functions, entire subsystems, or even the entire system.

How you work with Prototyping Tools?

3/23/2008

IFS310: Week 2

• Each prototype system is reviewed by end-users and management, who make recommendations about requirements, methods, and formats.

• The prototype is then corrected, enhanced, or refined to reflect the new requirements.

• The revision and review process continues until the prototype is accepted.

3/23/2008

IFS310: Week 2

Fact-Finding Ethics• More often than not during your fact finding exercises you may come

across or be analyzing information which is sensitive in nature. • The analyst must take great care to protect the data they have been

entrusted with.• Washington, D.C. is the home of the Computer Ethics Institute, a

nonprofit research, education and policy study organization. – It strives to make people more aware of computer ethics and to use

computers more responsibly. – One of their primary goals is to make computer ethics part of the standard

school curriculum and to promote more awareness they have published The Ten Commandments of Computer Ethics.

3/23/2008

IFS310: Week 2

A Fact-Finding Strategy

– Always better to collect as many facts as possible before using interviews (from existing documents, forms, reports, and files).

– If appropriate, observe the system in action. – Given all the facts that you've already collected, design

and distribute questionnaires to clear up things you don't fully understand.

– Conduct your interviews (or group work sessions, such as JAD or RAD).

– Follow up.

3/23/2008

IFS310: Week 2

Strategies for Systems Analysis and Problem Solving

• Modern Structured Analysis– Model

– Model-driven development

– Process Models - Data Flow Diagrams (DFDs)

3/23/2008

IFS310: Week 2

Structured Systems Analysis and Design Methodology (SSADM)

• A systems approach to the analysis and design of information systems.

• Involves the application of a sequence of analysis, documentation and design tasks.

• Uses a combination of text and diagrams throughout the whole life cycle of a system design, from the initial design idea to the actual physical design of the application.

3/23/2008

IFS310: Week 2

SSADM (cont.)

• SSADM uses a combination of three techniques: – Logical Data Modeling – Data Flow Modeling – Entity Behavior Modeling

3/23/2008

IFS310: Week 2

Structured programming

• A subset or subdiscipline of procedural programming, one of the major programming paradigms. It is most famous for removing or reducing reliance on the GOTO statement (also known as "go to").

• Break larger pieces of code into shorter subroutines (functions, procedures. methods, blocks, or otherwise) that are small enough to be understood easily.

3/23/2008

IFS310: Week 2

COBOL

• COBOL is a third-generation programming language. Its name is an acronym, for COmmon Business Oriented Language, defining its primary domain in business, finance, and administrative systems for companies and governments.

• COBOL did not support local variables, recursion, dynamic memory allocation, or structured programming constructs. Support for some or all of these features has been added in later editions of the COBOL standard.

3/23/2008

IFS310: Week 2

Structure of COBOL (Example)

• See handout (COBOL.doc) downloadable from BB or my Websitehttp://www.nku.edu/~sakaguch/ifs310/COBOL.doc

• COBOL has four divisions (Identification, Environment, Data, and Procedure), with Procedure division taking care of all the logics of the program.

3/23/2008

IFS310: Week 2

Structure Chart

3/23/2008

IFS310: Week 2

What is System Analysis?

Systems analysis is the dissection of a system into its component pieces for purposes of studying how those component pieces interact and work.

Systems analysis is (1) the surveysurvey and planning of the system and project, (2) the studystudy and analysis of the existing business and information system, and (3) the definitiondefinition of business requirements and priorities for a new or improved system. A popular synonym is logical design.

3/23/2008

IFS310: Week 2

The Survey Phase

• Survey Problems, Opportunities, and Directives

• Negotiate Project Scope

• Plan The Project

• Present The Project

3/23/2008

IFS310: Week 2

Outputs of Survey Phase

• Project Charter

• Problem Statement

• Scope Statement

3/23/2008

IFS310: Week 2

The Study Phase

• Model the Current System – The overriding modeling strategy is

information hiding.– Data, Process, and Geographic Modeling

• Analyze Problems and Opportunities– cause/effect analysis.

3/23/2008

IFS310: Week 2

Page 1 of 5

PROBLEMS, OPPORTUNITIES, OBJECTIVES AND CONSTRAINTS MATRIX

Project: Member Services Information System Project Manager: Sandra Shepherd

Created by: Robert Martinez Last Updated by: Robert Martinez

Date Created: January 21, 1997 Date Last Updated: January 31, 1997

CAUSE AND EFFECT ANALYSIS SYSTEM IMPROVEMENT OBJECTIVES

Problem or Opportunity Causes and Effects System Objective System Constraint

1. Order response time is unaccept-able.

1. Throughput has increased whilenumber of order clerks was down-sized. Time to process a single or-der has remained relatively con-stant.

2. System is too keyboard dependent.Many of the same values are keyedfor most orders. Net result is (withthe current system) each ordertakes longer to process than isideal.

3. Data editing is performed by theAS/400. As that computer has ap-proached its capacity, order edit re-sponses have slowed. Because or-der clerks are trying to work fasterto keep up with the volume, thenumber of errors have increased.

4. Warehouse picking tickets for or-ders were never designed to maxi-mize the efficiency of order fillers.As warehouse operations grew, or-der filling delays were inevitable.

1. Decrease the time required to proc-ess a single order by 30%.

2. Eliminate keyboard data entry foras much as 50% of all orders.

3. For remaining orders, reduce asmany keystrokes as possible by re-placing keystrokes with point-and-click objects on the computer dis-play screen.

4. Move data editing from a sharedcomputer to the desktop.

5. Replace existing picking ticketswith a paperless communicationsystem between member servicesand the warehouse.

1. There will be no increase in theorder processing workforce.

2. Any system developed must becompatible with the existing Win-dows 95 desktop standard.

3. New system must be compatiblewith the already approved auto-matic identification system (for barcoding).

3/23/2008

IFS310: Week 2

The Study Phase (cont.)

• Establish System Improvement Objectives and Constraints

• Modify Project Scope and Plan

• Present Findings and Recommendations

3/23/2008

IFS310: Week 2Analysis of the Current ___________ System

I. Executive summary (approximately 2 pages)A. Summary of recommendationB. Summary of problems, opportunities, and directivesC. Brief statement of system improvement objectivesD. Brief explanation of report contents

II. Background information (approximately 2 pages)A. List of interviews and facilitated group meetings conductedB. List of other sources of information that were exploitedC. Description of analytical techniques used

III. Overview of the current system (approximately 5 pages)A. Strategic implications (if the project is part of, or impacts an existing information

systems strategic plan)B. Models of the current system

1. Interface model (showing project scope)2. Data model (showing project scope)3. Geographic models (showing project scope)4. Process model (showing functional decomposition only)

IV. Analysis of the Current System (approximately 5-10 pages)A. Performance problems, opportunities, and cause/effect analysisB. Information problems, opportunities, and cause/effect analysisC. Economic problems, opportunities, and cause/effect analysisD. Control problems, opportunities, and cause/effect analysisE. Efficiency problems, opportunities, and cause/effect analysisF. Service problems, opportunities, and cause/effect analysis

V. Detailed recommendations (approximately 5-10 pages)A. System improvement objectives and prioritiesB. ConstraintsC. Project Plan

1. Scope reassessment and refinement2. Revised master plan3. Detailed plan for the definition phase

VI. AppendicesA. Any detailed system modelsB. (other documents as appropriate)

3/23/2008

IFS310: Week 2

The Definition Phase

• Outline Business Requirements

• Model Business System Requirements• Logical models depict what a system is, or what a

system must do – not ‘how’ the system will be implemented. Because logical models depict the essence of the system, they are sometimes called essential models

3/23/2008

IFS310: Week 2

Model Business System Requirements

Data Modeling Process Modeling Geographic Modeling (Network Modeling) Object Modeling

3/23/2008

IFS310: Week 2

The Definition Phase (cont.)

• Build Discovery Prototypes (opt.)

• Prioritize Business Requirements– Timeboxing is a technique which develops larger fully

functional systems in versions.

• Modify the Project Plan and Scope

3/23/2008

IFS310: Week 2

Deliverables

• Business Requirements Statement – “Big Picture” of the system– Trigger of the systems design

3/23/2008

IFS310: Week 2

Assignment Project

• Objectives– To be familiar with the tools of Systems

Analysis and Design.– Assignment 1 is a tutorial for MS Visio

which will be used to create diagrams (such as DFDs and ER diagrams)

– Next week, we discuss Process Modeling and Data Flow Diagrams (DFDs) and practice a series of DFDs as a group project.