Software Requirements Engineering

S.ZarAfshan Goher

Week 6: Lecture 11-12

Requirements Elicitation Techniques

In requirements engineering, requirements elicitation is the practice of researching and

discovering the requirements of a system from users, customers, and other stakeholders. The
practice is also sometimes referred to as "requirement gathering".

Before requirements can be analyzed, modeled, or specified they must be gathered through an
elicitation process. Requirements elicitation is a part of the requirements engineering process,
usually followed by analysis and specification of the requirements.

Commonly used elicitation techniques are listed below:

Requirements Elicitation Techniques

1. Interviews
2. Background Reading
3. Introspection

4. Social Analysis
5. Requirements Workshops
6. Brainstorming and Idea Reduction

7. Storyboarding
8. Prototyping

1. Interviews
Interviews are strong medium to collect requirements. Organization may conduct several types
of interviews such as:

a. Structured (closed) interviews, where information to gather is decided in advance, they

follow pattern and matter of discussion firmly.
b. Non-structured (open) interviews, where information to gather is not decided in advance,
more flexible and less biased.
 Software Requirements Engineering
S.ZarAfshan Goher

c. Oral interviews
d. Written interviews
e. One-to-one interviews which are held between two persons across the table.
f. Group interviews which are held between groups of participants. They help to uncover
any missing requirement as numerous people are involved.

2. Surveys

Organization may conduct surveys among various stakeholders by querying about their
expectation and requirements from the upcoming system. A document with pre-defined set of
objective questions and respective options is handed over to all stakeholders to answer, which
are collected and compiled.

The Survey Method is an electronic or paper based method of soliciting needs or requirements
from stakeholders. The survey method is a list of questions, directed at identifying stakeholder
needs or requirements. Having a wide range of stakeholders in your project presents challenges to
understanding their requirements. It’s great to have a lot of input, but you need to keep an eye on
costs during the initial stages of your project.

Using a survey or questionnaire to gather information for your project’s requirements is cost-
effective and removes constraints such as a geographically dispersed stakeholder base or time
issues.

Survey Method Advantages:

1. A survey can reach a large number of stakeholders or other sources of information.
2. A survey is an excellent tool to gather a significant amount of focused data in a short period
of time.
3. Survey method can provide good results when used to validate assumptions after the use of
the interviewing technique.
4. A Survey method is a good tool to gather statistical preference data.
5. A survey requires little scheduling effort.
6. A survey requires little stakeholder commitment of time and effort.
 Software Requirements Engineering
S.ZarAfshan Goher

Disadvantages:
1. The response level is often low, especially to large surveys.
2. Responses are usually limited to the realm of the questions asked, which reflect the analyst’s
preconceived ideas or assumptions of the survey designer.
3. Well-made surveys require trained and experienced personnel to develop.
4. Development time can be significant.
5. Conflicts and inconsistencies in information from stakeholders require additional analysis to
resolve.

3. Background Reading
It is appropriate when you are not familiar with the organization being investigated. Background
Reading is used to gather information about the organization, which is helpful to gain an
understanding of the organization’s structure, its working, and the existing system.

Background Reading technique is not solely used for eliciting requirements because you cannot
get the real user needs by just studying the existing documents. It is used as a complementary
approach with other techniques.

The Sources of information will be Company reports, organization charts, policy manuals, job
descriptions, reports, documentation of existing systems, etc.

4. Introspection
In Introspection technique Requirements analyst “imagines” what kind of system is required for
doing the required job, or by using available equipment etc. Introspection is the first and the most
obvious method for trying to understand what properties a system should have in order to
succeed.
It will be appropriate for when users are not available, don’t want to answer your questions or
Shows lack of feedback or input then Requirement engineer can use this technique to imagine
the things which he assumes that the user would require.

5. Social Analysis
 Software Requirements Engineering
S.ZarAfshan Goher

Social Analysis is also known as Observation. Observation is a process of collecting

