A Professional's Guide to Systems Analysis, Second Edition
by Martin Modell
McGraw-Hill Book Company, New York, NY; 1996
Author's Note: This book is currently out of print. It is reproduced here from the author's original manuscript and does not reflect the editing and revisions by the publisher - McGraw-Hill. The illustrations have been been scanned from a published copy of the book.
This electronic version and its illustrations are copyright to both McGraw-Hill and the author Martin Modell, and as such may not be copied or reproduced in any manner. This text is posted for and its contents may be used for educational purposes - limited portions may be cited. Any portions of the content thus cited must contain the copyright information to be found at the bottom of each chapter and at the bottom of this page
Why Systems Analysis?
What Is a System?
What Is a Systems Analyst?
The Roles of the Systems Analyst
Concerns of the Systems Analyst
Information Systems Analysis as a Task of Data Processing
Information Systems Projects Categorized by Scope
Business Systems Projects as a Method of Organizational Change
Business Process Reengineering
Total Quality Management
The Physician's Analogy
Reasons For Initiating Information Systems Analysis Projects
The Three Types of Systems Analysis Projects
The Organization as a Multilevel Entity
The Four Stages of EDP Growth
Operational versus Informational Systems
Personal, Departmental and Corporate Systems
What Is a System development Life Cycle?
The Purpose of a Methodology
The Need for a Methodology
Methodology
System Development Life Cycle Phases
Project Initiation
Reviews
Five phases of the Business Process Reengineering life cycle
Cost-Benefit Analysis
Project Development Costs
User and Project Implementation Costs
Analysis
Multiple Levels of Analysis
Three-Phase Approach to Analysis
Validation of the Analysis
Walk-Throughs
Input/Output Validation
Data Source to Use
Basic Systems - Wholly Manual
Intermediate Systems - Partially Manual And Partially Automated
Mature Systems - Fully Automated
Effects Of Prior Automation
Forms Of Reautomation
What Is an Interview?
Types of Interviews
Interviewing Components
What Are the Goals of the Interview?
Interviewing Guidelines
Dos and Don'ts of Interviewing
Who to Interview
The Need for Documentation
Functions of Documentation
Documenting the Interview
Dos and Don'ts of Documentation
Report Format Style Guidelines
Non-Interview Data Gathering Methods
Joint Applications Design (JAD) and Joint Requirements Analysis (JRA)
Prototyping
Introduction
Why a Dictionary?
What Is Data Administration?
Dictionary Design
Information Systems Components
Business Systems Components
Data and Process Model Components
How Does a Dictionary Function?
How Can the Dictionary Assist the Analysis Function?
Dictionaries, Encyclopedias and Repositories
The Entity-Relationship Approach
Entity-Relationship Analysis
Classification Analysis
Categorization as a fundamental process
Classification of Entities
Types, Subtypes and Groups
Entity Families
Active versus Passive Entities
Process Control Entities
Entity Definition
Entity Family versus Entity Group Reference
Distinguishing between Entities (Entity Roles)
Data Acquisition and Retention
Describing Process Control Entities
Modeling and Diagramming Techniques
The Entity-Relationship Model
The Enterprise Level
The Entity-Relationship Level
The Entity-Relationship-Attribute Level
The Entity-Relationship-Attribute-Data Level
Construction of an Entity-Relationship Diagram
Documentation of the Model
Data Flow Diagrams
Flowchart Diagrams
Hierarchic Process Diagrams
IDEF Diagrams
Part II - Analysis
Remember:
The more things change the more they remain the same.
Yet, the only thing constant in life is change
What Is a Function?
Two Categories of Business Functions
Business Function Analysis
Some Questions to Be Asked during Functional Analysis
Business Function Analysis Documentation
User Personal Computer/Workstations
Additional Documentation to Include, If Available
The Need for a Business Function Model
The Business Life Cycle Matrix
Developing the Functional Model
What Is a Business Process?
Business Process Analysis
Some Questions to Be Asked during Process Analysis
Business Process Analysis Documentation
User Specific Interview Questions
User Applications
Additional Documentation to Be Included, If Available
The Need for Business Process Models
Business Process Entities versus Processes
Process Entity-Relationship Models
Guidelines for Developing a Process Model
What Is a Task?
Business Task Analysis
Some Questions to Be Asked during Task Analysis
Task Modeling
Data Event Modeling
Deductive and Inductive Development
Data Actions
Data Action Symbols
Data Access Sequence
Types of Data Events
Relationship to Data Entity Time Line
Data Event Independence
Data Event Sources
Data Event triggers
Data Event Trigger Contents
Data Event Frames of reference
Sequential data Access
Data Event Assumptions
Separation of Data Event Types
Validating the Analysis
Walk Throughs
Input/Output Validation
Data-Source-to-Use Validation
Consistency Analysis
Level-to-Level Consistency
Carrier-to-Data Consistency
Process-to-Process Consistency
Other Analytical Techniques
Zero-Based Analysis
Data Event Analysis
Methods and Procedures Analysis
General to Specific Analysis
Evaluation Of Existing Systems Components
Level to Level Evaluation
Carrier to Data Evaluation
Process to Process Evaluation
Zero-based Evaluation
Problem Identification
Systems Design Requirements Documentation
Prioritization Of Changes
Dependency ranking
Synergy or Impact/Benefit Ranking
Cost Benefit Ranking
Cost-Benefit Ranking
Make Versus Buy Decisions
Cost-Benefit Analysis
Project Development Costs
User And Project Implementation Costs
Benefits
Additional Analysis Techniques
Risk Identification and Mitigation
Four Steps of Risk Management
Risk Issues
Part IV - Analysis Issues
The objective of all dedicated employees should be to thoroughly analyze all situations,
anticipate all problems prior to their occurrence,
have answers for these problems,
and move swiftly to solve these problems when called upon....
However, when you are up to your ears in alligators,
it is difficult to remind yourself that your initial objective was to drain the
swamp.
Top-Down versus Bottom-Up Analysis
On-Line versus Batch Systems
Issues Affecting the On-Line versus Batch Decision
Mainframe, Mini, and Micro Systems
Micro, Mini, or Mainframe Issues
Integrated Systems versus Stand-Alone
Make-versus-Buy Decisions
Make-versus-Buy Issues
Package Evaluation and Selection
Examining the Buy Option
What Is a Database?
Centralized versus Decentralized Data Bases
Management Levels
Replication of Data
The Centralized Database Environment
The Decentralized Database Environment
Common Database Types
A Comparison of DBMS Data Structure Options
DBMS Selection Criteria for Mainframe Systems
Process-directed Analytical Methodology
Data-directed Analytical Methodology
User Views
Data-directed Analysis and the Entity-Relationship Approach
Data Administration
Database Administration
The Changing Micro Environment
Microcomputer Systems
Network communications
Developer Tool Kits
Table-driven or Rules-driven Applications
Network communication issues:
Client server databases:
Client Server Issues
Facilities Management and Outsourcing
Security
What Is Security?
Security Analysis
Physical Access Security
Personal Computer Security
System Administration
Controls
Auditing and Auditability
The Concept of Time
Configuration management
Change Management
Disaster/Emergency Preparedness
Part V - Applications
Laws of Project Management
No major project is ever installed on time, within budget, with the same staff that started it. Yours will not be the first.
Projects progress quickly until they become 90 percent complete; they then remain at 90 percent complete forever.
One advantage of fuzzy project objectives is that they let you avoid the embarrassment of estimating the corresponding costs.
When things are going well, something will go wrong.
When things just can't get any worse, they will.
When things appear to be going better, you have overlooked something.
If project content is allowed to change freely, the rate of change will exceed the rate of progress.
No system is ever completely debugged: Attempts to debug a system inevitably introduce new bugs that are even harder to find.
A carelessly planned project will take three times longer to complete than expected, a carefully planned project will take only twice as long.
Project teams detest progress reporting because it vividly manifests their lack of progress.
The Typical Business Flow
Order Processing
Inventory
Customer Service
Accounts Payable and Accounts Receivable
General Ledger
Marketing and Sales
Payroll and Personnel
Time and Attendance Collection Systems
Automation of Routine Request for Action forms
Cases
Notes and Guidelines on Case Study Use
Apex Biscuit Company
National Association for the Advancement of Data Processing
System for Centralized Library Order Processing Services (SYCLOPS)
Studentext Publishing Company
The Last National Bank and Trust Company
Verylarge Full Service Brokerage Company