Requirement Elicitation: Techniques, Examples [Free Checklist]

Requirement Elicitation Checklist

What is Requirement Elicitation

Requirement elicitation refers to the search for details about the functions to be performed by the system and the limitations under which the system must operate. It is regarded as the process of obtaining data from stakeholders or, in other words, it can be defined as the elicitation process that takes place once the data analytics has interacted with stakeholders to understand their requirements. The goal of requirement elicitation is to thoroughly identify the business needs, risks, and assumptions associated with any given project.

A large number of the company or technical requirements are not reported anywhere as it lies in the minds of stakeholders, through the input from end-users that has yet to be collected, as well as from the analysis of flowcharts and surveys that have yet to be generated. Stakeholders often circulate in the back of their minds with thoughts, wants, or needs, but these may not be obvious, even to themselves. It is therefore the role of the analysts to be logical and comprehensive in drawing these from the stakeholders and assist them to express their vision and their perception of the end product.

Requirement elicitation can be performed by directly communicating with stakeholders or by doing some studies and experiments. The operations can be planned, unplanned, or both. Planned activities for requirement elicitation includes workshops and experiments, meanwhile, unplanned activities are the activity that often happens randomly where prior notice is not needed. For instance, impromptu discussion about the specifications with the client, but with no clear agenda set in advance. There are three common tasks assigned as the part of elicitation which is as followed:

  • Prepare for elicitation: The goal is to consider the nature of the elicitation operation, choose the correct techniques, and prepare for sufficient resources.
  • Conduct Elicitation: The goal is to discover and recognise change-related information.
  • Confirm Elicitation Findings: The information collected in the elicitation session is tested for accuracy in this phase. 

Requirement Elicitation in Software Engineering

In software engineering, requirements are defined as the solution to be developed which includes the features, interfaces, layout, and customer experiences. They are typically conceived by the client or stakeholders who are the individuals involved in the project or impacted by it and are thus interested in its achievement and only through an efficient customer-developer relationship can it be effective. Practical requirements elicitation in software engineering is a section that is essential to every software testing project’s achievement. The analysis of the requirement elicitation is the first phase in software designing.  Requirements from users, developers, and stakeholders for a program are obtained in the requirement elicitation process.

The elicitation of requirements in software engineering is recognised by situational characteristics and information sources. With regards to the situational characteristic, a service provider must know the types of stakeholders (domain expert, not domain expert, homogeneous, heterogeneous), the domain of the system being built (existing system or new system), the complexity of the system, the environment, followed approach as well as the issues. For information sources, a service provider requires knowledge of competitors, technical literature, professional advice, and surveys.

The process of requirement elicitation used the data from all the stakeholders in a complete and detailed manner related to the software development process. Software engineering is a step-by-step procedure and methodology that centres on all areas of software development. A service provider is a person who, according to user requirements, collects requirements for the creation of a programme. To satisfy the necessary criteria, service providers must follow all of the processes critically. The analysis of the requirements elicitation in software engineering is mandatory to verify why the product is necessary. Requirement analysis includes:

  • The assessment of the need for the software development, criteria to validate needs that do not apply to the organization’s business objectives or to the particular issue facing the software
  • Check reliability and completeness without contradictions and feasibility tests according to the budget and program.
  • Via introspection and interviews, the discussion of the requirements stresses the requirements and the discussion of the problematic elements.

Requirement Elicitation Techniques/Methods

The process of requirement elicitation includes the setting of overall organisational goals, the collection and understanding of system background knowledge, the organisation’s knowledge, and the compilation of requirements. There are several requirement elicitation techniques where the effectiveness of the technique implemented depends on the requirement analyst, system developers, users, and the customers where the services are provided. There are also a variety of tools that support a specific technique that have different levels of task automation and assistance. Some of the common requirement elicitation tools that assist the techniques are objective, ART-SCENE, The Requirements Apprentice, ACME/PRIME, AbstFinder, AMORE, and Groupware. Listed below are some of the requirement elicitation techniques that are most commonly integrated:

  • Interviews

This is the most common technique that is used in the elicitation of requirements. In building strong relationships between business analysts and stakeholders, interview techniques may be used where the interviewer directs the question to stakeholders to obtain information. The most commonly used method is a one-to-one interview. A structured interview is an interview session that have a predefined set of questions, meanwhile, an unstructured interview is when the interviewer did not have any predefined questions or a specified format.

  • Brainstorming

This is a technique that is conducted in group for requirement elicitation. It is created to elicit lots of new ideas, therefore providing a forum for exchanging opinions. To manage group bias and group disputes, a highly qualified facilitator is needed. Every concept is recorded so that it can be used by anyone.

  • Surveys/Questionnaires

Survey/Questionnaire is a requirement elicitation technique that allow the analyst to obtain data from a huge sample all at once. Stakeholders are provided a collection of questions to measure their thoughts. Data is analysed to assess the area of interest of stakeholders after collecting the responses. The optimal approach to this strategy is to make a simple Google Form as the requirement elicitation tool, give it to the target people, and decide a due date whenever possible.

Click Here to download 3000+ Project Management Documents: Complete Library of Project Management Templates, Processes, Plans, Checklists, Forms, Tools, Presentation Slides and Infographics. Suitable For All Industries.

  • Document Analysis

