Experiment 3

Aim: - To identify various elicitation techniques and their usage for the problem.
Elicitation methods used:
 Interviews
This is the most common technique used for requirement elicitation. Interview techniques should be
used for building strong relationships between business analysts and stakeholders. In this technique,
the interviewer directs the question to stakeholders to obtain information. One to one interview is the
most commonly used technique. If the interviewer has a predefined set of questions, then it’s called a
structured interview. If the interviewer is not having any particular format or any specific questions,
then it’s called an unstructured interview. In my problem statement, I have interviewed my family
members and friends to understand what use cases they desire from the software.

 Brainstorming Sessions
This technique is used to generate new ideas and find a solution for a specific issue. The members
included for brainstorming can be domain experts, subject matter experts. Multiple ideas and
information give you a repository of knowledge and you can choose from different ideas. This session
is generally conducted around the table discussion. All participants should be given an equal amount
of time to express their ideas. In my problem statement, I have referred some YouTube videos of
some brainstorming sessions to understand what use cases I should consider.

 Facilitated Application Specification Technique (FAST)

Its 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-
o Part of the environment that surrounds the system
o Produced by the system
o Used by the system
 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, e.g., 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 –
o It is possible to achieve
o It should be deferred and the reason for it
o It is impossible to achieve and should be dropped off
 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 include 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 maybe a person, machine etc. It is represented as a stick figure. Actors can be primary actors
or secondary actors.
o Primary actors – It requires assistance from the system to achieve a goal.
o Secondary actor – It is an actor from which the system needs assistance.
 Use cases: They describe the sequence of interactions between actors and the system. They
capture who(actors) do what(interaction) with the system. A complete set of use 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.