Modern Systems Analysis

and Design

Chapter 6
Determining System Requirements
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.

Chapter 6 Copyright © 2011 Pearson Education, Inc. Publishing as Prentice Hall 2

Learning Objectives (Cont.)
 Explain how computing can provide support for
requirements determination.
 Participate in and help plan a Joint Application
Design session.
 Use prototyping during requirements
determination.
 Describe contemporary approaches to
requirements determination.
 Understand how requirements determination
techniques apply to the development of
electronic commerce applications.

Chapter 6 Copyright © 2011 Pearson Education, Inc. Publishing as Prentice Hall 3

Performing Requirements Determination

FIGURE 6-1
Systems development life cycle with
analysis phase highlighted

Chapter 6 Copyright © 2011 Pearson Education, Inc. Publishing as Prentice Hall 4

The Process of Determining
Requirements
 Good Systems Analyst Characteristics:
 Impertinence—question everything
 Impartiality—consider all issues to find the best
organizational solution
 Relaxing constraints—assume anything is possible
 Attention to details—every fact must fit
 Reframing—challenge yourself to new ways

Chapter 6 Copyright © 2011 Pearson Education, Inc. Publishing as Prentice Hall 5

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

Chapter 6 Copyright © 2011 Pearson Education, Inc. Publishing as Prentice Hall 6

Deliverables and Outcomes (Cont.)
 From computerized sources — Joint
Application Design session results, CASE
repositories, reports from existing systems,
displays and reports from system prototype

Chapter 6 Copyright © 2011 Pearson Education, Inc. Publishing as Prentice Hall 7

Methods for Determining System
Requirements
 Traditional
Methods
 Contemporary Methods
 Radical Methods
 Agile Methodologies

Chapter 6 Copyright © 2011 Pearson Education, Inc. Publishing as Prentice Hall 8

1- Traditional Methods for
Determining Requirements
 Interviewing
individuals
groups
 Observing workers
 Studying business documents

Chapter 6 Copyright © 2011 Pearson Education, Inc. Publishing as Prentice Hall 9

1.1- Interviewing and Listening
 One of the primary ways analysts gather
information about an information systems
project
 Interview Guide is a document for
developing, planning and conducting an
interview.

Chapter 6 Copyright © 2011 Pearson Education, Inc. Publishing as Prentice Hall 10

Interviewing and Listening (Cont.)

FIGURE 6-2 Typical interview guide

https://www.youtube.com/watch?v=AMb_4Cdi7zg&ab_channel=PramodHanumappa

Chapter 6 Copyright © 2011 Pearson Education, Inc. Publishing as Prentice Hall 11

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.

Chapter 6 Copyright © 2011 Pearson Education, Inc. Publishing as Prentice Hall 12

Choosing Interview Questions
 Each question in an interview guide can
include both verbal and non-verbal
information.
 Open-ended questions: questions that have
no pre-specified answers
 Closed-ended questions: questions that ask
those responding to choose from among a set
of specified responses

Chapter 6 Copyright © 2011 Pearson Education, Inc. Publishing as Prentice Hall 13

1.2- 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

Chapter 6 Copyright © 2011 Pearson Education, Inc. Publishing as Prentice Hall 14

Interviewing Groups (Cont.)
 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

Chapter 6

Copyright © 2011 Pearson Education, Inc. Publishing as Prentice Hall 15

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.

Chapter 6 Copyright © 2011 Pearson Education, Inc. Publishing as Prentice Hall 16

Nominal Group Technique (NGT)
 Group openly discusses the ideas for
clarification.
 Ideas are prioritized, combined, selected,
reduced.
 NGT exercise used to complement group
meetings or as part of JAD effort.

Chapter 6 Copyright © 2011 Pearson Education, Inc. Publishing as Prentice Hall 17

1.3- Directly Observing Users
 Direct Observation
 Watching users do their jobs
 Obtaining objective measures of employee
interaction with information systems
 Can cause people to change their normal
operating behavior
 Time-consuming and limited time to observe

Chapter 6 Copyright © 2011 Pearson Education, Inc. Publishing as Prentice Hall 18

1.4- Analyzing Procedures and
Other Documents
 Document Analysis
 Review of existing business documents
 Can give a historical and “formal” view of
system requirements
 Types of Documents
 Writtenwork procedure
 Business form
 Report
 Description of current information system

Chapter 6 Copyright © 2011 Pearson Education, Inc. Publishing as Prentice Hall 19

Analyzing Procedures and
Other Documents (Cont.)
 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

Chapter 6 Copyright © 2011 Pearson Education, Inc. Publishing as Prentice Hall 20

Analyzing Procedures and
Other Documents (Cont.)
 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.

Chapter 6 Copyright © 2011 Pearson Education, Inc. Publishing as Prentice Hall 21

