Introduction

• The goal of this phase is to understand

the requirements of the new system
and latter develop a system that
addresses them.
• First Challenge is collecting and
integrating the information

• The second challenge is finding the right

people to participate.
Slide 1
 Requirements Determination
• This is the most critical step of the entire
SDLC because it is here that the major
elements of the system first begin to
emerge, and the system is easy to change
since little work has been done yet. As the
system moves further into development, it
becomes harder to return to requirements
determination and to make major changes.

• More than half of the systems fail due to

problems with the requirements. Slide 2
 What are Requirements?

• Requirements – simply a statement of

WHAT the system must do OR a
characteristic it must have.

• Requirements tell the developer what the

system will do and not how to design the
system.

Slide 3
 Types of Requirements

• Requirements written from the business

and user perspective – User
requirements

• Business/ user requirements evolve to

become more technical and they describe
how the system will be implemented and
they are written from developer
perspective- system requirements
Slide 4
 User Requirements
Classifications
• Functional requirements: relate directly to a
process the system has to perform or information it
needs to contain. They define the functions that the
system needs to have, for example a requirement
that states that the system must have the ability to
search for available inventory or to report actual
and budgeted expenses.

• Non-functional requirements: refer to behavioral

properties that the system must have, for example
performance, usability, security, quality etc, used
Slide 5
mainly in the design phase.
 Requirements Definition

• The requirements definition report- just

called the requirements definition is a
straightforward text report that simply lists
the functional and non functional
requirements in an outline format.

• Each numbered (in a legal / outline format)

for clear identification.

Slide 6
Functional Requirements

Slide 7
Nonfunctional Requirements

Slide 8
 Requirement Analysis
Techniques
• Before the project team can determine what
requirements are appropriate for a given system,
they need to have a clear vision of the kind of
system that will be created and level of change
that it will bring to the organization.
• Basic process of analysis is divided into three
steps
– Understanding as-is system
– Identify improvements
– Develop requirements for the to-be system
Slide 9
 Requirements Analysis
Techniques

1. BPA (Business Process Automation)

2. BPI (Business Process Improvement)
3. BPR (Business Process Reengineering)

• The above techniques are used by analysts to

help users discover their needs

Slide 10
 Business Process Automation
(BPA)
– Doesn’t change basic operations
– Automates some operations
– More time is spent understating the current as-is
system before improvements.
• BPA Techniques
– Problem Analysis (ask stakeholders to indentify
problems with as-is system and describe how to solve
them in the to-be system)
– Root Cause Analysis (root causes of problems are
investigated)

Slide 11
 Business Process Improvement
(BPI)

• Business Process Improvement (BPI)

– Making moderate changes to the way an
organization operates to take advantage of
new opportunities offered by technology
– Can improve efficiency
– Can improve effectiveness
– Study the as-is system (though with less time
than BPA)
– Primary focus- improving business processes
Slide 12
 BPI Components
• Duration Analysis
– Detailed examination of the amount of time
taken to perform each process in the current
as-is system
• Activity-Based Costing
– Examines major process costs
• Informal Benchmarking
– Studies how other organizations perform their
business processes in order to learn how the
organization can do better. Slide 13
 Business Process
Reengineering (BPR)
• Changes how the organization operates
• Making major changes to take advantage of new ideas and
technology
• Spends little time on understanding the as-is; goal is to
focus on new ideas and new ways of doing business.
• BPR Activities:
– Outcome Analysis (defines the outcomes that provide
value to the customer)
– Technology analysis (identify interesting technologies
and see how they might fit into the processes of the
organization)
– Activity Elimination (business processes are simplySlide 14
eliminated that may prove to be no needed)
 Select Appropriate Technique

• Assess Potential Business Value

• Determine Project Cost
• Specify Breadth or Scope of Analysis
• Determine Risk of Failure

Slide 15
Business Process Techniques

Slide 16
 Requirements Gathering
• An analyst is like a detective- knows that there is a
problem to be solved and must look for clues that
uncover the solution.
• Clues are not obvious- needs to talk to stake holders /
notice details
• Requirements gathering process is used to build political
support for the project and establish trust and rapport
between the project team and the users. All key
stakeholders (the people who can affect the system or
will be affected by it) must be included.
• Choose the best and appropriate ways of gathering
Slide 17
information.
 Techniques for
Requirements Gathering

• Interviews
• Questionnaires
• Document analysis
• Observation
• Joint Application Design (JAD) sessions
• Prototyping
• E.t.c
Slide 18
 Techniques for Requirements
Gathering - Interviews

• Most commonly used requirements-

gathering technique

• 5 basic steps to the interview process:

– Selecting interviewees
– Designing interview questions
– Preparing for interview
– Conducting the interview
– Post interview follow-up
Slide 19
 Conducting the Interview

• Appear professional and unbiased

• Record all information
• Check on organizational policy regarding tape
recording
• Be sure you understand all issues and terms
• Separate facts from opinions
• Give the interviewee time to ask questions
• Be sure to thank the interviewee
• End on time
Slide 20
 Conducting the Interview
Practical Tips

• Don’t worry, be happy

