Requirements elicitation

Requirements elicitation is perhaps the most difficult, most error-prone and most communication
intensive software development. It can be successful only through an effective customer-developer
partnership. It is needed to know what the users really need.

There are a number of requirements elicitation methods. Few of them are listed below –

1. Interviews

2. Brainstorming Sessions

3. Facilitated Application Specification Technique (FAST)

4. Quality Function Deployment (QFD)

5. Use Case Approach

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 maybe be open ended or structured.

1. In open ended interviews there is no pre-set agenda. Context free questions may be asked to
understand the problem.

2. 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

 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-

1. Part of the environment that surrounds the system

2. Produced by the system

3. 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
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 unauthorised access.

 Exciting requirements – It includes features that are beyond customer’s expectations and
prove to be very satisfying when present. Example – when an unauthorised access is
detected, it should backup and shutdown all processes.

The major steps involved in this procedure are –

1. Identify all the stakeholders, eg. Users, developers, customers etc

2. List out all requirements from customer.

3. A value indicating degree of importance is assigned to each requirement.

4. In the end the final list of requirements is categorised 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

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.
1. 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.

2. 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.

3. Use case diagram – A use case diiagram graphically represents what happens when an actor
interacts with a system. It captures the functional aspect of the system.

o A stick figure is used to represent an actor.

o An oval is used to represent a use case.

o A line is used to represent a relationship between an actor and a use case.

Basic Use-Case Diagram Symbols and Notations

There are following use-case diagram symbols and notations:

System
With the help of the rectangle, we can draw the boundaries of the system, which
includes use-cases. We need to put the actors outside the system's boundaries.
Use-Case
With the help of the Ovals, we can draw the use-cases. With the verb we have to label
the ovals in order to represent the functions of the system.

Actors
Actors mean the system's users. If one system is the actor of the other system, then
with the actor stereotype, we have to tag the actor system.
Relationships
With the simple line we can represent relationships between an actor and use cases.
For relationships between use-case, we use arrows which are labeled either "extends"
or "uses". The "extends" relationship shows the alternative options under the specific
use case. The "uses" relationship shows that single use-case is required to accomplish
a job.

Guidelines for Better Use-Cases

With regards to examine the system's requirements, use-case diagrams are another
one to one. Use-cases are simple to understand and visual. The following are some
guidelines that help you to make better use cases that are appreciated by your
customers and peers the same.

Generally, the use-case diagram contains use-cases, relationships, and actors. Systems
and boundaries may be included in the complex larger diagrams. We'll talk about the
guidelines of the use-case diagram on the basis of the objects.

Do not forget that these are the use case diagram's guidelines, not rules of the use-case
diagram.

Actors

o The actor's name should be meaningful and relevant to the business

If the use-case interacting with the outside organization, then we have to give
the actor's name with the function instead of the organization name, such as
Airline company is better than the PanAir).
o Place inheriting actors below the parent actor
We have to place the inheriting actors below the parent actor because it makes
the actors more readable and easily highlights the use-cases, which are exact
for that actor.
 o External Systems are actors
If send-email is our use-case and when the use-case interrelates with the email
management software, then in this case, the software is an actor to that
specific user-case.

Use-Cases

o The name of the use-case begins with a verb

The use-case models action, so the name of the use-case must start with a
verb.
o The name of the use-case must be descriptive
The use-case is created to provide more information to others who are looking
at a diagram, such as instead of "Print," "print Invoice is good.
o Put the use-cases to the right of the included use-cases.
In order to add clarity and enhance readability, we have to place the included
use-cases to the right of the invoking use-cases.
o Place inheriting use-case below the parent use-case
In order to enhance the diagram's readability, we have to place the inheriting
use-case below the parent use-case.

Systems/Packages

o Give descriptive and meaningful names to these objects.

o Use them carefully and only if needed.

Relationships
o When we are using <<extend>> arrow, points to the base use-case.
o When we are using <<include>> then arrow points to the comprised use-case.
o Actor and use-case relationship do not display arrows.
o <<extend>> may have an optional extension condition.
o <<include>> and <<extend>> both are shown as dashed arrows.

Use-Case Examples
Use-Case Example-Association Link
In this use-case diagram, we show a group of use cases for a system which means the
relationship among the use-cases and the actor.

Use-Case Example-Include Relationship

In order to add additional functionality that is not specified in the base use-case, we
use to include relationship. We use it to comprise the general behavior from an
included use case into a base case so that we can support the reuse general behavior.
Use-Case Example-Extend Relationship
With the help of the extend relationship, we can show the system behavior or
optional functionality. We use <<extend>> relationship in order to comprise optional
behavior from an extending use-case in an extended use-case. For example, the
below diagram of the use-case displays an extend connector and an extension point
"Search".
Use-Case Example-Generalization Relationship
In the generalization relationship, the child use-case can inherit the meaning and
behavior of the parent use-case. The child use-case is able to override and adds the
parent's behavior. The below diagram is an example of generalization relationship in
which two generalization connector is connected among three use-cases.

Use-Case Diagram-Vehicle Sales Systems

The below diagram displays an instance of a use-case diagram for a vehicle system.
As we can also see, a system as much as one vehicle sales system contains not in
excess of 10 use-cases, and it is the delicacy of use-case modeling.

The use of include and extend is also displayed by the use-case model. In addition,
there are associations that link between the use-case and
actors.

Use-Case Diagram-Student Management System

The below figure shows the working of the student management system:
In the above use-case diagram of the student management system, we have two
actors and five use-cases. The name of the actors is Student and Teacher. The use-
cases represent the definite functionality of the student management system. Every
actor interacts with a specific use-case. The student actor is able to check the test
marks, time-table and attendance. These are only 3 interactions that can be
performed by the student actor; however various use-cases are also remaining in the
system.

It is not must that every actor has to interact with each and every use-case, but it can
happen.

In the diagram, the name of the second actor is a Teacher. Teacher is an actor that is
able to interact with all the system's functionalities. The teacher actor is also able to
update the student's marks as well as attendance. Theses interactions of student as
well as teacher actors together summarize the whole student management
application.

Example: Use Case Diagram

Below is a sample use case diagram which I have prepared for reference
purpose for a sample project (much like Facebook). It would help us to
understand the role of various actors in our project. Various actors in the
below use case diagram are: User and System.
The main use cases are in the system and the diagram illustrates on how the
actors interact with the use cases.For eg. During Sign Up, only users need to
interact with the use case and not the system whereas when it comes to
categorizing posts, only system would be required.