requirements by observing the people doing their normal work. This method is used to find the
additional requirements needed by the user, when the user is unable to explain their expected
requirements.

This Social Analysis can be of the following types:

 Passive Observation

This social analysis is carried out without the direct involvement of the observer in the society.
The observation of the people work is carried out by recording using videotapes, video cameras
and surveillance cameras. The documentation of the problem and requirements are prepared
from the recorded data.

 Active Observation
This social analysis is carried out with the direct involvement of the observer in the society. The
observers encourage people to work with the existing product to perform the operations on the
product. The observer provides the domain knowledge to the user and makes the report of the
requirements of the people by observing their day to day work with the product.

 Explanatory Observation

In this type of observation the user talks loudly, explaining what they are doing while using the
product. The observer takes notes using the explanation given by the user.

6. Requirements Workshops
A requirements workshop is a structured, assisted and collaborative event in which a selected
group of stakeholders work together to discover, create, verify, and document requirements,
deliverables and work products. The requirements workshop is perhaps the most powerful
technique for eliciting requirements.

It gathers all key stakeholders together for a short but strongly focused period.

The use of an outside facilitator experienced in requirements management can ensure the success
of the workshop. Brainstorming is the most important part of the workshop.
 Software Requirements Engineering
S.ZarAfshan Goher

Participants of Workshop

 Sponsor: May not attend each workshop but might kick off the initial workshop.

 Content Participants: Subject matter experts and user representatives.

 Facilitator: Neutral skilled person who designs and lead the workshop

 Recorder: Neutral person experienced in documenting the specific work product. This
role can be filled by an analyst, developer, tester, Project manager.

 Planning Team: A minimum of three people- a content participant, a technical member

(can be analyst) and facilitator.

What happens in Workshop?

Team members create, review and complete important requirements deliverables. The facilitator
manages the group’s process. The Recorder documents the group’s work as its proceeds.

Preparing for the Workshop:

“Proper preparation for the workshop is critical to success.” Selling the workshop concept to
stakeholders. Ensuring the Participation of the Right Stakeholders. Attending Logistics involve
everything from structuring the proper invitation to travel arrangements to the lighting in the
workshop meeting room.

Preparation of Warm-up materials

a. Project-specific information:

This might include drafts of requirements documents, suggested features, copies of interviews,
analyst's reports on industry trends, bug reports from existing system, new management orders,
new marketing data, and so on. Although it's important not to bury the attendees in data, it's also
important to make sure they have the right data.

b. Out-of-box thinking preparation

Part of "getting their minds right" is encouraging attendees to think "out of the box." "Forget for
a minute what you know and what can't be done due to politics. Forget that we haven't yet
 Software Requirements Engineering
S.ZarAfshan Goher

standardized our development process. Simply bring your insights on the features of this new
project, and be prepared to think 'out of the box.'"

Role of Facilitator:

i. Establish professional and objective tone to the meeting.

ii. Start and stop the meeting on time.
iii. Establish and enforce the “rules” for the meeting.
iv. Introduce the goals and agenda for the meeting.
v. Manage the meeting and keep the team “on track.”
vi. Facilitate a process of decision and consensus making, but avoid participating in the
content.
vii. Make certain that all stakeholders participate and have their input heard.
vii. Control troublesome or unproductive behavior.
Work Agenda: Set an agenda before the workshop and publish it along with the other pre-
workshop documentation.

Workshop Problems and Suggestions:

6. Prototyping
 Software Requirements Engineering
S.ZarAfshan Goher

Prototyping is building user interface without adding detail functionality for user to interpret the
features of intended software product. It helps giving better idea of requirements. If there is no
software installed at client’s end for developer’s reference and the client is not aware of its own
requirements, the developer creates a prototype based on initially mentioned requirements. The
prototype is shown to the client and the feedback is noted. The client feedback serves as an input
for requirement gathering.