Modern Systems Analysis
and Design
Seventh Edition
Jeffrey A. Hoffer
Joey F. George
Joseph S. Valacich
Chapter 6
Analysis: Determine Requirements
Outline
• Gathering Information
–
–
–
–
–
Site visits
Documentation review
Observation
Questionnaires
Interviews
• Analysis (Milestone 2)
–
–
–
–
–
–
–
Stmt of User Environment
Problems/Causes/Effects
Objectives (Measurable)
Assumptions
Stmt of User/System Requirements
Recommendation
Supporting documentation
Introduction to Requirements Discovery
User/System Requirement (or business requirement)
• A description of the needs and desires for an information
system.
• May describe functions, features (attributes), and constraints.
Functional Requirement
• A function or feature that must be included in an IS in order to
satisfy the business need and be acceptable to the users.
Nonfunctional Requirement
• A description of the features, characteristics, and attributes of
the system as well as any constraints that may limit the
boundaries of the proposed solution.
An Ambiguous Requirements Statement
Requirement:
Create a means to transport a single
individual from home to place of work.
Management
Interpretation
IT
Interpretation
User
Interpretation
Results of Incorrect Requirements
• The system may cost more than projected.
• The system may be delivered later than promised.
• The system may not meet the users’ expectations and
that dissatisfaction may cause them not to use it.
• Once in production, the costs of maintaining and
enhancing the system may be excessively high.
• The system may be unreliable and prone to errors and
downtime.
• The reputation of the IT staff on the team is tarnished
because any failure, regardless of who is at fault, will
be perceived as a mistake by the team.
Relative Cost to Fix an Error
Phase in Which Found
Cost Ratio
Requirements
1
Design
3-6
Coding
10
Development Testing
15-40
Acceptance Testing
30-70
Operation
40-1000
Criteria to Define System Requirements
• Consistent
• Complete
• Feasible
• Required
• Accurate
• Traceable
• Verifiable
Phase 2: Analysis
A. Determine system requirements
B. Structure requirements
1. Process modeling
2. Logic modeling
3. Data modeling
C. Select best alternative
Phase 2A: Determine System Requirements (Milestone 2)
• Study and analyze the current system (gather and
study facts)
• Define and prioritize requirements
Study and Analyze Current System
• Gather info on what the system should do from as
many sources as possible
• Concentrate on WHAT is needed, not HOW to do it
• “Don’t try to fix it unless you understand it”
• Major problem: analyst not understanding user needs
Study and Analyze Current System
Activities
1. Learn about current system (gather facts)
2. Model current system
3. Analyze problems/opportunities (study facts)
4. Establish new system objectives
Learn About Current System (Gather Facts)
Gather info from:
– Current info system:
• A current IS may exist
– External sources:
• Reviewing other IS outside the organization can reveal
practical ideas and techniques
– Internal sources:
• Single most important source of facts is the user
• Existing paperwork or documents is also a good source
Fact-Finding Methods
• Research and site visits
• Existing documentation
• Observation
• Questionnaires
• Interviews
Existing Documentation
Helps to identify:
• Missing information
• Redundant steps
• Key individuals in the organization
• Special information processing circumstances
• Reason why the current system is designed the way it
is
• Data
• Rules for processing data
• Organization principles by which it operates
• Etc.
Observation
Observation
• Fact-finding technique wherein the systems analyst
either participates in or watches a person perform
activities to learn about the system
Advantages?
Disadvantages?
– Serves as a good method to supplement interviews
– Often difficult to obtain unbiased data
• People often work differently when being observed
Observation Guidelines
• Determine the who, what, where, when, why, and how of the
observation.
• Obtain permission from appropriate supervisors or managers.
• Inform those who will be observed of the purpose of the
observation.
• Keep a low profile.
• Take notes during or immediately following the observation.
• Review observation notes with appropriate individuals.
• Don't interrupt the individuals at work.
• Don't focus heavily on trivial activities.
• Don't make assumptions.
Types of Questionnaires
Free-Format Questionnaires
• 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 Questionnaires
• Contain questions that require selection of predefined
responses from individuals.
Questionnaire Types
• Open-ended (free format)
• Closed-ended (fixed format)
–
–
–
–
Multiple choice
Rating
Ranking
Single fact
Questionnaire Development
1. Determine what facts need to be collected
2. Determine whether free- or fixed-format is best.
Usually, a combination is used.
3. Write the questions. Examine them carefully. Make
sure the questions don’t reflect your personal biases.
4. Test the questions on a small sample of respondents.
Modify those questions that respondents had
problems with.
5. Duplicate and distribute the questionnaire.
Questionnaires – the Good and the Bad
Advantages
–
–
–
–
Can be quickly answered
Cheap for gathering data from a large number of users
Allow users to maintain anonymity
Responses can be tabulated and analyzed quickly
Disadvantages
–
–
–
–
–
–
Number of respondents is often low
No guarantee that the user will answer all the questions
Inflexible – voluntary info is stifled
Elimination of body cues
No immediate opportunity to clarify an answer
Good questionnaires are difficult to prepare
The King's Companion
The King called his wizard, Harry, into his chambers. "Harry, I require a
companion. I want you to find one for me. She must be strong and capable,
yet warm and affectionate. She must be intelligent, yet loyal and accepting of
my supreme authority. She must be attractive, yet find me loveable. She must
be able to entertain herself, yet be ready to cheerfully accompany me
anywhere at a moments notice. She must be quick to joy, slow to anger, and
must never criticize me. Oh - and Harry - I need her by tonight."
Harry stared at the King. After a long pause, he started to speak. The King
abruptly stood up and waved him away. "I have given you my requirements.
You are a powerful wizard, I know you can find the perfect companion for me
- now go."
Harry slowly nodded and retired to his tower.
Several hours later, while eating his supper, the King allowed himself to dream
about the wonderful woman the wizard would bring to him. She would be
sweet and warm, yet strong and intelligent. Surely, she would be the queen to
match his magnificent kingliness. He chortled as he thought about the other
kings with their chatty, stupid queens. They will most certainly envy him at
next month's Monarch Golf Tournament and Banquet.
Imagine the King's surprise when Harry arrived at the door with a beautiful
golden retriever. Imagine Harry's frustration as he was led to the dungeon.
Harry's yells can still be heard echoing in the vast corridors of the castle....
"But..... you said you wanted...."
The King's Companion
Moral: If you do not allow open two-way
discussion about your requirements, you may
be given a solution that meets your
requirements, but has completely missed your
needs.
Interviews
Interviews
• Fact-finding technique whereby the systems analysts collect
information from individuals through face-to-face interaction
Unstructured Interviews
• 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 Interviews
• The interviewer has a specific set of questions to ask of the
interviewee.
Types of Interview Questions
Open-Ended Questions
• Allow the interviewee to respond in any way that
seems appropriate.
Closed-Ended Questions
• Restrict answers to either specific choices or short,
direct responses.
How to Conduct an Interview
1. Select interviewees. Learn as much as you can about
interviewee.
2. Make an appointment – never ‘drop by’
3. Limit the interview to between ½ hour and 1 hour
4. Clear it with the interviewee’s supervisor
5. Conduct the interview in a private location
6. Prepare for the interview: provide an interview
agenda
7. Conduct the interview: opening, body, conclusion
8. Follow-up
Interview Questions
• 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.
Sample Interview Guide
Sample Interview Guide (concluded)
Interviewing Do’s and Don’ts
Do
•
•
•
•
•
Be courteous
Listen carefully
Maintain control
Probe
Observe mannerisms and
nonverbal communication
• Be patient
• Keep interviewee at ease
• Maintain self-control
Avoid
• Continuing an interview
unnecessarily.
• Assuming an answer is finished or
leading nowhere.
• Revealing verbal and nonverbal
clues.
• Using jargon
• Revealing your personal biases.
• Talking instead of listening.
• Assuming anything about the topic
and the interviewee.
• Tape recording -- a sign of poor
listening skills.
Communicating With the User
• Listening - “To hear is to recognize that someone is
speaking, to listen is to understand what the speaker
wants to communicate.” (Gildersleeve – 1978)
• Guidelines for Communicating
–
–
–
–
–
–
Approach the Session with a Positive Attitude
Set the Other Person at Ease
Let Them Know You Are Listening
Ask Questions
Don’t Assume Anything
Take Notes
Body Language and Proxemics
Body Language
• All of the nonverbal information being communicated
by an individual
• A form of nonverbal communications that we all use
and are usually unaware of
Proxemics
• The relationship between people and the space around
them
• A factor in communications that can be controlled by
the knowledgeable analyst
Spatial Zones
•
•
•
•
Intimate zone—closer than 1.5 feet
Personal zone—from 1.5 feet to 4 feet
Social zone—from 4 feet to 12 feet
Public zone—beyond 12 feet
Interviews – the Good and the Bad
Advantages
–
–
–
–
Users are actively involved
SA can probe for more feedback from user
SA can reword questions for each interviewee
Body cues
Disadvantages
– Very time consuming, thus very costly
– Success of the interview is dependent on the SA’s human
relations skills
– Interviewing may be impractical due to location of
interviewees
Overall Strategy for Fact Finding
1.
2.
3.
4.
Learn all you can from existing documentation
If appropriate, observe the system in action
Conduct interviews
Use questionnaires to clear up things you don’t fully
understand
5. Follow-up
Some Questions that Must be Answered
• What are the inputs to this system?
• What are the outputs of this system?
• What is the business process (i.e., how is data
processed)?
• Who are the direct end-users?
• How will the users feel about this system?
• Who developed the existing system?
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
Milestone 2
Milestone 2
Statement of User Environment
• A narrative explanation of all the facts gathered from
interviews, questionnaires, documentation, and so
forth as they pertain to the current system (i.e. how the
business processes currently occur)
• Inputs/Processes/Outputs
– From the stmt of user environment, identify all processes
and their related inputs and outputs
– Note: This is not the stmt of user requirements for the new
system. This is simply a listing of how the current
processing occurs; this must be understood before the new
system requirements can be identified.
Problems / Opportunities: Causes and Effects
• Study and analyze the “current” system
• Problem analysis is difficult
– We often try to solve problems without analyzing them
– We try to state the problem in terms of a solution
• Identify the problem/opportunity/directive
– Note: When complete, the problems should be ranked in
order of importance.
• Cause: what is the source of the problem?
• Effect: what is the implication to the organization?
The PIECES Problem-Solving Framework and Checklist
• Use the PIECES framework to frame your
investigation of the problems, opportunities, and
requirements
–
–
–
–
–
–
Performance analysis
Information and data analysis
Economic analysis
Control and security analysis
Efficiency analysis
Service analysis
• The checklist on the following slide, uses Wetherbe’s
PIECES framework. The categories of the PIECES
framework are equally suited for analyzing both
manual and computerized systems and applications.
The PIECES Problem-Solving Framework and Checklist
PERFORMANCE Problems, Opportunities, and Directives
A.
B.
Throughput – the amount of work performed over some period of time.
Response time – the average delay between a transaction request and a response
CONTROL (and Security) Problems, Opportunities, and Directives
A.
INFORMATION (and Data) Problems, Opportunities, and Directives
A.
B.
C.
Outputs
1.
Lack of any information
2.
Lack of necessary information
3.
Lack of relevant information
4.
Too much information – “information overload”
5.
Information that is not in a useful format
6.
Information that is not accurate
7.
Information that is difficult to produce
8.
Information is not timely to its subsequent use
Inputs
1.
Data is not captured
2.
Data is not captured in time to be useful
3.
Data is not accurately captured – contains errors
4.
Data is difficult to capture
5.
Data is captured redundantly – same data captured more than once
6.
Too much data is captured
7.
Illegal data is captured
Stored data
1.
Data is stored redundantly in multiple files and/or databases
2.
Stored data is not accurate (may be related to #1)
3.
Data is not secure to accident or vandalism
4.
Data is not well organized
5.
Data is not flexible – not easy to meet new information needs from stored
data
6.
Data is not accessible
ECONOMICS Problems, Opportunities, and Directives
•
•
•
Costs are unknown
Costs are untraceable to source
Costs are too high
B.
Too little security or control
1.
Input data is not adequately edited
2.
Crimes are (or can be) committed against data
a.
Fraud
b.
Embezzlement
3.
Ethics are breached on data or information – refers to data or information
getting to unauthorized people
4.
Redundantly stored data is inconsistent in different files or databases
5.
Data privacy regulations or guidelines are being (or can be) violated
6.
Processing errors are occurring (either by people, machines, or software)
7.
Decision-making errors are occurring
Too much control or security
1.
Bureaucratic red tape slows the system
2.
Controls inconvenience customers or employees
3.
Excessive controls cause processing delays
EFFICIENCY Problems, Opportunities, and Directives
A.
B.
C.
D.
People, machines, or computers waste time
1.
Data is redundantly input or copied
2.
Data is redundantly processed
3.
Information is redundantly generated
People, machines, or computers waste materials and supplies
Effort required for tasks is excessive
Materials required for tasks is excessive
SERVICE Problems, Opportunities, and Directives
A.
B.
C.
D.
E.
F.
G.
H.
I.
J.
The system produces inaccurate results
The system produces inconsistent results
The system produces unreliable results
The system is not easy to learn
The system is not easy to use
The system is awkward to use
The system is inflexible to new or exceptional situations
The system is inflexible to change
The system is incompatible with other systems
The system is not coordinated with other systems
Example: Problem/Opportunity, Cause, and Effect
Problem/Opportunity
Cause
Effect
1.
Response time to bid
on sporting events is
excessive. We lose a
lot of possible
contracts.
Retrieval of bidding
information takes too
long. Approval for bids
takes too long.
Potential loss: $250,000
annually
2.
Difficult to calculate
estimated costs for a
bid. If bid is
underestimated, the
customer cannot be
charged for
excessive costs.
Historical data is hard to Approximately $50,000
gather and organize. Lag per year in undercharged
time of receiving current costs.
costs for our resources.
3.
Etc.
System Objectives
• Objective: a measure of success
• Should be precise, measurable statements of business
performance
• Be careful not to state requirements as objectives
• Experience is the best teacher
Critical Assumptions
• Identify any assumptions made about the system
• Identify any assumptions about the continuance of the
project
• And so forth…
Statement of User/System Requirements
• Use information gathered and studied
• Requirements
– Those things that a system must do to meet the objectives
and solve the problems / exploit the opportunities
• Prioritize the requirements
• Identify 5 parts:
– Outputs, Inputs, Processes, System Performance, and Out of
Scope
Defining Requirements Example
A good requirement is unambiguous, testable, consistent, and understandable.
Requirements are usually grouped into one (or more) of the following categories:
outputs, inputs, processes, and performance. Examples of each are provided below.
Outputs
• The system must be able to prepare an emergency Reorder ready to send to a
supplier within one hour of the time the need is identified.
• The reorder stock process must generate reorder forms ready to be sent to the
supplier.
Inputs
• The system must allow new customers to be entered by sales clerks.
• The manager, and only the manager, should have the ability to indicate a customer’s
credit standing.
• The system must be able to scan bar codes as a means of determining product price.
Defining Requirements Example Cont.
Processes
• The system must track reorders that have been issued but have not yet arrived.
• The store manager must approve all reorders before they are sent to the supplier.
• A product is considered for reorder when the Stock on hand falls below the reorder
point.
System Performance
• The Stock on hand must be accurate to within 1% for at least 99% of the products in
inventory.
• Inventory data must be maintained for at least 1000 different products with an
average Stock on hand of at least 50 units per product.
• The system must allow for a 50% growth in inventory over the next five years.
• The system must be able to generate at least 50 reorders per week.
• The system must hold data for at least 1000 unique inventory items.
• The system must be user friendly.
Outside the Scope?
• Aspects of the system which are “outside” the
scope of the project
Recommendation
• Make a recommendation to:
–
–
–
–
Continue
Modify
Cancel
Postpone
• Justify your response with:
–
–
–
–
TELOS/PDM?
Cost estimate?
Schedule estimate?
And so forth…
Supporting Documentation
• All forms of communication must be documented,
including:
–
–
–
–
Copies of all questionnaires
Copies of all interview agendas
Copies of all existing documents gathered
Copies of all communication with the user (including
emails)
– Summaries of all meetings with users
• These documents should be provided in an Appendix
to Milestone 2.
Output of Phase 2A (Milestone 2)
1.
2.
3.
4.
5.
6.
7.
Complete statement of user environment
List of major problems/causes/effects
System objectives
List of critical assumptions
Statement of user requirements
Recommendation
Supporting documentation