SYSTEMS ANALYSIS
Chapter Five
Systems Analysis
• Define systems analysis
• Describe the preliminary investigation, problem
•
•
analysis, requirements analysis, and decision analysis
phases in terms of your information system building
blocks, and in terms of purpose, participants, inputs,
outputs, techniques, and steps.
Although some of the tools and techniques of systems
analysis are introduced in this chapter, it is not the
intent of this chapter to teach those tools and
techniques.
This chapter teaches only the process of systems
analysis. The tools and techniques will be taught in
the subsequent five chapters.
WHAT IS SYSTEMS ANALYSIS?
Systems Analysis vs. Systems Design
• Systems analysis is
–
–
–
a problem-solving technique
that decomposes a system into its component pieces
for the purpose of studying how well those component parts
work and interact to accomplish their purpose.
• Systems design (also called systems synthesis) is
–
–
–
a complementary problem-solving technique to systems
analysis,
that reassembles a system’s component pieces back into a
complete system—hopefully, an improved system.
This may involves adding, deleting, and changing pieces
relative to the original system.
• See Figure 5.1
Figure 5.1 The Context of Systems Analysis
Information Systems Analysis
Information systems analysis is defined as those
development phases in a project that primarily
focus on the business problem, independent of
any technology that can or will be used to
implement a solution to that problem.
SYSTEMS ANALYSIS APPROACHES
Systems Analysis Approaches
• Systems Analysis Approaches
– Model-Driven Analysis Approaches
•
•
•
Structured analysis
Information engineering (IE)
Object-oriented analysis (OOA)
– Accelerated Analysis Approaches
• Discovery prototyping
• Rapid architecture analysis
•
The intend here is to develop a high-level understanding only,
Subsequent chapters will teach you the techniques.
Model-Driven Analysis Approaches
Model-Driven Analysis Methods
• Model-driven analysis
– 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.
• A model
– is a representation of either reality or vision.
– Just as “a picture is worth a thousand words,” most
models use pictures to represent the reality or vision.
– e.g. flowcharts, organization charts
Model-Driven Methods
• Structured analysis
•
Information engineering (IE)
• Object-oriented analysis (OOA)
Model-Driven Methods
• Structured analysis is a model-driven, processcentered technique used to either analyze an existing
system, define business requirements for a new
system, or both.
• The models are pictures that illustrate the system’s
component pieces: processes and their associated
inputs, outputs, and files.
• By process-centered, we mean the emphasis in this
technique is on the process building blocks in the
information system framework.
• Systems analysts draw a series of process models
called data flow diagrams (DFD). See Figure 5.2.
Figure 5.2 A Simple Process Model
Model-Driven Methods
•
Information engineering (IE) is a model-driven and data-centered, but
process-sensitive technique to plan, analyze, and design information
systems.
•
IE models are pictures that illustrate and synchronize the system’s data
and processes.
•
The data models in IE are called entity relationship diagrams (ERDs).
•
IE use the same data flow diagrams of structured analysis.
•
System analyst draw ERDs to model the system’s raw data before they
draw DFDs that illustrate how that data will be captured, stored, used, and
maintained.
•
See Figure 5.3 A simple ERD
Figure 5.3 A Simple Data Model
Model-Driven Methods
• Object-oriented analysis (OOA) is a model-driven
technique that integrates data and process concerns
into constructs called objects.
• OOA models are pictures that illustrate the system’s
objects from various perspectives such as structure
and behavior.
• OOA has become so popular that a modeling
standard has evolved around it. The Unified
Modeling Language (UML) provide a graphical
syntax for an entire series of object models.
• See Figure 5.4.
Figure 5.4 A Simple Object Model
STUDENT
COURSE
-ID Number
-Name
-Grade Point Average
0..*
has record for>
+Admit()
+Regsiter for Classes()
+Withdraw()
+Change Address()
+Calculate GPA()
1
+Graduate()
0..*
-Subject
-Number
-Title
-Credit
+Create a Course()
+Delete from
Course Master()
1
+Change in Course Master()
TRANSCRIPT COURSE
-Semester
-Division
-Grade
+Add()
+Drop()
+Complete()
+Change Grade()
Accelerated Analysis Approaches
Accelerated Analysis Methods
• Accelerated analysis approaches emphasize the
construction of prototypes to more rapidly identify
business and user requirements for a new system.
• A prototype is a small-scale, incomplete, but working
sample of a desired system. Prototypes provide to the
“I’ll know what I want when I see it” way of thinking
that is characteristic of many users and managers.
• These approaches emphasize the interface building
blocks by constructing sample forms and reports.
• These approaches are common in rapid application
development (RAD) methodologies.
Accelerated Analysis Methods
• Discovery prototyping (sometimes called
requirements prototyping) is used to identify the users’
business requirements by having them react to a quickand-dirty implementation of those requirements.
• Rapid architecture analysis is an approach that
attempts to derive system models (as described earlier
in this section) from existing systems or discovery
prototypes.
–
Reverse engineering technology reads the program code for a
database, application program, and/or user interface and
automatically generates the equivalent system model.
Requirements Discovery Methods
Requirements Discovery Methods
• Requirements discovery includes those
techniques to be used by systems analysts to
identify or extract system problems and
solution requirements from the user
community.
– Fact-Finding Techniques
– Joint Requirements Planning (JRP) techniques
Requirements Discovery Methods
• Fact-finding (or information gathering) is a classical set
of techniques used to collect information about system
problems, opportunities, solution requirements, and
priorities.
– Sampling of existing documentation, reports, forms, files
– Research of relevant literature
– Observation of the current system in action and work
environment
– Questionnaires and surveys of the management and
user
– Interviews of managers, users, and technical staff
• These techniques covered in the next chapter.
Requirements Discovery Methods
• Joint Requirements Planning (JRP) techniques use
facilitated workshops to bring together all of the system
owners, system users, systems analysts, and some
systems designer and builders to jointly perform systems
analysis.
• JRP is generally considered a part of Joint Application
Development (JAD), which is to the entire system
development process.
• JRD workshop will typically run from three to five full
working days. This workshop can replace weeks or
months of classical fact-finding meetings.