Document analysis is an extremely useful form of elicitation of requirements that is commonly used in the IT industry. When introducing an enhancement to a current system, such as an update or change request, this technique is especially important. Document review requires reviewing all the existing documents found by the device processor.

  • Interface Analysis

Analysts investigate who uses the interface during interface analysis, how it operates, and what data it takes. For competitors’ structures, such analysis may also be performed. Analysis of the interface allows one to recognise market rules, future problems, and lack of or unnecessary features that need to be addressed with interested parties.

  • Focus Group

One may get information about a product or service from a group by using a focus group. There are subject matter experts in the Focus group. This group’s study aims to address the subject and provide information. This session is handled by a moderator.

  • Prototyping

Prototyping is used to classify criteria which are incomplete or undefined. In this technique, by designing the prototypes, regular demonstrations are offered to the consumer so that consumers can get an idea of how the product would look. Prototypes may be used to create a mock-up of sites and, using diagrams to explain the process.

  • Stakeholder Analysis

Stakeholders can include members of the team, clients, any person who is involved in the project or can be a supplier. In order to determine the stakeholders that will be impacted by the system, stakeholder analysis is conducted.

  • Laddering

A structural type of dialogue in which a small number of standard questions are addressed to stakeholders. The question series is structured in a hierarchical order, and the performance of this approach depends on the understanding of the domain stakeholders.

  • Quality Function Deployment

Consumer satisfaction is of main priority in this strategy, thereby stressing the conditions that are valuable to the customer. There are three types of requirement which are normal requirements (goals of the proposed software are discussed with the customer), expected requirements (obvious requirements that the customer need not explicitly state them), and exciting requirements (includes features that are beyond customer’s expectations and prove to be very satisfying when present).

Requirement Elicitation Examples

Identifying a list of questions is a vital aspect of planning for the elicitation of requirements. Most of the requirement elicitation examples of the techniques employed by the analysts require a thorough study and analysis of the requirement elicitation questions that were asked to the stakeholders. A common example of conducting requirement elicitation is by distributing a questionnaire that elicits a list of questions related to the requirements/needs. The questions are usually grouped by characteristics (business requirement or project objective). To further refine the understanding, each high-level requirement from the scope document should essentially include a list of questions. Some significant questions must be answered in this process. The requirement elicitation questions are vital in ensuring the optimality of the process, thus these questions must be answered thoroughly and critically. Listed below are the requirement elicitation questions’ examples:

  • System’s functional and non-functional requirement?
  • The steps and process of using the features of the system?
  • The characteristics of the system?
  • Type of stakeholders participating in the system?
  • Does this feature meet the business need and solve the issues?
  • Elaboration of the predicted effects from the process of elicitation?

Steps to Prepare for Requirement Elicitation Session

The preparation for requirement elicitation involves four major steps. The first step is collecting the documentation needed and analyse the current system. Documentation collected in this step often includes the organization’s description (organization’s rules, structure, legal and regulatory requirements.  The documentation collected allows the analyst to analyse the clients’ needs and requirements as well as the current and expected state of the organization. In enhancing the pace of the study especially involving complex documents, subject-matter-expert (SME) who is familiar with the organization, project, and technology will usually be provided by the client.

The second step is analysing stakeholder roles where the analyst will identify all project-affected stakeholders and specifies which of them will be included in the elicitation process. This stage is important to accelerate the process of elicitation, include only appropriate parties in the debate, and notify those impacted by future changes. The RACI (Responsible, Accountable, Consult, and Inform) matrix can be used for efficient communication to define the position of each stakeholder with a table listing different assigned tasks and stakeholders.

The third step can proceed once the stakeholder analysis is conducted. In this step, when discussing with the stakeholders, the business analyst prepares the case and process flow diagrams for use. A graphical representation of a relationship between the actor (a user, programme, or system) and a solution is deemed as a use case diagram. User flow diagrams allow developers to imagine all potential experiences with a solution and select the one that best fits the needs of the consumer.

The final step is preparing the stakeholders for elicitation. During this step, the business analyst will ensure that all of the participants can comprehend the aim and the elicitation process. The preparation comprises choosing the most suitable means of communication with stakeholders, arranging periodic meetings, and determining which stakeholder information is needed. These operations shape the perceptions of elicitation from stakeholders and help to make discussions concise and successful.

What to Include in Requirement Elicitation Checklist

A requirement elicitation checklist is a convenient checklist that assists the analysts in thoroughly analyse the requirements of the stakeholders. It consists of an overview of the entire document which includes the purpose, scope, definitions, acronyms, abbreviations, references, and overview of the stakeholder requests. The Generic Interview is one easy and inexpensive approach that is suitable to be implemented when using the checklist. It assists the analyst to consider the priorities and issues of stakeholders. Equipped with this experience, developers can build apps that suit the real needs of the stakeholder and increase their satisfaction. Listed below are the subsection that needs to be included for the overview of the stakeholders’ requests and how the requirement elicitation template is organized.

  • Establish Stakeholder or User Profile
  • Assessing the Problem
  • Understanding the User Environment
  • Recap for Understanding
  • Analyst’s Inputs on Stakeholder’s Problem (validate or invalidate assumptions)
  • Assessing the Solution (if applicable)
  • Assessing the Opportunity
  • Assessing Reliability, Performance and Support Needs
  • Other Requirements
  • Wrap Up
  • Analyst’s Summary

Click here to download Requirement Elicitation Checklist Template.

Recent Posts