Modern Systems Analysis
and Design
Seventh Edition
Jeffrey A. Hoffer
Joey F. George
Joseph S. Valacich
Chapter 6
Determining System Requirements
Systems Analysis
& Design
V. Implementation
I. Foundations II. Planning III. Analysis IV. Design
& Maintenance
4. Identify & Select 6. Determine 13. System
1. SD Environment 9. Design DB
SD Projects Systems Req’s Implementation
7. Structure
2. Origins of 5. Initiate & Plan 10. Design Forms
Systems Process 14. Maintaining IS
Software SD Projects & Reports
Req’s
8. Structure 11. Design
3. Manage IS
Systems Data Interfaces &
Project
Req’s Dialogues
12. Design Dist &
Internet Systems
Learning Objectives
• Describe options for designing and conducting
interviews and develop a plan for conducting an
interview to determine system requirements.
• Explain the advantages and pitfalls of observing
workers and analyzing business documents to
determine system requirements.
• Explain how computing can provide support for
requirements determination.
• Participate in and help plan a Joint Application Design
session.
Copyright © 2014 Pearson Education, Inc. Publishing
3
as Prentice Hall
Learning Objectives
• Use prototyping during requirements determination.
• Describe contemporary approaches to requirements
determination.
• Understand how requirements determination
techniques apply to the development of electronic
commerce applications.
Copyright © 2014 Pearson Education, Inc. Publishing
4
as Prentice Hall
Performing Requirements Determination
FIGURE 6-1
Systems development life cycle with
analysis phase highlighted
Copyright © 2014 Pearson Education, Inc. Publishing
5
as Prentice Hall
Process of Determining Requirements
• Good Systems Analyst Characteristics:
– Impertinence — question everything
– Impartiality — consider all issues to find the best
organizational solution
– Relax constraints — assume anything is possible
– Attention to details — every fact must fit
– Reframing — challenge yourself to new ways
Copyright © 2014 Pearson Education, Inc. Publishing
6
as Prentice Hall
Deliverables and Outcomes
• Deliverables for Requirements Determination:
– From interviews and observations
• interview transcripts, observation notes, meeting minutes
– From existing written documents
• mission and strategy statements, business forms, procedure
manuals, job descriptions, training manuals, system
documentation, flowcharts
– From computerized sources
• Joint Application Design session results, CASE repositories, reports
from existing systems, displays and reports from system prototype
Copyright © 2014 Pearson Education, Inc. Publishing
7
as Prentice Hall
Traditional Methods for Determining Requirements
• Interviewing individuals
• Interviewing groups
• Observing workers
• Studying business documents
Copyright © 2014 Pearson Education, Inc. Publishing
8
as Prentice Hall
Interviewing and Listening
• One of the primary ways analysts gather information
about an information systems project
• An interview guide is a document for developing,
planning and conducting an interview.
Copyright © 2014 Pearson Education, Inc. Publishing
9
as Prentice Hall
Guidelines for Effective Interviewing
• Plan the interview.
– Prepare interviewee: appointment, priming questions.
– Prepare agenda, checklist, questions.
• Listen carefully and take notes (tape record if
permitted).
• Review notes within 48 hours.
• Be neutral.
• Seek diverse views.
Copyright © 2014 Pearson Education, Inc. Publishing
10
as Prentice Hall
Interviewing and Listening
FIGURE 6-2 Typical interview guide
Copyright © 2014 Pearson Education, Inc. Publishing
11
as Prentice Hall
Interviewing and Listening
FIGURE 6-2 Typical interview guide
Copyright © 2014 Pearson Education, Inc. Publishing
12
as Prentice Hall
Choosing Interview Questions
• Each question in an interview guide can include both
verbal and non-verbal information.
– Open-ended questions: questions that have no
prespecified answers
– Closed-ended questions: questions that ask those
responding to choose from among a set of specified
responses
Copyright © 2014 Pearson Education, Inc. Publishing
13
as Prentice Hall
Interviewing Guidelines
• Don’t phrase a question in a way that implies a right
or wrong answer.
• Listen very carefully.
• Type interview notes within 48 hours after the
interview.
• Don’t set expectations about the new system unless
you know these will be deliverables.
• Seek a variety of perspectives from the interviews.
Copyright © 2014 Pearson Education, Inc. Publishing
14
as Prentice Hall
Interviewing Groups
• Drawbacks to individual interviews:
– Contradictions and inconsistencies between interviewees
– Follow-up discussions are time consuming
– New interviews may reveal new questions that require
additional interviews with those interviewed earlier
Copyright © 2014 Pearson Education, Inc. Publishing
15
as Prentice Hall
Interviewing Groups
• Interviewing several key people together
– Advantages
• More effective use of time
• Can hear agreements and disagreements at once
• Opportunity for synergies
– Disadvantages
• More difficult to schedule than individual interviews
Copyright © 2014 Pearson Education, Inc. Publishing
16
as Prentice Hall
Nominal Group Technique (NGT)
• A facilitated process that supports idea generation by
groups
• Process
– Members come together as a group, but initially work
separately.
– Each person writes ideas.
– Facilitator reads ideas out loud, and they are written on a
blackboard or flipchart.
– Group openly discusses the ideas for clarification.
– Ideas are prioritized, combined, selected, reduced.
• Used to complement group meetings or as part of JAD
effort
Copyright © 2014 Pearson Education, Inc. Publishing
17
as Prentice Hall
Directly Observing Users
• Direct Observation
– Watching users do their jobs
– Used to obtain more firsthand and objective measures of
employee interaction with information systems
– Can cause people to change their normal operating
behavior
– Time-consuming and limited time to observe
Copyright © 2014 Pearson Education, Inc. Publishing
18
as Prentice Hall
Analyzing Procedures and Other Documents
• Document Analysis
– Review of existing business documents
– Can give a historical and “formal” view of system
requirements
Copyright © 2014 Pearson Education, Inc. Publishing
19
as Prentice Hall
Analyzing Procedures and Other Documents
• 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
Copyright © 2014 Pearson Education, Inc. Publishing
20
as Prentice Hall
Analyzing Procedures and Other Documents
• Useful document: Written work procedure
– For an individual or work group
– Describes how a particular job or task is performed
– Includes data and information used and created in the
process
Copyright © 2014 Pearson Education, Inc. Publishing
21
as Prentice Hall
Analyzing Procedures
FIGURE 6-3 Example of a procedure
Copyright © 2014 Pearson Education, Inc. Publishing
22
as Prentice Hall
Analyzing Procedures
FIGURE 6-3 Example of a procedure
Copyright © 2014 Pearson Education, Inc. Publishing
23
as Prentice Hall
Analyzing Procedures and Other Documents
• Potential Problems with Procedure Documents:
– May involve duplication of effort
– May have missing procedures
– May be out of date
– May contradict information obtained through interviews
Copyright © 2014 Pearson Education, Inc. Publishing
24
as Prentice Hall
Analyzing Procedures and Other Documents
• Formal Systems: the official way a system works as
described in organizational documentation (i.e. work
procedure)
• Informal Systems: the way a system actually works
(i.e. interviews, observations)
Copyright © 2014 Pearson Education, Inc. Publishing
25
as Prentice Hall
Analyzing Procedures and Other Documents
• Useful document: Business form
– Used for all types of business functions
– Explicitly indicates what data flow in and out of a system
and data necessary for the system to function
– Gives crucial information about the nature of the
organization
Copyright © 2014 Pearson Education, Inc. Publishing
26
as Prentice Hall
Analyzing Procedures
and Other Documents
FIGURE 6-4
An invoice form from Microsoft Excel
Copyright © 2014 Pearson Education, Inc. Publishing
27
as Prentice Hall
Analyzing Procedures and Other Documents
• Useful document: Report
– Primary output of current system
– Enables you to work backwards from the report to the
data needed to generate it
• Useful document: Description of current information
system
Copyright © 2014 Pearson Education, Inc. Publishing
28
as Prentice Hall
Analyzing Procedures and Other Documents
Copyright © 2014 Pearson Education, Inc. Publishing
29
as Prentice Hall
Contemporary Methods for Determining System
Requirements
• Joint Application Design (JAD)
– Brings together key users, managers, and systems analysts
– Purpose: collect system requirements simultaneously from
key people
– Conducted off-site
• Group Support Systems
– Facilitate sharing of ideas and voicing of opinions about
system requirements
Copyright © 2014 Pearson Education, Inc. Publishing
30
as Prentice Hall
Contemporary Methods for Determining System
Requirements
• CASE tools
– Used to analyze existing systems
– Help discover requirements to meet changing business
conditions
• System prototypes
– Iterative development process
– Rudimentary working version of system is built
– Refine understanding of system requirements in concrete
terms
Copyright © 2014 Pearson Education, Inc. Publishing
31
as Prentice Hall
Joint Application Design (JAD)
• Intensive group-oriented requirements
determination technique
• Team members meet in isolation for an extended
period of time
• Highly focused
• Resource intensive
• Started by IBM in 1970s
Copyright © 2014 Pearson Education, Inc. Publishing
32
as Prentice Hall
JAD
FIGURE 6-6 Illustration of the typical room layout for a JAD
Source: Based on Wood and Silver, 1995.
Copyright © 2014 Pearson Education, Inc. Publishing
33
as Prentice Hall
JAD
• JAD Participants:
– Session Leader: facilitates group process
– Users: active, speaking participants
– Managers: active, speaking participants
– Sponsor: high-level champion, limited participation
– Systems Analysts: should mostly listen
– Scribe: record session activities
– IS Staff: should mostly listen
Copyright © 2014 Pearson Education, Inc. Publishing
34
as Prentice Hall
JAD
• End Result
– Documentation detailing existing system
– Features of proposed system
Copyright © 2014 Pearson Education, Inc. Publishing
35
as Prentice Hall
CASE Tools During JAD
• Upper CASE tools are used
• Enables analysts to enter system models directly into
CASE during the JAD session
• Screen designs and prototyping can be done during
JAD and shown to users
Copyright © 2014 Pearson Education, Inc. Publishing
36
as Prentice Hall
Using Prototyping During Requirements Determination
• Quickly converts requirements to working version of
system
• Once the user sees requirements converted to
system, will ask for modifications or will generate
additional requests
Copyright © 2014 Pearson Education, Inc. Publishing
37
as Prentice Hall
Using Prototyping During Requirements Determination
Figure 6-7
The prototyping
methodology
(Source: Based on
“Prototyping: The New
Paradigm for Systems
Development,” by
J. D. Naumann and A.
M. Jenkins, MIS
Quarterly 6(3): 29–44.)
Copyright © 2014 Pearson Education, Inc. Publishing
38
as Prentice Hall
Using Prototyping During Requirements Determination
• Most useful when:
– User requests are not clear.
– Few users are involved in the system.
– Designs are complex and require concrete form.
– There is a history of communication problems between
analysts and users.
– Tools are readily available to build prototype.
Copyright © 2014 Pearson Education, Inc. Publishing
39
as Prentice Hall
Using Prototyping During Requirements Determination
• Drawbacks
– Tendency to avoid formal documentation
– Difficult to adapt to more general user audience
– Sharing data with other systems is often not considered
– Systems Development Life Cycle (SDLC) checks are often
bypassed
Copyright © 2014 Pearson Education, Inc. Publishing
40
as Prentice Hall
Radical Methods for Determining System Requirements
• Business Process Reengineering (BPR): search for
and implementation of radical change in business
processes to achieve breakthrough improvements in
products and services
Copyright © 2014 Pearson Education, Inc. Publishing
41
as Prentice Hall
Radical Methods for Determining System Requirements
• Goals
– Reorganize complete flow of data in major sections of an
organization.
– Eliminate unnecessary steps.
– Combine steps.
– Become more responsive to future change.
Copyright © 2014 Pearson Education, Inc. Publishing
42
as Prentice Hall
Identifying Processes to Reengineer
• Key business processes
– Structured, measured set of activities designed to produce
specific output for a particular customer or market
– Focused on customers and outcome
– Same techniques as requirements determination are used
Copyright © 2014 Pearson Education, Inc. Publishing
43
as Prentice Hall
Disruptive Technologies
• Information technologies must be applied to radically
improve business processes.
• Disruptive technologies are technologies that enable
the breaking of long-held business rules that inhibit
organizations from making radical business changes.
Copyright © 2014 Pearson Education, Inc. Publishing
44
as Prentice Hall
Disruptive Technologies
Copyright © 2014 Pearson Education, Inc. Publishing
45
as Prentice Hall
Requirements Determination using Agile Methodologies
• Continual user involvement
– Replace traditional SDLC waterfall with iterative analyze–
design–code–test cycle
• Agile usage-centered design
– Focuses on user goals, roles, and tasks
• The Planning Game
– Based on eXtreme programming
– Exploration, steering, commitment
Copyright © 2014 Pearson Education, Inc. Publishing
46
as Prentice Hall
Continual User Involvement
FIGURE 6-9
The iterative analysis–design–code–test
cycle
Copyright © 2014 Pearson Education, Inc. Publishing
47
as Prentice Hall
Agile Usage-Centered Design Steps
• Gather group of programmers, analysts, users, testers,
facilitator.
• Document complaints of current system.
• Determine important user roles.
• Determine, prioritize, and describe tasks for each user
role.
• Group similar tasks into interaction contexts.
• Associate each interaction context with a user interface
for the system, and prototype the interaction context.
• Step through and modify the prototype.
Copyright © 2014 Pearson Education, Inc. Publishing
48
as Prentice Hall
Planning Game from eXtreme Programming
FIGURE 6-10
eXtreme Programming’s Planning Game
Copyright © 2014 Pearson Education, Inc. Publishing
49
as Prentice Hall
Electronic Commerce Applications: Determining System
Requirements
• Determining system requirements for Pine Valley
furniture’s WebStore
– System layout and navigation characteristics
– WebStore and site management system capabilities
– Customer and inventory information
– System prototype evolution
Copyright © 2014 Pearson Education, Inc. Publishing
50
as Prentice Hall
Summary
• In this chapter you learned how to:
– Describe interviewing options and develop interview plan.
– Explain advantages and pitfalls of worker observation and
document analysis.
– Explain how computing can support requirements
determination.
– Participate in and help plan Joint Application Design sessions.
– Use prototyping during requirements determination.
– Describe contemporary approaches to requirements
determination.
– Understand how requirements determination techniques apply
to the development of electronic commerce applications.
Copyright © 2014 Pearson Education, Inc. Publishing
51
as Prentice Hall
Copyright © 2014 Pearson Education, Inc.
Publishing as Prentice Hall