COMP303TH

Software Engineering

Lecture: 6
Requirement Elicitation Process

Requirement elicitation is the process of collecting the requirements of a

system or requirement gathering from user, customers and stakeholders by
conducting meetings, interviews, questionnaires, brainstorming sessions,
prototyping etc.
Elicitation is gathering of all the system requirements from the stakeholders
and it encompasses all activities involved in discovering the requirements of a
system. The system developers and engineers work in a close relationship with
the customers and end-users to determine more about the problem to be
solved and to bridge the gap between the stakeholders and the developers.
Elicitation techniques facilitates this process by:
 Finding out more about the problem to be solved.
 Describing the functionalities of the system and non functional
attributes.
 Enhances the performance of the system.
 Overcomes hardware constraints.
 Bridges the gap between the stakeholders and the developers.

Requirement Elicitation Methods:

There are number of requirements elicitation methods. Some are:
 Interviews
 Brainstorming Sessions
 Facilitated Application Specification Technique (FAST)
 Quality Function Deployment(QFD)
 Use Case Approach

18
 COMP303TH
Software Engineering

The success of an elicitation technique used depends on the maturity of the

analyst, developers, users and the customer involved.
1. Interviews:
Objective of conducting an interview is to understand the customer’s
expectations from the software. It is impossible to interview every
stakeholder hence representatives from groups are selected based on
their expertise and credibility.
Interviews may be open-ended or structured.
 In open-ended interviews there is no pre-set agenda. Context free
questions may be asked to understand the problem.
 In structured interview, agenda of fairly open questions is
prepared. Sometimes a proper questionnaire is designed for the
interview.

2. Brainstorming Sessions:
 It is a group technique.
 i.e. an informal debate is held among various stakeholders
and all their inputs are recorded for further requirement
analysis.
 It is intended to generate lots of new ideas hence providing a
platform to share views.
 A highly trained facilitator is required to handle group bias and
group conflicts.
 Every idea is documented so that everyone can see it.
 Finally, a document is prepared which consists of the list of
requirements and their priority if possible.

3. Facilitated Application Specification Technique:

It’s objective is to bridge the expectation gap – difference between
what the developers think they are supposed to build and what
customers think they are going to get.
A team oriented approach is developed for requirements gathering.
Each attendee is asked to make a list of objects that are-
 Part of the environment that surrounds the system
 Produced by the system
 Used by the system

Each participant prepares his/her list, different lists are then

combined, redundant entries are eliminated, team is divided into
smaller sub-teams to develop mini-specifications and finally a draft

19
 COMP303TH
Software Engineering

of specifications is written down using all the inputs from the

meeting.

4. Quality Function Deployment:

In this technique customer satisfaction is of prime concern, hence it
emphasizes on the requirements which are valuable to the
customer.
3 types of requirements are identified –
 Normal requirements – In this the objective and goals of the
proposed software are discussed with the customer. Example –
normal requirements for a result management system may be entry
of marks, calculation of results, etc
 Expected requirements –These requirements are so obvious that
the customer need not explicitly state them. Example – protection
from unauthorized access.
 Exciting requirements – It includes features that are beyond
customer’s expectations and prove to be very satisfying when
present. Example – when unauthorized access is detected, it should
backup and shutdown all processes.
The major steps involved in this procedure are –
 Identify all the stakeholders, eg. Users, developers, customers etc
 List out all requirements from customer.
 A value indicating degree of importance is assigned to each
requirement.
 In the end the final list of requirements is categorized as –
1. It is possible to achieve
2. It should be deferred and the reason for it
3. It is impossible to achieve and should be dropped off.

5. Use Case Approach:

This technique combines text and pictures to provide a better
understanding of the requirements.
The use cases describe the “what”, of a system and not “how”. Hence they only
give a functional view of the system.
The components of the use case design includes three major things: Actor, Use
Cases, use case diagram.
 Actor: It is the external agent that lies outside the system but interacts
with it in some way. An actor may be a person, machine etc. It is
represented as a stick figure. Actors can be of two types:
 Primary actors: It requires assistance from the system to achieve
a goal.
 Secondary actor: It is an actor which the system needs
assistance.

20
 COMP303TH
Software Engineering

 Use cases: They describe the sequence of interactions between actors

and the system. The capture who (actors) do what(interaction) with the
system. A complete set o fuse cases specifies all possible ways to use the
system.
 Use case diagram: A use case diagram graphically represents what
happens when an actor interacts with a system. It captures the
functional aspect of the system.
 A stick figure is used to represent an actor.
 An oval is used to represent a use case.
 A line is used to represent a relationship between an actor and a
use case.

21