Chapter 5:
Determining Object-Oriented
Systems Requirements
Object-Oriented Systems Analysis and
Design
Joey F. George, Dinesh Batra,
Joseph S. Valacich, Jeffrey A. Hoffer
© Prentice Hall, 2007
5-1
Chapter Objectives
– Describe options for and develop plans for designing and
–
–
–
–
–
conducting interviews to determine systems requirements
Explain advantages and pitfalls of observing workers and
analyzing business documents to determine systems
requirements
Participate in and help plan Joint Application Design
(JAD) sessions
Use prototyping during requirements determination
Describe agile approaches to requirements determination
Select the appropriate methods to elicit system
requirements
Chapter 5
© Prentice Hall, 2007
5-2
Chapter 5
© Prentice Hall, 2007
5-3
Characteristics for Successful
Requirements Determination

Impertinence
 Impartiality
 Relaxing of constraints
 Attention to details
 Reframing
Chapter 5
© Prentice Hall, 2007
5-4
Chapter 5
© Prentice Hall, 2007
5-5
How to Determine Requirements
Chapter 5
© Prentice Hall, 2007
5-6
What Is Interviewing?

Dialogue with user or manager to obtain
their requirements
 Two forms:
– Open-ended – conversational, questions with
no specific answers in mind
– Closed-ended – structured, questions with
limited range of possible answers
Chapter 5
© Prentice Hall, 2007
5-7
How to Conduct Interviews
Chapter 5
© Prentice Hall, 2007
5-8
Interview Guide
is a document for
developing,
planning, and
conducting an
interview.
Chapter 5
© Prentice Hall, 2007
5-9
Each question in
an interview
guide can include
both verbal and
non-verbal
information.
Chapter 5
© Prentice Hall, 2007
5-10
What is Direct Observation?

Watching users do their jobs

Purpose – obtain firsthand, objective measures of
employees’ interactions with the information system

Can provide more accurate information than self-reporting
in interviews

Pitfalls – observed employees may change their behavior;
time limitations make observation more difficult
Chapter 5
© Prentice Hall, 2007
5-11
What is Document Analysis?

Review of existing business documents

Can give a historical and “formal” view of system
requirements

Relevant documents – mission statements,
business plans, organizational charts, policy
manuals, job descriptions, correspondences,
reports from organizational studies
Chapter 5
© Prentice Hall, 2007
5-12
Formal vs. Informal Systems

Formal system – the official way a system
works as described in organizational
documentation

Informal system – the way the system
actually works
Chapter 5
© Prentice Hall, 2007
5-13
Written work
procedure is a
business document
that formally
describes work
processes. Provides
useful information
regarding system
functionality and
logic.
Chapter 5
© Prentice Hall, 2007
5-14
Business form is a
document that
contains useful
information
regarding data
organizations and
possible screen
layouts.
Chapter 5
© Prentice Hall, 2007
5-15
Observations vs. Document
Analysis
Chapter 5
© Prentice Hall, 2007
5-16
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
Chapter 5
© Prentice Hall, 2007
5-17
JAD Team Members

Session leader
 Users
 Managers
 Sponsor
 Systems analysts
 Scribe
 IS staff
Chapter 5
coordinator
information source
information source
champion
listeners
recorder
listeners
© Prentice Hall, 2007
5-18
Chapter 5
© Prentice Hall, 2007
5-19
What Is Prototyping?

A repetitive process in which analysts and
users build a rudimentary version of an
information system based on user feedback

Repeated cycle: build, use, evaluate
Chapter 5
© Prentice Hall, 2007
5-20
Chapter 5
© Prentice Hall, 2007
5-21
When to Use Prototyping

Prototyping is good when:
– Users are unclear about their requirements.
– The system affects a relatively small number of
users.
– Designs are complex.
– Communication between users and analysts
needs to be strengthened.
– Rapid application development tools are
available.
Chapter 5
© Prentice Hall, 2007
5-22
Pitfalls of Prototyping

Prototyping has the following drawbacks:
– Tendency to avoid creating formal systems requirement
documentation
– Prototypes may be indiosynchratic to the individual
user and difficult to adapt for others
– Prototypes are designed as standalone systems, so do
not address data sharing and integration
– Checks in SDC are bypassed, so issues like security,
controls and standardization may be ignored
Chapter 5
© Prentice Hall, 2007
5-23
What are Agile Methodologies?

Techniques for eliciting user requirements
that encourage continuous user involvement
and adapt to incremental changes in system
design over time

Two approaches:
– Agile user-centered design (similar to JAD)
– eXtreme programming
Chapter 5
© Prentice Hall, 2007
5-24
Steps in
Agile User-Centered Design
1.
2.
3.
4.
5.
6.
7.
8.
Gather stakeholders together in sequestered environment
Give everyone a chance to vent complaints and record
them
Determine and list most appropriate user roles
Determine tasks for each user role
Group tasks by similarity, into “interaction context”
Write a description for each task in an interaction context
Treat each interaction context as a single user interface
screen, and sketch the user interface
List all the steps of the user interface, and make sure these
can be accomplished in the prototype
Chapter 5
© Prentice Hall, 2007
5-25
eXtreme Programming

Typically involve 2-person programming teams
 Fusion of planning, analysis, design, and
implementation
 Characterized by:
– Short development cycles
– Incremental planning
– Focus on automated tests for monitoring development
process
– Reliance on evolutionary development
Chapter 5
© Prentice Hall, 2007
5-26
eXtreme Programming
Planning Game


Players – business and development
Three phases:
– exploration
– commitment
– Steering

Three stacks of story cards
– Essential features
– Value-added features
– Noce-to-have features

Story cards are replaced by task cards during
Iteration Planning Game
Chapter 5
© Prentice Hall, 2007
5-27
Chapter 5
© Prentice Hall, 2007
5-28