Modern Systems Analysis

and Design
Week 4
Determining System
Requirements

Lecturer: Hamid Milton Mansaray

Phone#: +23276563575
Email: [email protected]
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.
 Describe contemporary approaches to
requirements determination.
 Understand how requirements determination
techniques apply to the development of
electronic commerce applications.
3
Performing Requirements Determination

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

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

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

7
Traditional Methods for
Determining Requirements
 Interviewing individuals
 Interviewing groups
 Observing workers
 Studying business documents

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

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

10
Interviewing and Listening (Cont.)

FIGURE 6-2 Typical interview guide

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 prespecified answers
 Closed-ended questions: questions that ask
those responding to choose from among a set
of specified responses

12
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

13
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

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

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

16
Directly Observing Users
 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
 Time-consuming and limited time to observe

17
Analyzing Procedures and
Other Documents
 Document Analysis
 Review of existing business documents
 Can give a historical and ―formal‖ view of
system requirements

18
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
19
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

20
Analyzing Procedures and
Other Documents (Cont.)

FIGURE 6-3 Example of a procedure

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.

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)

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

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#

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

26
Analyzing Procedures and
Other Documents (Cont.)

27
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

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
 Rudimentary working version of system is built
 Refine understanding of system requirements in
concrete terms

29
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

30
JAD (Cont.)

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

Source: Based on Wood and Silver, 1995
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

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

33
CASE Tools During JAD

 Upper CASE tools are used

 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

34
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

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.

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

37
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

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.

39
Identifying Processes to Reengineer

 Identification of 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

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.

41
Disruptive Technologies (Cont.)

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

43
Continual User Involvement

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

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.

45
 The Planning Game from
eXtreme Programming

FIGURE 6-12
eXtreme Programming’s Planning Game

46
Electronic Commerce Applications:
Determining System Requirements
 Determining system requirements for Pine
Valley furniture’s Webstore
 System layout and navigation characteristics
 Webstore and site management system
capabilities
 Customer and inventory information
 System prototype evolution

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

48
Summary (Cont.)
 Participatein 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.
49