Requirements Elicitation or requirements capture or requirements acquisition

Requirements elicitation (also known as requirements capture and requirements acquisition) is a process of collecting information about software requirementsfrom different individuals such as users and other stakeholders. Stakeholders areindividuals who are affected by the system, directly or indirectly. They includeproject mangers, marketing personnel, consultants, software engineers,maintenance engineers, and the user.

Various issues may arise during requirements elicitation and may cause difficulties in understanding the software requirements. Some of the problems are listed below.

1. Problems of scope: This problem arises when the boundary of software (that is, scope) is not defined properly. Due to this, it becomes difficult to identify objectives as well as functions and features to be included in the software.
2. Problems of understanding: This problem arises when users are not certain about their requirements and thus are unable to express what they require in the software and which requirements are feasible. This problem also arises when users have no or little knowledge of the problem domain and are unable to understand the limitations of the computing environment of the software.
3. Problems of volatility: This problem arises when requirements change over time.
4. Requirements elicitation uses elicitation techniques, which facilitate software engineers to understand user requirements and software requirements needed to develop the proposed software.

Elicitation Techniques

Various elicitation techniques are used to identify the problem, determine its solution, and identify different approaches for the solution. These techniques also help the stakeholders to clearly express their requirements by stating all the important information. The commonly followed elicitation techniques are listed below.

1. Interviews: These are conventional ways of eliciting requirements, which help software engineers, users, and the software development team to understand the problem and suggest solutions for it. For this, the software engineer interviews the users with a series of questions. When an interview is conducted, rules are established for users and other stakeholders. In addition, an agenda is prepared before conducting interviews, which includes the important points (related to software) to be discussed among users and other stakeholders. An effective interview should have the following characteristics.
2. Individuals involved in interviews should be able to accept new ideas. Also, they should focus on listening to the views of stakeholders related to requirements and avoid biased views.
3. Interviews should be conducted in a defined context to requirements rather than in general terms. For this, users should start with a question or a requirements proposal.
4. Scenarios: These are descriptions of a sequence of events, which help to determine possible future outcomes before 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.
5. Description of what users expect when the scenario starts
6. Description of how to handle the situation when the software is not functioning properly
7. Description of the state of the software when the scenario ends.
8. Questionnaire: Questionnaire is an effective tool of gathering requirements and produces a written document. The major advantage of questionnaire is that it requires less effort and gathers information from many users in a very short time. In this method, preparing right and effective questionnaires is the critical issue. This is because different users work with different parts of the system, and have knowledge of that part only. Thus, a single questionnaire is not appropriate for all the users. The analyst must prepare different sets of questionnaires for different group of users. He should consider various issues while preparing questionnaires like the length of questionnaires, whether to ask close-ended or open-ended questions, and so on. Once the questionnaires are prepared, they are distributed to the users. In this method, users get sufficient time, which enables them to give correct answers of the queries.
9. 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. Site visit enables the analyst to observe the current system, which helps him to detect the problems of existing system.
10. 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.
11. 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.
12. 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.
13. 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.
14. 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.