Transcript Analysis Methods and Fact

Geospatial Systems Analysis and
Fact-Finding
Todd S. Bacastow
Professor of Practice
John A. Dutton e-Education Institute
The Pennsylvania State University
October 12, 2008
Analysis Methods and Fact-Finding
• Tomlinson
– Chapters 4, 5 & 6
– Chapter 6
addresses key
spatial elements
(e.g., spatial error,
topology)
– Focus on analysis
and documenting
• IPDs (info product
descriptions)
• MIDL (master input
data list)
• Etc.
• Whitten
– Chapters 5 & 6
– Systems analysis
methods
– Focus on analysis
and fact finding
• Problem statement
• Cause-and-Effect
Analysis
• System Improvement
Report
• Etc.
Owners
Analyst
•SOW
•Business Req’ts
•System Proposal
Owners
Whitten, p. 158
5-3
What is Systems Analysis?
Systems analysis – 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 – a complementary
problem-solving technique (to systems
analysis) that reassembles a system’s
component pieces back into a complete
system. This may involves adding,
deleting, and changing pieces relative to
the original system.
5-4
Model-Driven Analysis Methods
Model-driven analysis – a problemsolving 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.
Model – a representation of either reality or
vision.
5-5
Model-Driven Approaches
• Traditional Approaches
– Structured Analysis
• Focuses on the flow of data through processes
• Key model: data flow diagram
– Information Engineering
• Focuses on structure of stored data
• Key model: entity relationship diagram
• Object-Oriented Approach
– integrates data and process concerns into objects
• Object – the encapsulation of the data (called properties)
that describes a discrete person, object, place, event, or
thing, with all the processes (called methods) that are
allowed to use or update the data and properties.
– Unified Modeling Language (UML)
5-6
Accelerated Systems Analysis
Accelerated systems analysis approaches
emphasize the construction of prototypes to
more rapidly identify business and user
requirements.
prototype – a small-scale, incomplete, but
working sample of a desired system.
– Accelerated systems analysis approaches
• Discovery Prototyping
• Rapid Architected Analysis
5-7
Discovery Prototyping
Discovery prototyping – used to identify the
users’ business requirements by having them
react to a quick-and-dirty implementation.
– Advantages
• “I’ll know what I want when I see it”
– Disadvantages
• Can become preoccupied with final “look and feel”
prematurely
• Can encourage a premature commitment
• Users can be misled to believe that the completed
system can be built rapidly using prototyping tools
5-8
Rapid Architected Analysis
Rapid architected analysis – an
approach that attempts to derive
system models from existing
systems or discovery prototypes.
5-9
Requirements Discovery
Requirements discovery – the process of
identifying or extracting system problems
and solution requirements from the user
community.
5-10
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
JRP techniques to the entire systems development process.
5-11
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.
5-12
Whitten Analysis Phases
• Scope Definition Phase
–
Is the project worth looking at?
• Problem Analysis Phase
– Is a new system worth building?
• Requirements Analysis Phase
– What do the users need and want from
the new system?
• Logical Design Phase
– What must the new system do?
• Decision Analysis Phase
– What is the best solution?
5-13
Context of Scope Definition Phase
Owner scope and vision of knowledge,
functions, and communications.
5-14
Key Terms for Scope Definition Phase
Steering body (steering committee) – 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.
Project charter – the final deliverable for the
preliminary investigation phase.
A project charter defines the project scope, plan,
methodology, and standards.
– Preliminary master plan includes preliminary schedule
and resource assignments (also called a baseline plan).
– Detailed plan and schedule for completing the next
phase of the project.
5-15
Sample Problem Statements
Whitten, p. 171.
5-16
Context of Problem Analysis Phase
Problem Analysis 
scope and vision (knowledge, functions, communications)
5-17
Key Terms of the Problem Analysis Phase
Cause-and-effect analysis – a technique in
which problems are studied to determine their
causes and effects.
Context Diagram – a pictorial model that shows
how the system interacts with the world around it
and specifies in general terms the system inputs
and outputs.
5-18
Sample Cause-and-Effect Analysis
Whitten, p. 181.
5-19
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.
– Decrease by 50 percent the time required to respond
to an incident.
Constraint – something that will limit your flexibility in
defining a solution to your objectives. Essentially,
constraints cannot be changed.
– The new system must be operational by April 15.
– The new system cannot cost more than $350,000.
5-20
System Improvement Report Outline
I.
Executive summary (approximately 2 pages)
A.
B.
C.
D.
II.
Summary of recommendation
Summary of problems, opportunities, and directives
Brief statement of system improvement objectives
Brief explanation of report contents
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.
2.
3.
4.
Interface model (showing project scope)
Data model (showing project scope)
Geographical models (showing project scope)
Process model (showing functional decomposition
only)
Whitten, p. 184.
5-21
System Improvement Report Outline (cont.)
IV. Analysis of the current system (approx. 5-10 pages)
A.
B.
C.
D.
E.
F.
V.
Performance problems, opportunities, cause-effect
analysis
Information problems, opportunities, cause-effect
analysis
Economic problems, opportunities, cause-effect
analysis
Control problems, opportunities, cause-effect
analysis
Efficiency problems, opportunities, cause-effect
analysis
Service problems, opportunities, and cause-effect
analysis
Detailed recommendations (approx. 5-10 pages)
A.
B.
C.
System improvement objectives and priorities
Constraints
Project Plan
1.
2.
3.
Scope reassessment and refinement
Revised master plan
Detailed plan for the definition phase
VI. Appendixes
A.
B.
5-22
Any detailed system models
Other documents as appropriate
Context of Requirements Analysis Phase
Business Requirements Statement
results from the requirements analysis
5-23
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
5-24
Key Terms of Requirements Analysis Phase
(cont.)
Use case – a business 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.
5-25
Key Terms of Requirements Analysis Phase
(cont.)
Timeboxing – a technique that delivers information
systems functionality and requirements through
versioning.
1.
2.
3.
–
–
5-26
The development team selects the smallest subset of
the system that, if fully implemented, will return
immediate value to the systems owners and users.
That subset is developed, ideally with a time frame of
six to nine months or less.
Subsequently, value-added versions of the system
are developed in similar time frames.
A mandatory requirement is one that must be fulfilled
by the minimal system, version 1.0
A desirable requirement is one that is not absolutely
essential to version 1.0. It may be essential to the
vision of a future version.
Context of Logical Design Phase of Systems Analysis
Logical design = business req’t  system model
For data, processes, and interface
5-27
Context of Decision Analysis Phase
Goals – Constraints
•(Users – Analysis) =
System Proposal
5-28
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?
• Operational feasibility – Will the solution fulfill the
users’ requirements? To what degree? How will the
solution change the users’ work environment? How do
users feel about such a solution?
• Economic feasibility – Is the solution cost-effective?
• Schedule feasibility – Can the solution be designed
and implemented within an acceptable time period?
5-29
Candidate Systems Matrix
Whitten, p. 196.
5-30
Candidate Systems Matrix (cont.)
5-31
Feasibility Matrix
5-32
Typical System Proposal Outline
I.
II.
III.
IV.
V.
VI.
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
Tools and techniques used
A. Solution generated
B. Feasibility analysis (cost-benefit)
Information systems requirements
Alternative solutions and feasibility analysis
Recommendations
Appendices
Whitten, p. 199
Contrast with Tomlinson, pp. 17 & 54
5-33
6-34
Requirements
Introduction to Requirements Discovery
Requirements discovery – the process and
techniques used by systems analysts to identify or
extract system problems and solution requirements
from the user community.
System requirement – something that the information
system must do or a property that it must have. Also
called a business requirement.
6-35
Functional vs. Nonfunctional Requirements
Functional requirement - something the information
system must do
Nonfunctional requirement - a property or quality the
system must have
– Performance
– Security
– Costs
6-36
Results of Incorrect Requirements
• Cost more than projected.
• Delivered later than promised.
• Not meet the users’ expectations and they
may not to use it.
• Costs of maintaining and enhancing
system may be excessively high.
• Unreliable and prone to errors and
downtime.
• Failure will be perceived as a mistake by
the team.
6-37
Relative Cost to Fix an Error
Key concept!
6-38
Criteria for System Requirements
•
•
•
•
•
•
•
6-39
Consistent
Complete
Feasible
Required
Accurate
Traceable
Verifiable
Process of Requirements Discovery
6-40
Problem
discovery and
analysis
Requirements
discovery
Documenting
and analyzing
requirements
Requirements
management
Ishikawa Diagram
• Graphical tool used to identify, explore, and depict
problems and the causes and effects of those
problems. It is often referred to as a cause-and-effect
diagram or a fishbone diagram.
– Problem at right (fish head)
– Possible causes drawn as "bones" off main backbone
– Brainstorm for 3-6 main categories of possible causes
6-41
Requirements Discovery
• Given an understand of problems, the systems analyst
can start to define requirements.
Fact-finding – the formal process of using research,
meetings, interviews, questionnaires, sampling, and
other techniques to collect information about system
problems, requirements, and preferences. It is also
called information gathering or data collection.
6-42
Documenting and Analyzing Requirements
• Documenting the draft requirements
– Use cases
– Decision tables
– Requirements tables
• Analyzing requirements to resolve
problems
–
–
–
–
–
Missing requirements
Conflicting requirements
Infeasible requirements
Overlapping requirements
Ambiguous requirements
• Formalizing requirements
– Requirements definition document
– Communicated to stakeholders or steering body
6-43
Requirements Definition Document
Requirements Definition Document – A
formal document that communicates the
requirements of a proposed system to key
stakeholders and serves as a contract for
the systems project.
• Synonyms
–
–
–
–
6-44
Requirements definition report
Requirements statement
Requirements specification
Functional specifications
Sample Requirements Definition Report
Outline
Whitten p. 214
6-45
Requirements Management
Requirements management - the process
of managing change to the requirements.
– Over the lifetime of the project it is very common
for new requirements to emerge and existing
requirements to change.
– Studies have shown that over the life of a project
as much as 50 percent or more of the requirements
will change before the system is put into
production.
6-46
Fact-Finding Ethics
• Fact-Finding often brings systems analysts into
contact with sensitive information.
– Company plans
– Employee information
– Customer information
• Ethical behavior
– Must not misuse information.
– Must protect information from people who would
misuse it.
• Otherwise
– Lose respect, credibility, and confidence
– Legal liability
– Lose job
6-47
Fact-Finding Methods
• Sampling of existing documentation,
forms, and databases.
• Research and site visits.
• Observation of the work environment.
• Questionnaires.
• Interviews.
• Prototyping.
• Joint requirements planning (JRP).
6-48
Sampling Existing Documentation, Forms, & Files
Sampling –process of collecting a
representative sample of documents, forms, and
records.
– Organization chart
– Memos and other documents that describe
the problem
– Standard operating procedures for current
system
– Completed forms
– Manual and computerized screens and
reports
– Samples of databases
– Flowcharts and other system documentation
– And more
6-49
Things to be Gleaned from Documents
• Symptoms and causes of problems
• Persons in organization who have
understanding of problem
• Business functions that support the
present system
• Type of data to be collected and
reported by the system
• Questions that need to be covered in
interviews
6-50
Sampling Techniques
Randomization – a sampling technique
characterized by having no
predetermined
pattern or plan for selecting sample data.
Stratification – a systematic sampling
technique that attempts to reduce the
variance of the estimates by spreading
out the sampling—for example, choosing
documents or records by formula—and
by avoiding very high or low estimates.
6-51
Observation
Observation – a fact-finding technique
wherein the systems analyst either
participates in or watches a person perform
activities to learn about the system.
Advantages?
Disadvantages?
Work sampling - a fact-finding technique
that involves a large number of observations
taken at random intervals.
6-52
Observation
Advantages
• Data gathered can be
very reliable
• Can see exactly what
is being done in
complex tasks
• Relatively inexpensive
compared with other
techniques
• Can do work
measurements
6-53
Disadvantages
• People may perform
differently when being
observed
• Work observed may
not be representative
of normal conditions
• Timing can be
inconvenient
• Interruptions
• Some tasks not
always performed the
same way
• May observe wrong
way of doing things
Observation Guidelines
• Determine the who, what, where, when,
why, and how of the observation.
• Obtain permission from appropriate
supervisors.
• Inform those who will be observed of the
purpose of the observation.
• Keep a low profile.
• Take notes.
• Review observation notes with
appropriate individuals.
• Don't interrupt the individuals at work.
• Don't focus heavily on trivial activities.
• Don't make assumptions.
6-54
Questionnaires
Questionnaire – a special-purpose document that
allows the analyst to collect information and opinions
from respondents.
Free-format questionnaire – a questionnaire
designed to offer the respondent greater latitude in the
answer. A question is asked, and the respondent
records the answer in the space provided after the
question.
Fixed-format questionnaire – a questionnaire
containing questions that require selecting an answer
from predefined available responses.
6-55
Questionnaires
Advantages
• Often can be
answered quickly
• People can complete
at their convenience
• Relatively
inexpensive way to
gather data from a
large number
• Allow for anonymity
• Responses can be
tabulated quickly
6-56
Disadvantages
• Return rate is often
low
• No guarantee that
an individual will
answer all questions
• No opportunity to
reword or explain
misunderstood
questions
• Cannot observe
body language
• Difficult to prepare
Types of Fixed-Format Questions
• Multiple-choice questions
• Rating questions
• Ranking questions
Rank the following transactions according to the amount of
time you spend processing them.
___ % making maps
___ % entering data
___ % overlay analysis
___ % data editing
The implementation of handheld entry devices
would cause an increase in data accuracy.
___ Strongly agree
___ Agree
___ No opinion
Is the current infrastructure report
___ Disagree
that you receive useful?
___ Strongly disagree ___ Yes
___ No
6-57
Developing a Questionnaire
1. Determine what facts and opinions must be
collected and from whom.
2. Determine whether free- or fixed-format
questions will produce the best answers.
3. Write the questions.
4. Test the questions.
5. Duplicate and distribute the questionnaire.
6-58
Interviews
Interview - a fact-finding technique
whereby the systems analysts collect
information from individuals through
face-to-face interaction.
–
–
–
–
–
–
–
6-59
The personal interview
is generally recognized
as the most important
and most often used
fact-finding technique.
Find facts
Verify facts
Clarify facts
Generate enthusiasm
Get the end-user involved
Identify requirements
Solicit ideas and opinions
Types of Interviews and Questions
Unstructured interview –conducted with only a
general goal or subject in mind and with few, if
any, specific questions.
The interviewer counts on the interviewee to
provide a framework and direct the conversation.
Structured interview –interviewer has a specific
set of questions to ask of the interviewee.
Open-ended question – question that allows the
interviewee to respond in any way.
Closed-ended question – a question that
restricts answers to either specific choices or
short, direct responses.
6-60
Interviews
Advantages
Disadvantages
• Give analyst
• Time-consuming
opportunity to motivate • Success highly
interviewee to respond
dependent on analyst's
freely and openly
human relations skills
• Allow analyst to probe • May be impractical due
for more feedback
to location of
• Permit analyst to adapt
interviewees
or reword questions for
each individual
• Can observe
nonverbal
communication
6-61
Procedure to Conduct an Interview
1. Select Interviewees
– End users
– Learn about individual prior to the interview
2. Prepare for the Interview
– interview guide
3. Conduct the Interview
– Summarize the problem
– Offer an incentive for participation
– Ask the interviewee for assistance
4. Follow Up on the Interview
– Memo that summarizes the interview
6-62
Prepare for the Interview
• Types of Questions to Avoid
– Loaded questions
– Leading questions
– Biased questions
• Interview Question Guidelines
– Use clear and concise language.
– Don’t include your opinion as part of the
question.
– Avoid long or complex questions.
– Avoid threatening questions.
– Don’t use “you” when you mean a group of
people.
6-63
Conduct the Interview
•
•
•
•
Dress to match interviewee
Arrive on time
Open interview by thanking interviewee
State purpose and length of interview and
how data will be used
• Monitor the time
• Ask follow-up questions
– Probe until you understand
– Ask about exception conditions ("what if...")
6-64
Interviewing Do’s and Don’ts
Do
•
•
•
•
•
•
•
•
•
•
6-65
Dress appropriately
Be courteous
Listen carefully
Maintain control of the
interview
Probe
Observe mannerisms
and nonverbal
communication
Be patient
Keep interviewee at
ease
Maintain self-control
Finish on time
Don't
• Assume an answer
is finished or leading
nowhere
• Reveal verbal and
nonverbal clues
• Use jargon
• Reveal personal
biases
• Talk more than listen
• Assume anything
about the topic or
the interviewee
• Tape record (take
notes instead)
Discovery Prototyping
Discovery prototyping – the act of
building a small-scale, representative
or working model of the users’
requirements in order to discover or
verify those requirements.
6-66
Discovery Prototyping
Advantages
• Can experiment to
develop
understanding of how
system might work
• Aids in determining
feasibility and
usefulness of system
before development
• Serves as training
mechanism
• Aids in building test
plans and scenarios
• May minimize time
spent on fact-finding
6-67
Disadvantages
• Developers may need
to be trained in
prototyping
• Users may develop
unrealistic
expectations
• Could extend
development schedule
Joint Requirements Planning
Joint requirements planning (JRP) – a process
whereby highly structured group meetings are
conducted for the purpose of analyzing problems and
defining requirements.
– JRP is a subset of a more comprehensive joint
application development or JAD technique that
encompasses the entire systems development process.
6-68
JRP Participants
•
•
•
•
•
6-69
Sponsor
Facilitator
Users and Managers
Scribes
IT Staff
Steps to Plan a JRP Session
1. Selecting a location
– Away from workplace when possible
– Requires several rooms
– Equipped with tables, chairs, whiteboard,
overhead projectors
– Needed computer equipment
2. Selecting the participants
– Each needs release from regular duties
3. Preparing the agenda
– Briefing documentation
– Agenda distributed before each session
6-70
Guidelines for Conducting a JRP Session
•
•
•
•
•
•
•
•
Do not unreasonably deviate from the agenda
Stay on schedule
Ensure that the scribe is able to take notes
Avoid the use of technical jargon
Apply conflict resolution skills
Allow for ample breaks
Encourage group consensus
Encourage user and management participation
without allowing individuals to dominate the session
• Make sure that attendees abide by the established
ground rules for the session
6-71
Brainstorming
• Sometimes, one of the goals of a JRP session is to
generate possible ideas to solve a problem.
– Brainstorming is a common approach that is used for this
purpose.
Brainstorming – a technique for generating ideas by
encouraging participants to offer as many ideas as
possible in a short period of time without any analysis
until all the ideas have been exhausted.
6-72
Brainstorming Guidelines
• Isolate appropriate people in a place that free from
distractions and interruptions.
• Make sure everyone understands purpose of the
meeting.
• Appoint one person to record ideas.
• Remind everyone of brainstorming rules.
• Within a specified time period, team members call
out their ideas as quickly as they can think of them.
• After group has run out of ideas and all ideas have
been recorded, then and only then should ideas be
evaluated.
• Refine, combine, and improve ideas generated
earlier.
6-73
Benefits of JRP
• JRP actively involves users and management
in the development project (encouraging
them to take “ownership” in the project).
• JRP reduces the amount of time required to
develop systems.
• When JRP incorporates prototyping as a
means for confirming requirements and
obtaining design approvals, the benefits of
prototyping are realized
6-74
A Fact-Finding Strategy
1. Learn from existing documents, forms, reports, and
files.
2. If appropriate, observe the system in action.
3. Design and distribute questionnaires to clear up things
that aren’t fully understood.
4. Conduct interviews (or group work sessions).
5. (Build discovery prototypes for any functional
requirements that are not understood or for
requirements that need to be validated.)**
6. Follow up to verify facts.
** Optional and not always possible
6-75
Back to Tomlinson
• Tomlinson is:
–
–
–
–
Based on 40+ years of experience
Uses a structured method
Considers important spatial concepts Whitten does not include
Often unfamiliar to organizations that are now getting into
spatial.
– Highlights the importance of a well conceived approach.
– Highlights the importance of understanding the user’s
information needs over a focus on software and hardware.
• Key points:
– Most organizations do not mandate a single
development approach (structured analysis, OOA).
– Many integrate many popular development approaches
(Agile).
– System developers need the flexibility to select from a
variety of techniques to best accomplish the tasks.
– Most geospatial systems are developed use a mixture.
– Understanding the users needs are critical.