Professional Documents
Culture Documents
Systems Analysis
4-4
Repository
Repository – a location (or set of locations)
where systems analysts, systems designers,
and system builders keep all of the
documentation associated with one or more
systems or projects.
– Network directory of computer-generated files that
contain project correspondence, reports, and data
– CASE tool dictionary or encyclopedia (Chapter 2)
– Printed documentation (binders and system
libraries)
– Intranet website interface to the above components
4-5
Model-Driven Analysis Methods
Model-driven analysis – a problem-solving
approach that emphasizes the drawing of pictorial
system models to document and validate both
existing and/or proposed systems. Ultimately, the
system model becomes the blueprint for designing
and constructing an improved system.
4-8
A Simple Data Model
4-9
A Simple Object Model
4-10
Accelerated Systems Analysis
Accelerated systems analysis
approaches emphasize the construction
of prototypes to more rapidly identify
business and user requirements for a
new system.
– Advantages
• Prototypes cater to the “I’ll know what I want when I see it” way
of thinking that is characteristic of many users and managers.
– Disadvantages
• Can become preoccupied with final “look and feel” prematurely
• Can encourage a premature focus on, and commitment to, design
• Users can be misled to believe that the completed system can be
built rapidly using prototyping tools
4-12
Rapid Architected Analysis
4-14
Requirements Discovery
Methods
• Fact-finding – the process of collecting information
about system problems, opportunities, solution
requirements, and priorities.
– Sampling existing documentation, reports, forms, databases, etc
– Research of relevant literature
– Observation of the current system
– Questionnaires and surveys
– Interviews
• Joint requirements planning (JRP) –use of facilitated
workshops to bring together all of the system owners,
users, and analysts, and some systems designer and
builders to jointly perform systems analysis.
– Considered a part of a larger method called joint application
development (JAD), a more comprehensive application of the
4-15
JRP techniques to the entire systems development process.
Business Process Redesign
4-16
Agile Methods
Agile method – integration of various
approaches of systems analysis and design for
applications as deemed appropriate to problem
being solved and the system being developed.
4-19
Key Terms for Scope Definition
Phase
Steering body – a committee of executive business and
system managers that studies and prioritizes competing
project proposals to determine which projects will return
the most value to the organization and thus should be
approved for continues systems development.
– Also called a steering committee.
4-21
Sample Problem Statements
4-22
Tasks of the Problem Analysis
Phase
4-23
Key Terms of the
Problem Analysis Phase
Cause-and-effect analysis – a technique in which
problems are studied to determine their causes and
effects.
In practice, effects can be symptomatic of more deeply
rooted problems which, in turn, must be analyzed for
causes and effects until the causes and effects do not
yield symptoms of other problems.
4-25
Sample Context Diagram
4-26
Key Terms of the
Problem Analysis Phase (cont.)
Objective – a measure of success. It is something that you
expect to achieve, if given sufficient resources.
4-27
System Improvement Report
Outline
I. Executive summary (approximately 2 pages)
A. Summary of recommendation
B. Summary of problems, opportunities, and directives
C. Brief statement of system improvement objectives
D. Brief explanation of report contents
II. Background information (approximately 2 pages)
A. List of interviews and facilitated group meetings conducted
B. List of other sources of information that were exploited
C. Description of analytical techniques used
III. Overview of current system (approximately 5 pages)
A. Strategic implications (if project is part of or impacts
existing IS strategic plan)
B. Models of the current system
1. Interface model (showing project scope)
2. Data model (showing project scope)
3. Geographical models (showing project scope)
4-28 4. Process model (showing functional decomposition only)
System Improvement Report
Outline (cont.)
IV. Analysis of the current system (approx. 5-10 pages)
A. Performance problems, opportunities, cause-effect analysis
B. Information problems, opportunities, cause-effect analysis
C. Economic problems, opportunities, cause-effect analysis
D. Control problems, opportunities, cause-effect analysis
E. Efficiency problems, opportunities, cause-effect analysis
F. Service problems, opportunities, and cause-effect analysis
V. Detailed recommendations (approx. 5-10 pages)
A. System improvement objectives and priorities
B. Constraints
C. Project Plan
1. Scope reassessment and refinement
2. Revised master plan
3. Detailed plan for the definition phase
VI. Appendixes
A. Any detailed system models
4-29
B. Other documents as appropriate
Requirements Analysis Phase
Tasks
4-30
Key Terms of
Requirements Analysis Phase
Functional requirement – a description
of activities and services a system must
provide.
• inputs, outputs, processes, stored data
Nonfunctional requirement – a
description of other features,
characteristics, and constraints that
define a satisfactory system.
• Performance, ease of learning and use, budgets,
deadlines, documentation, security, internal
auditing controls
4-31
Key Terms of Requirements
Analysis Phase (cont.)
Use case – a business scenario or event for
which the system must provide a defined
response. Use cases evolved out of object-
oriented analysis; however, their use has
become common in many other
methodologies for systems analysis and
design.
4-32
Key Terms of Requirements
Analysis Phase (cont.)
Timeboxing – a technique that delivers information
systems functionality and requirements through
versioning.
1. The development team selects the smallest subset of the system
that, if fully implemented, will return immediate value to the
systems owners and users.
2. That subset is developed, ideally with a time frame of six to nine
months or less.
3. Subsequently, value-added versions of the system are
developed in similar time frames.
4-34
Tasks for Decision Analysis
Phase
4-35
Key Terms of Decision Analysis
Phase
• Technical feasibility – Is the solution technically
practical? Does our staff have the technical expertise
to design and build this solution?
4-36
Candidate Systems Matrix
4-37
Candidate Systems Matrix
(cont.)
4-38
Feasibility Matrix
4-39
Typical System Proposal
Outline
I. Introduction
A. Purpose of the report
B. Background of the project leading to this report
C. Scope of the report
D. Structure of the report
II. Tools and techniques used
A. Solution generated
B. Feasibility analysis (cost-benefit)
III. Information systems requirements
IV. Alternative solutions and feasibility analysis
V. Recommendations
4-40 VI. Appendices