Requirement

Elicitation
The Analysis Phase
• Determining what the new system should do
PART ONE
Learning Objectives

 Explain the analysis phase of the SDLC

 Describe the content and purpose of the
requirements definition statement.
 Classify requirements correctly as business, user,
functional, or nonfunctional requirements.
Performing Requirements Determination

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

5
Requirement
• What is a requirement?
 A statement of what the system must do; or
 A statement of characteristics the system must have
Type of Requirement
Business requirement for
Business
Requirements that company

What user needs to do to

How the system should be System User complete a task in systems
built Requirements Requirements

Requirement

Behavioral properties the system must have

- Operational (where the system will
operate ;mobile,web-based, android, ios, - Process-oriented
etc) (a process the system must perform)
- Performance (speed, capacity, reliability) Non-
Functional - Information-oriented
functional
- Security (authorized access, virus Requirements (information the system must contain)
Requirements
protected)
- Cultural and policy (company policy etc)
Example
PART TWO
Learning Objectives
 Describe good systems analysis characteristics
 Describe traditional, contemporary and radical approaches to
requirements determination.
 Deliverables and outcome from requirement determination
Good Systems Analysist Characteristics
Impertinence Question everything

Challenge yourself to new Consider all issues to find

ways Reframing Impartiality the best organizational
solution
Characteristics

Every fact must fit Attention to Relax Assume anything is possible

details constraints
Method for Requirement Determination / Elicitation

Traditional Method Contemporary Radical Methods

Method
• Interviewing • Joint Application • Business Process
individuals Design (JAD) Reengineering
• Interviewing groups • Group Support (BPR)
• Observing workers Systems
• Analyzing • CASE tools
Procedures and • System prototypes
others documents
TRADITIONAL METHOD
1. Interview
• Plan the interview
• Listen carefully and take notes
• Review notes within 48 hours
Guidelines • Be neutral
• Seek diverse views
• Open-ended questions :
questions that have no
specific answers
• Closed-ended questions :
questions that ask those Question
responding to choose
from among a set of • Names as Nominal Groups Technique (NGT)
specified responses
• Process
• Members come together as a group but work
separately
Interviewing • Each person writes ideas
in groups • 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
2. Observation
– Watching users do their jobs
– Time-consuming and limited time to observe
3. Analyzing Procedures and Other Documents
• 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.
interview, observation
Systems
procedure
• Written work procedure • May involve duplication of
• Business form effort
• Report • May have missing procedures
• Description of current • May be out of date
information system • May contradict information
obtained through interviews
Problems with
Useful document procedure
documents
CONTEMPORARY METHOD
1. Joint Application Design (JAD)
JAD PARTICIPANTS:
1. Session Leader: facilitates group
process
2. Users: active, speaking participants
3. Managers: active, speaking
participants
4. Sponsor: high-level champion, limited
participation
5. Systems Analysts: should mostly listen
6. Scribe: record session activities
7. IS Staff: should mostly listen

END RESULT:
 Documentation detailing existing
• Brings together key users, managers, and systems analysts system
• Purpose: collect system requirements simultaneously from  Features of proposed system
key people
• Conducted off-site
2. Group Support Systems

• Facilitate sharing of ideas and voicing of opinions

about system requirements
3. CASE Tools

 Used to analyze existing systems

 Help discover requirements to meet
changing business conditions
4. System Prototype
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.
 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
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
RADICAL METHOD
Business Process Reengineering
GOALS
 Reorganize complete flow of data
in major sections of an
organization.
 Eliminate unnecessary steps.
 Combine steps.
 Become more responsive to future
change.

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 as requirements
determination are used
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.
Disruptive Technologies (Cont.)
DELIVERABLES AND OUTPUT
Deliverables and Outcome for Requirements Determination

From
From Interviews From existing
computerized
and observations written document
sources
Mission and strategy
Interview transcripts statements JAD session result

Business forms
Reports from existing
Observation notes
systems
Procedure manuals

Displays and reports from

Meeting minutes flowcharts system prototype