0% found this document useful (0 votes)
32 views36 pages

Systems Analysis and Design: Determining System Requirements

This document discusses methods for determining system requirements, including: - Conducting interviews with stakeholders to understand their needs, either individually or in groups. Nominal group technique allows individual brainstorming followed by group discussion. - Observing users to understand their actual work processes in addition to what they report. - Analyzing existing business documents like forms, reports, and system descriptions to understand current data and processes. - Using contemporary methods like joint application design sessions and prototyping to engage stakeholders in envisioning solutions.

Uploaded by

Satya Nadella
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
32 views36 pages

Systems Analysis and Design: Determining System Requirements

This document discusses methods for determining system requirements, including: - Conducting interviews with stakeholders to understand their needs, either individually or in groups. Nominal group technique allows individual brainstorming followed by group discussion. - Observing users to understand their actual work processes in addition to what they report. - Analyzing existing business documents like forms, reports, and system descriptions to understand current data and processes. - Using contemporary methods like joint application design sessions and prototyping to engage stakeholders in envisioning solutions.

Uploaded by

Satya Nadella
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
You are on page 1/ 36

Systems Analysis

and Design

Lecture 5
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.

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.

3
Performing Requirements Determination

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

Chapter 6 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 5
Deliverables and Outcomes

6
Traditional Methods for
Determining Requirements
 At the core of systems analysis is the collection of information.
 At the outset, you must collect information about the information
systems that are currently being used and how users would like to
improve the current systems and organizational operations with new
or replacement information systems.
 One of the best ways to get this information is to talk to the people
who are directly or indirectly involved in the different parts of the
organizations affected by the possible system changes: users,
managers, funders, and so on.
 Another way to find out about the current system is to gather copies
of documentation relevant to current systems and business
processes.

7
Traditional Methods for
Determining Requirements
 In this chapter, you will learn about various ways
to get information directly from stakeholders:

 Interviewing individuals
 Interviewing groups
 Nominal Group Technique
 Observing workers
 Studying business documents

8
Interviewing and Listening
 Interviewing is one of the primary ways analysts gather information
about an information systems project
 Early in a project, an analyst may spend a large amount of time
interviewing people about their work, the information they use to do
it, and the types of information processing that might supplement
their work.
 You may ask the interviewee to think about specific questions or
issues or to review certain documentation to prepare for the
interview.
 Interview Guide is a document for developing, planning and
conducting an interview.
 which sequence you intend to ask your questions
 how much time you want to spend in each area of the interview.

Chapter 6 9
Guidelines for Effective Interviewing
 Plan the interview. you should prepare thoroughly before
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 10
Interviewing and Listening (Cont.)

FIGURE 6-2 Typical interview guide

Chapter 6 11
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, like:
 “What would you say is the best thing about the information system you
currently use to do your job?”

 Closed-ended questions: questions that ask those responding to


choose from among a set of specified responses, like:
• True or false.
• Multiple choice (with only one response or selecting all relevant choices).
• Rating a response or idea on a scale

Chapter 6 12
Interviewing
 A series of interviews may turn up inconsistent information
about the current system or its replacement.

 You must work through all of these inconsistencies to figure


out what might be the most accurate representation of
current and future systems.

 Catching important people in their offices is often difficult


and frustrating, and scheduling new interviews may become
very time consuming.

13
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.

14
Interviewing Groups (Cont.)
 interviewing several people together allows them to hear the
opinions of other key people and gives them the opportunity to
agree or disagree with their peers.
 For example, the comments of one person might cause another
person to say, “That reminds me of” or “I didn’t know that was a
problem.
 The more people who are involved, the more difficult it will be
finding a convenient time and place for everyone.
 Modern videoconferencing technology can minimize the
geographical dispersion factors that make scheduling meetings
so difficult

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

16
Nominal Group Technique (NGT)
 A specific technique for working with groups, Nominal Group
Technique
 The individuals working together to solve a problem are a group
in name only.
 Group members may be gathered in the same room for NGT, but
they all work alone for a period of time.
 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.

17
Directly Observing Users
 People, however, are not always very reliable informants,
even when they try to be reliable and tell what they think is
the truth.

 Direct Observation
 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.
 Employees who know they are being observed may be nervous and make more
mistakes than normal,
 Time-consuming and limited time to observe.

18
Analyzing Procedures and Other
Documents
 You should attempt to find all written documents
about the organizational areas relevant to the
systems under redesign.

 Document Analysis
 Review of existing business documents
 Can give a historical and “formal” view of system
requirements

Chapter 6 19
Analyzing Procedures and
Other Documents (Cont.)
 Useful document: Business form
 Forms are used for all types of business functions,
from recording an order acknowledging the payment
of a bill to indicating what goods have been shipped
 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 20
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 21
Analyzing Procedures and
Other Documents (Cont.)
 Useful document: Report generated by
current systems
 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 22
Contemporary Methods for Determining
System Requirements
 Even though we called interviews, observation, and
document analysis traditional methods for determining a
system’s requirements, all of these methods are still very
much used by analysts to collect important information.

 Today, however, there are additional techniques to


collect information about the current system, the
organizational area requesting the new system, and
what the new system should be like.

Chapter 6 23
Contemporary Methods for
Determining System Requirements

Chapter 6 24
Contemporary Methods for
Determining System Requirements
 Joint Application Design (JAD)
A structured process in which users, managers,
and analysts work together for several days in a
series of intensive meetings to specify or review
system requirements.

 Purpose: collect system requirements


simultaneously from key people

Chapter 6 25
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 26
Joint Application Design (JAD)
 JAD sessions are usually conducted at a
location other than the place where the people
involved normally work.

 The idea behind such a practice is to keep


participants away from as many distractions as
possible so that they can concentrate on
systems analysis.

Chapter 6 27
JAD (Cont.)

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


Source: Based on Wood and Silver, 1995
Chapter 6 28
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 29
JAD (Cont.)
 End Result
 Documentation detailing existing system
 Features of proposed system

Chapter 6 30
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

Chapter 6 31
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 32
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 33
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 34
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.

Chapter 6 35
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.

Chapter 6 36

You might also like