User:22CB/Requirements elicitation

Requirements elicitation is a process in requirements engineering during which candidate requirements of a system are acquired in collaboration with system users and stakeholders.

The aim of requirements elicitation is to explore the problem world and to gain information on the improvement objectives of the system, the technical and organizational constraints, domain properties and the evolution of technologies and market conditions that can influence the workings of the system. The requirements elicitation process includes highly communicative activities which allow for communication, prioritization, negotiation and collaboration with relevant stakeholders. Requirements are spread across many sources such as problem owners, stakeholders, system documentation and other existing systems. To elicit these requirements various techniques are adopted depending on the project. Different techniques are suitable for different goals in elicitation. Whereas one technique might improve communication, another might be suitable for gathering information about a system. Some techniques used in requirements elicitation are interviews, questionnaires, domain analysis, task analysis, group work, brainstorming, focus groups, prototyping, scenarios, ethnography and observation.



Requirements elicitation is an iterative process which takes place in the beginning of the requirements engineering process. After the requirements elicitation process has been undergone and a set of candidate requirements have been acquired, the requirements undergo requirement prioritization, during which they are evaluated and negotiated.

What makes requirements elicitation challenging is the gap between the knowledge stakeholders have of the system and the knowledge of the developers. Requirements are elicited rather than gathered because the stakeholders do not always know what the system needs or how to communicate their needs to the developers. It is the task of the requirements analyst during the requirements elicitation to bridge the gap between the stakeholders and the developers. Requirements elicitation builds a common understanding of the system and its problems between stakeholders and developers by quantifying and clarifying the underlying assumptions and goals of the stakeholder and communicating those to the developers. The requirements analyst is responsible for communicating, facilitating, mediating and documenting information. The requirements analyst is neutral when resolving conflict between stakeholders.

Guidelines
In 2022, the International Requirements Engineering Board (IREB) described a set of guidelines for the elicitation process. They define two different phases of the elicitation process. The set-up phase is the first phase of the elicitation process. During this phase, an overview of the system-as-is is acquired. The system-as-is refers to the system as it currently exists. Moreover, the objective of the elicitation is determined and a planning is made according to specifics of the system-as-is and the objective. The second phase is the execution phase. In this phase, the planning made in the set-up phase is executed and adjustments are made to the plan accordingly.

Guidelines for the set-up phase
The set-up phase contains the initial set of activities in the requirements elicitation process. During this phase the specific characteristics of a project and the existing knowledge and assumptions of the project participants form the basis for defining the intended approach of the elicitation.


 * 1) Get an overview of the project situation and the business case. It is vital to have a clear understanding of the domain which the project is part of. Different domains have different technologies, working processes and problems, which all influence the project. This information is obtained by talking to domain experts and to the stakeholders. It is also necessary to understand the history of the project, why it was initiated and what the project constraints are. This information can be obtained by talking to the people involved in the project.
 * 2) Determine elicitation objective. Determining the elicitation objectives is done at the beginning of the elicitation process as the objectives will guide the process. The objectives are also important to know when deciding what elicitation techniques to know, as different techniques will result in different results.
 * 3) Plan for the systematic analysis of the system context. As it is essential to have a clear understanding of the system context for requirements elicitation, various things must be identified. Requirements can be elicited from various sources. Early in the elicitation process the relevant stakeholders should be determined. The project sponsor is usually the most important stakeholder. However, in some cases the users of a system may be the most important. Other parties who have a stake in the project or exert influence over any part of the system should also be regarded as stakeholders. Stakeholders are the most prominent source for requirements and the information they provide may be supplied by system users and domain experts. The existing systems and the corresponding documentation and processes may also be used as a source for eliciting requirements.
 * 4) Plan for the systematic and pragmatic identification of (multiple types of) requirements sources. Requirements sources for elicitation activities must be named so that the activities are executable. It is also important to have an understanding of the culture and structure of the organization that is undertaking the project. The political, organizational and social aspects related to the system need to be thoroughly explored.
 * 5) Consider relevant process patterns to define the activities. The elicitation techniques and methods that will be used for this project are to be determined. The techniques and tools employed in the elicitation process must be selected thoughtfully, since it can determine the success of the elicitation. Which techniques and tools should be used depend on the type of project and the skill of the analyst. The amount of time they would take and the resources that are available should also be taken into account. Requirements elicitation is best performed with a combination of various complementary techniques.
 * 6) Allow time and budget for resolution activities. Stakeholders can be uncooperative or have conflicting priorities with other stakeholders, which can cause conflict. If these conflicts are found early, more time can be dedicated to resolving them.

Guidelines for the execution phase
The plan which has been made in the set-up phase will be executed in the execution phase. After each activity, the plan should be reflected on and adjusted according to the new information acquired during the activity. Conflicts should be resolved during this phase.


 * 1) Consider elicitation activities as time-boxed activities Every elicitation activity should produce valuable information, so as not to waste time and resources. If every activity is considered time-boxed, meaning every activity adds information to the requirements iteratively and incrementally, it will make the elicitation process more efficient. If an activity does not perform as expected, it can be stopped and the reason for it under performing can be examined. On the basis of this examination new activities can be planned.
 * 2) Question the plan after each activity As the elicitation process progresses, the knowledge that is acquired of the project increases. After every activity the plan should be revised to accommodate the newly obtained knowledge. Previously defined objectives can be rendered irrelevant, new objectives can be created, requirements conflicts can arise or more suitable activities can be found.
 * 3) Schedule defensively and make use of short and long-term elicitation activities. The sequence in which elicitation activities are performed matters. The activities should be scheduled according to the availability of stakeholders/requirement sources, the availability of the requirements analysts and the value to the project. Activities that bring more value to the project are to be prioritized over those that bring low value to the project.
 * 4) Incorporate slack to leave time for creativity, conflict resolution and unexpected events. Projects are often uncertain and not everything can be accounted for in the set-up phase. Incorporating extra time in the elicitation process will allow for unexpected conflicts to be resolved, unforeseen delays to be dealt with, or creative activities to be executed.
 * 5) Parallelize independent activities. When activities are independent from each other, it is efficient to execute them consecutively to save time. However, parallelized activities should be coordinated regularly, otherwise hidden dependencies might be overlooked.
 * 6) Combine elicitation activities that address the same requirements source. Elicitation activities which require the same requirements source can be combined for efficiency.
 * 7) Search for conflicts and react to them according to an agreed strategy. The consistency of the requirements and information acquired throughout the elicitation process should continuously be checked. This can help detect conflict early and allow for resolution.

