REQUIREMENTS

ANALYSIS
SDLC Phase 1 - Requirements Analysis

• The key person in the first phase of SDLC is the

system analyst, who analyzes the business
situation, identifies opportunities for
improvements, and designs an information system
to implement the improvements.

• The analysis phase answers the 4 Ws - who, what,

where and when.
SDLC Phase 1 - Requirements Analysis
This phase has three steps:
1. Analysis strategy - study the current system and its
problems, and envisioning ways to design a new
system.
2. Requirements gathering - identifying the kinds of
user requirements and strategies of eliciting these
requirements.
3. System proposal - consists of analyses, system
concept and models
 ELICITING
REQUIREMENTS
USER REQUIREMENTS
• refer to the things that user want the software to do for
them, and how they want the software to be like.

Two Kinds of User Requirements:

1 • Functional Requirements

2 • Nonfunctional Requirements
FUNCTIONAL REQUIREMENTS
• are the services that the users want the software
to do for them.

Example:

• A client wants the software that you will

build for him to enable him to add,
update, and delete records of the books in
his database.
NONFUNCTIONAL REQUIREMENTS
• are characteristics that the users want the
software to have.

Example:

The client might want the color of the GUI

be green (his favorite color), or he might
want the response time of the software
not exceed one second.
 ELICITING & UNDERSTANDING
USER REQUIREMENTS

● INTERVIEW ● PROTOTYPING

● OBSERVATION ● Survey / Questionnaire

● DOCUMENT ANALYSIS ● FOCUS GROUP

 INTERVIEW
● It is the most common approach to elicit requirements.
● In this approach, the software engineer or system analyst asks users about their tasks
and task-related problems and how they want the software to assist them in the
performance of these tasks.

Steps in conducting an interview:

▪ Identify which users to interview;
▪ Prepare a list of interview questions for each user;
▪ Set up appointments to interview the identified users;
▪ Conduct the interview; and
▪ Write up transcripts or minutes of the interviews, and ask the
interviewees for approval of the transcripts or minutes

• TRANSCRIPTS – is a word-for-word, written record of the entire interview.

• MINUTES – are records of only the key points of the interview.
OBSERVATION
- In this approach, the software engineer or system
analyst needs to do the following:

● Identify which user or processes to observe;

● Obtain permission to observe users/processes,
and perhaps take videos or pictures;
● Conduct the observation in a non-obtrusive
manner;
● Write up a description of the user’s actions or
processes observed, and ask those observed for
comments on the description.
DOCUMENT ANALYSIS
- In this approach, the software engineer or system analyst look at
paper as well as electronic documents to obtain a preliminary
understanding of the user’s organization and general processes.

Example:
The web site of an organization - to know the organization’s
missions, its major products and processes, who make up the
team, and whom to address the questions about specific
processes or products.
PROTOTYPING
● This is usually done when users are not so sure of what they want.
● It is a non-final version of the software.

Two kinds of prototype:

1. THROWAWAY PROTOTYPE is a preliminary version
of the software; its sole purpose is to help users
visualize the software that he or she wants. It is
usually thrown away once the users have identified
their requirements with a high degree of certainty.
2. EVOLUTIONARY PROTOTYPE is not thrown away
but continuously extended.
SURVEY / QUESTIONNAIRE
● When collecting information from many people – too
many to interview with budget and time constraints

● The survey can force users to select from

choices, rate something (“Agree Strongly,
agree…”), or have open ended questions
allowing free-form responses.

● Survey design is hard – questions can bias

the respondents.
FOCUS GROUP
● It is a gathering of people who are representative of
the users or customers of a product to get feedback.

● The feedback can be gathered about needs /

opportunities / problems to identify requirements,
or can be gathered to validate and refine already
elicited requirements.

● This form of market research is distinct from

brainstorming in that it is a managed process with
specific participants.