Analyzing Procedures and Other
Documents (Cont.)
 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.

Chapter 6 Copyright © 2011 Pearson Education, Inc. Publishing as Prentice Hall 22

Analyzing Procedures and
Other Documents (Cont.)
 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)

Chapter 6 Copyright © 2011 Pearson Education, Inc. Publishing as Prentice Hall 23

Analyzing Procedures and
Other Documents (Cont.)
 Useful document: Business form
 Used for all types of business functions
 Explicitly indicate 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

Chapter 6 Copyright © 2011 Pearson Education, Inc. Publishing as Prentice Hall 24

Analyzing
Procedures and
Other Documents
(Cont.)
FIGURE 6-4
An example of a business form—
An invoice form for QuickBooks,
from jnk.btobsource.com. Reprinted
by permission.
Source: http://jnk.btobsource.com/
NASApp/enduser/products/product_
detail.jsp?pc513050M#

Chapter 6 Copyright © 2011 Pearson Education, Inc. Publishing as Prentice Hall 25

Analyzing Procedures and
Other Documents (Cont.)
 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

Chapter 6 Copyright © 2011 Pearson Education, Inc. Publishing as Prentice Hall 26

Analyzing Procedures and
Other Documents (Cont.)

Chapter 6 Copyright © 2011 Pearson Education, Inc. Publishing as Prentice Hall 27

2- 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

Chapter 6 Copyright © 2011 Pearson Education, Inc. Publishing as Prentice Hall 28

 Contemporary Methods for Determining
System Requirements (Cont.)
 CASE tools
 Used to analyze existing systems
 Help discover requirements to meet changing
business conditions
 System prototypes
 Iterative
development process
 primary working version of system
 Refine understanding of system requirements in
concrete terms

Chapter 6 Copyright © 2011 Pearson Education, Inc. Publishing as Prentice Hall 29

2.1- 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 6 Copyright © 2011 Pearson Education, Inc. Publishing as Prentice Hall 30

 JAD (Cont.)

FIGURE 6-6 Illustration of the typical room layout for a JAD

Source: Based on Wood and Silver, 1995
Chapter 6 Copyright © 2011 Pearson Education, Inc. Publishing as Prentice Hall 31
JAD (Cont.)
 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

Chapter 6 Copyright © 2011 Pearson Education, Inc. Publishing as Prentice Hall 32

JAD (Cont.)
 End Result
 Documentation detailing existing system
 Features of proposed system

Chapter 6 Copyright © 2011 Pearson Education, Inc. Publishing as Prentice Hall 33

2.2- CASE Tools During JAD

 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

Chapter 6 Copyright © 2011 Pearson Education, Inc. Publishing as Prentice Hall 34

2.3- 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

Chapter 6 Copyright © 2011 Pearson Education, Inc. Publishing as Prentice Hall 35

Using Prototyping During
Requirements Determination (Cont.)
 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.

Chapter 6 Copyright © 2011 Pearson Education, Inc. Publishing as Prentice Hall 36

Using Prototyping During
Requirements Determination (Cont.)
 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

Chapter 6 Copyright © 2011 Pearson Education, Inc. Publishing as Prentice Hall 37

3- 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

Chapter 6 Copyright © 2011 Pearson Education, Inc. Publishing as Prentice Hall 38

Radical Methods for Determining
System Requirements (Cont.)
 Goals
 Reorganize complete flow of data in major
sections of an organization.
 Eliminate unnecessary steps.
 Combine steps.
 Become more responsive to future change.

Chapter 6 Copyright © 2011 Pearson Education, Inc. Publishing as Prentice Hall 39

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 are used as for requirements

determination

Chapter 6 Copyright © 2011 Pearson Education, Inc. Publishing as Prentice Hall 40

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.

Chapter 6 Copyright © 2011 Pearson Education, Inc. Publishing as Prentice Hall 41

Disruptive Technologies (Cont.)

Chapter 6 Copyright © 2011 Pearson Education, Inc. Publishing as Prentice Hall 42

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

Chapter 6 Copyright © 2011 Pearson Education, Inc. Publishing as Prentice Hall 43

Continual User Involvement

FIGURE 6-11
The iterative analysis–design–code–test
cycle

Chapter 6 Copyright © 2011 Pearson Education, Inc. Publishing as Prentice Hall 44

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.

Chapter 6 Copyright © 2011 Pearson Education, Inc. Publishing as Prentice Hall 45

 The Planning Game from
eXtreme Programming

FIGURE 6-12
eXtreme Programming’s Planning Game

Chapter 6 Copyright © 2011 Pearson Education, Inc. Publishing as Prentice Hall 46

 Thanks

Chapter 6 Copyright © 2011 Pearson Education, Inc. Publishing as Prentice Hall 47