• Pay attention
• Summarize key points
• Be succinct (concise / to the point)
• Be honest
• Watch body language

Slide 21
 Post-Interview Follow-Up

• Prepare interview notes

• Prepare interview report (contains interview

notes, information that was collected over the
course of the interview and is summarized in a
useful format)

• Look for gaps and new questions

Slide 22
 Interview Report
INTERVIEW REPORT

Interview notes approved by: ____________

Person interviewed ______________

Interviewer _______________
Date _______________
Primary Purpose:

Summary of Interview:

Open Items:

Detailed Notes:
Slide 23
JOINT APPLICATION
DESIGN (JAD)

Slide 24
 JAD Session

• An information-gathering technique that allows

the project team, users, and management to
work together to identify requirements.

• Structured process in which 10-20 users meet

together under the direction of a facilitator skilled
in JAD techniques.

• More structured than interviews.

Slide 25
 JAD
• Allows project managers, users, and developers
to work together.

• May reduce scope creep by 50%

• Avoids requirements being too specific or too

vague

Slide 26
 JAD - Important Roles

• Facilitator
– sets the meeting agenda and guides the
discussion
• Scribe
– assist the facilitator by recording notes,
making copies, etc.
• Project team, users, and
management participate in the
discussions. Slide 27
 JAD - Setting
• U-Shaped seating
• Away from distractions
• Whiteboard/flip chart used
• Prototyping tools (some people design
screens in JAD session- prototyping tools
aid in this)
• e-JAD

Slide 28
 The JAD Session
• Tend to last 5 to 10 days over a three week
period
• Prepare questions as with interviews
• Follows a formal agenda and ground rules
• Facilitator activities
– Keep session on track
– Help with technical terms and jargon
– Record group input
– Help resolve issues
• Post-session follow-up to summarize JAD
findings Slide 29
 Managing Problems in JAD
Sessions
• Reducing domination- one person should not
monopolize the conversation so that only his/her
requirements are in the findings.
• Facilitator and other participants should encourage
non-contributors
• Side discussions in breaks are recommended
• Agenda merry-go-round:- happens when a member
keeps returning to the same issue every few minutes
and will not let go. Let them talk as you note down
what they say, if they bring up the same issue, refer to
Slide 30
the flip chart and let others contribute to the issue.
 Managing Problems in JAD
Sessions
• Violent agreement- participants agree on issues because
they are using different terms. Facilitator has to define and
translate terms into different words and find common ground
so that parties realize that they really agree.
• Unresolved conflict: Participants can’t agree and can’t
determine what alternatives are better. In this case, structure
the issue, ask the group for criteria by which they can identify
good alternatives, then ask the group to assess the
alternatives using the list.
• True conflict- Group can’t agree on an issue- postpone the
discussion and move on. Return to it later.
• Use humor when needed, keep the session enjoyableSlide
– 31
encourages participation.
 Techniques for Requirements
Elicitation - Questionnaires

• Useful when the opinions of a large number

of individuals need to be determined
• Forms of questionnaires:
– paper
– email or Web
• Design of questions is critical to success

Slide 32
 Questionnaire Steps
• Selecting participants
– Using samples of the population
• Designing the questionnaire
– Careful question selection
• Administering the questionnaire
– Working to get good response rate
• Questionnaire follow-up
– Send results to participants
Slide 33
 Good Questionnaire Design
• Begin with nonthreatening and interesting
questions.
• Group items into logically coherent sections.
• Do not put important items at the very end of the
questionnaire.
• Do not crowd a page with too many items.
• Avoid abbreviations.
• Avoid biased or suggestive items or terms.
• Number questions to avoid confusion.
• Pretest the questionnaire to identify confusing
questions.
Slide 34
• Provide anonymity to respondents.
 Document Analysis

• Examination of the various forms or

documents used by the client in the
business environment

• Provides clues about existing “as-is”

system

Slide 35
 Document Analysis

• Example of documents reviewed and

analyzed
– Forms
– Reports
– Policy manuals
• Look for user additions to forms
• Look for unused form elements

Slide 36
 Techniques for Requirements
Gathering – Observation

• Powerful tool for gathering

information about an existing system
• Methods of observation:
– personal observation
– video cameras

Slide 37
 Techniques for Requirements
Gathering – Observation

• Video cameras
– Set up video cameras within the
workplace to record exactly what is
being done
– Must have prior written permission from
those being observed

Slide 38
 Observation
• Users/managers often don’t remember
everything they do
• Checks validity of information gathered
through other methods
• Behaviors change when people are
watched
• Careful not to ignore periodic activities
– Weekly … Monthly … Annual
Slide 39
Selecting a Technique

Slide 40
 Problems of Requirements
Analysis
• Stakeholders don’t know what they really want.
• Stakeholders express requirements in their own
terms.
• Different stakeholders may have conflicting
requirements.
• Organizational and political factors may influence
the system requirements.
• The requirements change during the analysis
process. New stakeholders may emerge and the
Slide 41
business environment change.
 Summary
• First Step to system development is to
determine requirements
• Systems analysts use the following
techniques
– Interviews,
– JAD,
– Questionnaires,
– Document Analysis,
– Observation Slide 42