Requirements Elicitation or requirements capture or requirements acquisition Techniques

Requirements Elicitation Techniques: A major goal of Requirements Elicitation is to avoid confusion between stakeholders and analysts. This will often involve putting significant sort into requirements elicitation. Unfortunately, Requirements Engineering is an immature discipline, perhaps not entirely unfairly characterized as a battlefield occupied by competing commercial methods, firing competing claims at each other, and leaving the consumers weary and confused.

As requirements elicitation is a process in which intensive interaction between stakeholders and the analysts, so improving the quality of extracted requirements. 

Requirements Elicitation is the process to find out the requirements for an intended software system by communicating with client, end-users, system users and others who have a stake in the software system development.

There are various ways to discover requirements

Interviews

Interviews are a strong medium to collect requirements. An organization may conduct several types of interviews such as:

• Structured (closed) interviews, where every single information to gather is decided in advance, they follow pattern and matter of discussion firmly.
• Non-structured (open) interviews, where information to gather is not decided in advance, more flexible, and less biased.
• Oral interviews
• Written interviews
• One-to-one interviews are held between two persons across the table.
• Group interviews are held between groups of participants. They help to uncover any missing requirement as numerous people are involved.

Scenarios: 

These are descriptions of a sequence of events, which help to determine possible future outcomes before the software is developed or implemented. Scenarios are used to test whether the software will accomplish user requirements. It also helps to provide a framework for questions to software engineers about users' tasks. These questions are asked from users about future conditions (what-if) and procedures (how) in which they think tasks can be completed. Generally, a scenario includes the following information.

• Description of what users expect when the scenario starts
• Description of how to handle the situation when the software is not functioning properly
• Description of the state of the software when the scenario ends.

Questionnaire: 

Questionnaire is an effective tool of gathering requirements and produces a written document. The major advantage of the questionnaire is that it requires less effort and gathers information from many users in a very short time.

On-site observation: 

Generally, users are not able to express the process of how they work. Thus, to have a close look of the system, the analyst may decide to perform the site visit. The site visit enables the analyst to observe the current system, which helps him to detect the problems of the existing system.

Prototypes:

Prototypes help to clarify unclear requirements. Like scenarios, prototypes also help users to understand the information they need to provide to the software development team.

Quality function deployment (QFD): 

This deployment translates user requirements into technical requirements for the software. For this, QFD facilitates the development team to understand what is valuable to users so that quality can be maintained throughout software development. QFD identifies the following user requirements.

1. General requirements: These requirements describe the system objectives, which are determined by various requirements elicitation techniques. Examples of general requirements are graphical displays requested by users, specific software functions, and so on.
2. Expected requirements: These requirements are implicit to software as users consider them to be fundamental requirements, which will be accomplished in the software and hence do not express them. Examples of expected requirements are ease of software installation, ease of software and user interaction, and so on. 
3. Unexpected requirements: These requirements specify the requirements that are beyond user expectations. These requirements are not requested by the user but if added to the software, they become an additional feature of the software. An example of unexpected requirements is to have word processing software with additional capabilities such as page layout capabilities along with the earlier features.

Surveys

The organization may conduct surveys among various stakeholders by querying about their expectation and requirements from the upcoming system.

Brainstorming

Informal debate is held among various stakeholders and all their inputs are recorded for further requirements analysis.