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.
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.
Performing Requirements Determination

FIGURE 6-1
Systems development life cycle with
analysis phase highlighted
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
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
• Interviewing individuals
Traditional Methods for Determining Requirements

• Interviewing groups
• Observing workers
• Studying business documents
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.
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.
Interviewing and Listening
(Cont.)

FIGURE 6-2 Typical interview guide

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
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
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
 Nominal Group Technique
• A facilitated process that supports idea generation by groups
(NGT)
•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.
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.
 Directly
• Direct Observation Observing Users
• Watching users do their jobs
• Obtaining 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
Analyzing Procedures and Other Documents
• Document Analysis
• Review of existing business documents
• Can give a historical and “formal” view of system requirements
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
 Analyzing
• Useful document: Procedures
Written workand Other Documents
procedure
(Cont.)
• 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
Analyzing Procedures and Other Documents
(Cont.)

FIGURE 6-3 Example of a procedure

 Analyzing
• Potential Procedures
Problems with Procedureand Documents:
Other Documents
(Cont.)
• May involve duplication of effort.
• May have missing procedures.
• May be out of date.
• May contradict information obtained through interviews.
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)
 Analyzing Procedures and Other Documents
• Useful document: Business form
(Cont.)
• 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
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#
 Analyzing
• Useful document: Procedures
Report and Other Documents
(Cont.)
• 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
Analyzing Procedures and Other Documents
(Cont.)
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
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
• Rudimentary working version of system is built
• Refine understanding of system requirements in
concrete terms
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
JAD (Cont.)

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

Source: Based on Wood and Silver, 1995
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
JAD (Cont.)
• End Result
• Documentation detailing existing system
• Features of proposed system
 CASE
• Upper CASE toolsTools
are used 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
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
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.
• Drawbacks
Using Prototyping During Requirements Determination (Cont.)
• 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
• Business Process
Radical Reengineering
Methods (BPR): System
for Determining search for and implementation
Requirements
of radical change in business processes to achieve breakthrough
improvements in products and services
• Goals
Radical Methods for Determining System Requirements (Cont.)
• Reorganize complete flow of data in major sections of an organization.
• Eliminate unnecessary steps.
• Combine steps.
• Become more responsive to future change.
 Identifying Processes to
• Identification of processes to reengineer
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
 Disruptive
• Information technologies 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.
Disruptive Technologies
(Cont.)
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.
Summary (Cont.)
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.