Table of contents
1.
Introduction
2.
Requirement Elicitation Activities 
3.
Requirements elicitation Methods
4.
FAQs
5.
Key Takeaways
Last Updated: Mar 27, 2024

Requirement Elicitation and Analysis

Author Shivani Kumari
3 upvotes
Career growth poll
Do you think IIT Guwahati certified course can help you in your career?

Introduction

Requirement elicitation is a process that involves gathering, researching, defining, structuring, and clarifying the requirements of a product. As a result of elicitation, a Business Analyst creates a set of project objectives. These objectives should be understandable for each team member and represent all the client's demands and needs.

Requirement Elicitation Activities 

Elicitation techniques facilitate this process by:

  • Finding more about the problem to be solved.  
  • Describe the functionalities of the system and non-functional attributes.  
  • Increase the performance of the system. Reduces hardware constraints.  
  • Reduces the gap between the developers and the stakeholders.

Requirements elicitation Methods

There are many requirements elicitation methods. A 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

1. Interviews:

The main objective of an interview is to understand customers' expectations from the software.

It is not possible to interview every stakeholder; hence representatives from groups are selected based on their expertise and credibility.

Interviews may be structured or open-ended.

  1. In a structured interview, agenda of reasonably open questions are prepared. Sometimes a good questionnaire is designed for the interview.
  2. Open-ended interviews do not have any pre-set agenda. Context-free questions may be asked to understand the problem.

2. Brainstorming Sessions:

  • It is a group discussion.
  • Its objective is to generate a lot of new ideas and provide a platform to share the view of every member.
  • A highly trained facilitator handles group bias and group conflicts.
  • Ideas are documented so that everyone can see them.
  • Finally, a document is prepared consisting of the list of requirements and their priority if possible.

3. Facilitated Application Specification Technique:

Its objective is to bridge the expectation gap – the difference between what the developers think they have to build and what customers think they will get.

A team-oriented approach is evolved to get a better understanding of requirements.

Each attendee in the team should make a list of objects such that-

  1. They are part of the environment that surrounds the system.
  2. The system produces them.
  3. The system uses them.

Every participant prepares their list, different lists are then combined, redundant entries are eliminated, the team is divided into smaller sub-groups to develop mini-specifications, and a draft of specifications is written using all the inputs from the meeting.

4. Quality Function Deployment:

In this technique, customer satisfaction is the prime concern; hence it emphasizes the valuable requirements to the customer.

Three types of requirements are identified –

  • Normal requirements – It covers the objective and goals of the proposed software are discussed with the customer. For example – normal requirements for a result management system may be the entry of marks, calculation of results, etc.
  • Expected requirements –  These requirements are so apparent that the customer need not explicitly state them: for example – protection from unauthorized access.
  • Exciting requirements – It includes features beyond customers' expectations and proves to be very satisfying when present. For example – when unauthorized access is detected, it should back up and shut down all processes.

The significant steps involved in this procedure are –

  1. Identify all the stakeholders, e.g., Users, developers, customers, etc
  2. List out all requirements from the customer.
  3. The degree of importance is given to every requirement.
  4. In the end, the final list of requirements is divided as –
  • It is possible to attain.
  • It should be deferred, and the reason for it.
  • It is not possible to achieve and should be dropped off.

5. Use Case Approach:

In this technique, text and pictures are combined to understand the requirements better.

The use cases describe the 'what' of a system and not 'how .' Therefore, 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.

  1. Actor – It is an external agent that lies outside the system but interacts with it somehow. An actor, maybe a person, a machine, etc. It is shown as a stick figure. Actors may be primary actors or secondary actors.
  • Primary actors – They require assistance from the system to accomplish a goal.
  • Secondary actor – The system demands assistance from secondary actors.
  1. Use cases – It describes the sequence of interactions between the system and actors. It captures who(actors) do what(interaction) with the system. A set of Use cases specifies all possible ways to use the system.
  2. Use case diagram – A use case diagram represents what happens when an actor graphically interacts with a system. It has the functional side of the system.
  • A Stick figure is used to show an actor.
  • Oval is used to show the use case.
  • A line represents a relationship between an actor and a use case.

We have discussed methods of requirement elicitation. Now let’s move to FAQ Section to clear your doubts.
 

Also read,  V Model in Software Engineering

FAQs

  1. What is the need for requirement analysis?
    Determining the needs or conditions to meet for a new or altered product or project, taking account of the possibility. Conflicting requirements of the stakeholders, analyzing, documenting, validating, and managing software or system requirements. 
    We need the requirement analysis for all the activities that have been mentioned before.
     
  2. Why is requirements elicitation essential?
    Elicitation is essential as many stakeholders cannot articulate the business problem accurately. Therefore, analysts performing the elicitation need to ensure that the requirements are understandable, helpful, and relevant.
     
  3. Why is requirement elicitation difficult?
    Sometimes, Stakeholders or users cannot specify or mention what they want or their requirements. They sometimes expect or demand unrealistic requirements that cannot be fulfilled. Therefore, it becomes challenging to meet the expectations of the users.
     
  4. What are the common problems encountered during requirements elicitation?
    Conflicting requirements, unspoken or assumed requirements, difficulty in meeting with relevant stakeholders, stakeholder resistance to change, and not enough time set for meeting with all stakeholders are general challenges during requirements elicitation.
     
  5. What are the types of requirements?
    The main types of requirements are Functional Requirements, Performance Requirements, System Technical Requirements, Specifications.

Key Takeaways

In this article, we learned Requirement Elicitation and activities involved in this process. We explore different methods to perform Requirement Elicitation. We get in-depth knowledge of each method.

See more, Application software and Boundary value analysis

Visit here to learn more about topics related to database and management systems. Take a look at the Top 100 SQL Problems to master frequently asked questions in big companies and get your dream job. Practice a wide range of DSA questions on Coding Ninjas Studio to crack interviews.

Live masterclass