Determining System

Requirements

© 2005 by Prentice Hall

 System Requirements Determination

6-2 © 2005 by Prentice Hall

 Deliverables of 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
 JAD session results, CASE repositories, system
prototype displays and reports

6-3 © 2005 by Prentice Hall

 Traditional Requirements
Determination Methods

Interviewing individuals
Interviewing groups
Observing workers
Studying business documents

6-4 © 2005 by Prentice Hall

 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

6-5 © 2005 by Prentice Hall

 Guidelines for Effective
Interviewing

Plan the interview.

 Prepare interviewee: appointment, nature of
interview,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.

6-6 © 2005 by Prentice Hall

 Interview Guide
is a document
for developing,
planning and
conducting an
interview.

Each question
in an interview
guide can
include both
verbal and non-
verbal
information.

6-7 © 2005 by Prentice Hall

 Disadvantages of Individual
Interviews

Interview one person at a time

Advantages
 Easier to schedule than group interviews
Disadvantages
 Contradictions and inconsistencies
between interviewees
 Follow-up discussions are time
consuming

6-8 © 2005 by Prentice Hall

 Group Interviews

Interview 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

6-9 © 2005 by 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 blackboard.
 Group discusses the ideas.
 Ideas are prioritized, combined, selected,
reduced.

6-10 © 2005 by Prentice Hall

 Other Approaches

What is Direct Observation?

 Watching users do their jobs
 Can provide more accurate information
than self-reporting (like questionnaires
and interviews)
What is Document Analysis?
 Review of existing business documents
 Can give a historical and “formal” view of
system requirements
 Mission, business plans, org. charts,
policy manuals, job descriptions,
internal/external correspondence, reports

6-11 © 2005 by Prentice Hall

 Analyzing Procedures and
Other Documents

Types of information to be discovered for

new system:

 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

7.12
6-12 © 2005 by Prentice Hall
 Analyzing Procedures and
Other Documents (cont.)

Four types of useful documents

 Written work procedures
 Describes how a job is performed
 Includes data and information used and
created in the process of performing the job or
task
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

7.13
6-13 © 2005 by Prentice Hall
 Formal vs. Informal Systems
Formal
 The official way a system works as described
in organization’s documentation
 Procedure documents describe formal
system
Informal
 The way a system actually works in practice
 Interviews and observation reveal informal
system

6-14 © 2005 by Prentice Hall

 Analyzing Procedures and
Other Documents (cont.)

 Business form
 Explicitly indicate data flow in or out of a
system
 Report
 Enables the analyst to work backwards from
the report to the data that it generated
 Description of current information system
o how they are designed & how they work

6-15 © 2005 by Prentice Hall

 Contemporary Methods for
Determining Requirements
Joint Application Design (JAD)
 Brings together key users, managers, and
systems analysts
 Purpose: collect system requirements
simultaneously from key people
 Conducted off-site in special purpose
rooms
 Participants: JAD session leader, Users,
Managers, Sponsors, System analysts,
Scribe, IS staff
 Held in a special purpose room

 End result: Detailed information on what is

desired on the replacement system
6-16 © 2005 by Prentice Hall
 Participants - JAD

Session Leader: facilitates group process

Sponsor: Importance of upgrading
System analyst: present on key problems
Users & Managers: pros & cons
Session Leader: Identifies root problems,
design of original system & its intents
Issues not resolved are noted to carry on
other JAD sessions
Analysts: Discuss on forms & reports &
consolidates what they learned at the end
Scribe: record session activities
Session Leader documents the findings &
circulate to users & analysts

6-17 © 2005 by Prentice Hall

 Contemporary Methods for
Determining Requirements (cont.)

Taking part in JAD (Maters discussed

&documented)
o Overview of the current system & problems
associated with it
o Analysis of current system screens
o Analysis of reports,

End Result
 Documentation detailing existing system
 Features of proposed system

6-18 © 2005 by Prentice Hall

6-19 © 2005 by Prentice Hall
 Categories of CASE

Upper CASE: support information

planning, project identification and
selection, project initiation and planning,
analysis and design
Lower CASE: support the implementation
and maintenance phases of the systems
development life cycle
Cross life-cycle CASE: support activities
that occur across multiple phases of the
systems development life cycle

6-20 © 2005 by Prentice Hall

 Joint Application Design (cont.)
CASE Tools During JAD
 Used to analyze existing systems
 Help discover requirements to meet
changing business conditions
 Upper CASE tools are used

 Planning tools, diagramming tools,

prototyping tools(form & report generators)
 Requirement determination & structuring-
diagramming / Forms/reports: More
interaction
 Diagramming & Prototyping : Graphical form
to users – what the alternative system will
look like.
 Enables analysts to enter system models
directly into CASE during the JAD session
 Project Menu, display
6-21 & report designs :
© 2005 by Prentice Hall
Evaluate
6-22 © 2005 by Prentice Hall
 Joint Application Design (cont.)
Supporting JAD with GSS
 Group support systems (GSS) can be
used to enable more participation by
group members in JAD
 Facilitate sharing of ideas and voicing of
opinions about system requirements
 Members type their answers into the
computer
 All members of the group see what other
members have been typing
 Electronic Meeting system(EMS)

6-23 © 2005 by Prentice Hall

 GSS
Two of the currently available EMS
software packages are The Meeting
Room by Eden Systems Corporation
and Team Talk by Trax Soft works, Inc.
The Meeting Room and Team Talk are
relatively low-cost Windows-based
packages.
A 20-user license for each of these
packages can be obtained for
approximately $1,500.
More expensive systems are available
which may cost in excess of $20,000.

6-24 © 2005 by Prentice Hall

 Prototyping
Iterative development process


 Refine understanding of system

requirements in concrete terms
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
Most useful when:
 User requests are not clear
 Few users are involved in the system
 Designs are complex and require concrete form
 History of communication problems between
analysts and users
 Tools are readily available to build prototype

6-25 © 2005 by Prentice Hall

 Prototyping (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

6-26 © 2005 by Prentice Hall