Common pitfalls
In 2005, Zowghi and Coulin identified several pitfalls in requirements elicitation.
 * Process and project: Projects are usually complex and depend on many factors in the real world, which is dynamic. Requirements are susceptible to change and must take into account many variables and the interaction between those variables. This can make requirements elicitation quite a challenge. No project is the same, thus there is no single procedure or technique with which every project can be approached.
 * Communication and understanding: Stakeholders may have difficulty articulating their requirements. Sometimes stakeholders and analysts fail to understand each other. Matters that are important to the stakeholder could be overlooked by the analyst. Analysts could fail to understand or misinterpret domain-specific jargon. There are many such things that could go wrong during communication.
 * Quality of requirements: The requirements elicited may not be defined clearly, vague, unfeasible, impossible to validate, inconsistent, incomplete or incorrect. Requirements maybe be at odds with other requirements, contradict itself, or not accurately reflect what the requirement is meant to be. Requirements may contain subjective phrasing, which makes it impossible to validate the requirement. Requirements may also fail to specify what components or what facet of a system it is about.
 * Conflict between stakeholders: Stakeholders may not agree with each other or have different priorities which could be in conflict with each other. Conflict between stakeholders can make it difficult to settle on a set of requirements.

Approaches and techniques
In 2005, Zowghi and Coulin discussed several approaches and techniques for requirements elicitation. A distinction is made between the terms 'approach' and 'technique'. An approach consists of actions that are executed in systematic steps to solve a problem or situation, while a technique is a practical method to perform a certain task. In addition, a substantial level of expertise and skill are needed to perform the approaches properly and to effectively communicate with the stakeholders. Which approach is the most suitable usually depends on the situation, such as elicitation phase, preference and experience of the requirement analyst. Other factors, like the quality of the elicited requirements, the system context and the level of stakeholder agreement should be taken into account as well. In other words, which elicitation technique is selected remains a subjective decision. Consequently, the results of the elicitation may be biased.

Structured interviews appear to be the most effective technique, since requirements analysts are able to gather more information through this technique compared to others. Yet, contemporary research indicates that this technique might be inadequate nowadays, since it depends on the stakeholder's teaching ability to transfer their knowledge to the requirements analyst, and less on their mastery of their job. Thus, complementary techniques such as observing the stakeholders in their work environment could be beneficial as well, since it could reveal issues that are otherwise not captured via interviews.

In 2018, Pacheco et al. conducted a systematic literature review and brought the most widely used techniques under the following classification. These can be found in the table below.

Complementary and alternative approaches
The goal of using complementary approaches is to evoke creativity and flexibility by combining multiple techniques to obtain the best possible results. Other reasons to use alternative approaches can be that the requirements analyst is not comfortable with a selected technique and therefore wishes to use multiple techniques combined, or when the results of a selected technique turn out to be less useful than expected. An example of approaches that could complement each other are domain analysis and interviews. That is, a domain analysis could be combined with an interview, where the requirements analyst could validate the results of the domain analysis by asking follow-up questions. Another example of approaches that could serve as alternatives for each other are observations and scenarios. The natural work environment of the user might be too dangerous for observation. In that case, scenarios could be used to elicit the requirements.

In 2009, Alexander and Beus-Dukic proposed a set of complementary approaches for discovering requirements:


 * Identifying stakeholders
 * Modeling goals
 * Modeling context
 * Discovering scenarios (or use cases)
 * Discovering "qualities and constraints" (non-functional requirements)
 * Modeling rationale and assumptions
 * Writing definitions of terms
 * Analyzing measurements (acceptance criteria)
 * Analyzing priorities

Alexander and Beus-Dukic suggested that these approaches could be conducted with individuals (as in interviews), with groups (as in focused meetings known as workshops, or via electronic meeting systems), or from "things" (artifacts) such as prototypes.

In 2014, Carrizo et al. proposed a systematic way of selecting techniques.


 * Determine the context of the situation
 * Determine to which degree a technique fits the situation
 * Create a "session plan": select one or more techniques and prioritize them according to their adequacy

Supporting tools
Tools are implementations, for instance pieces of software or artifacts, that are used in requirements elicitation. They offer the opportunity to work with requirements in a more systematic and formalized manner. In general, tools are owned and maintained by their vendors, as they are often targeted at specific environments and niche markets, development processes or application settings. There exists a wide variety in the capabilities of the tools. Categorization examples are "Requirements Organization", "Traceability Support" and "Collaboration, Workflow and Management". Examples of tool applications are templates, like the ISO-IEC-IEEE 29148-2018 standard and the Volere Requirements Specification Template. Examples of management tools are CaliberRM, IBM Rational RequisitePro, IBM Doors Next, and Jira.