INTRODUCTION

In the digital era, the demand for product and service innovation moves at breakneck speed. Between the technological shift towards machine learning and the mass proliferation of smartphone users, which will reach 3.8 billion by 2021, customers want increasingly better products or services in near-real-time. But, what does “better” actually mean?

Enter requirements elicitation, a structured and detailed method for determining all relevant stakeholders’ definitions of “better.” Requirement elicitation is more than simply asking “what are the most important features in product X?”. Stakeholders frequently have ideas, wants or needs floating in the back of their minds, but these may not be clear, even to themselves. So, it’s the job of requirements elicitor to draw these out of the stakeholders and help them articulate their vision, as well as their understanding of the end product.

WHY IS REQUIREMENT ELICITATION IMPORTANT?

Product development is a cost-intensive process; this holds true whether your goal is as seemingly simple as developing a mobile app or more involved in terms of time and materials such as developing an autonomous vehicle. Moreover, if the end-user has no use for the product, then it will have a high likelihood of failure (or if the autonomous vehicle is poorly constructed, then there are serious risks involved).

Added to the end-user consideration is an increasing number of local, national, and international laws. There are numerous data protection laws throughout the world including the General Data Protection Regulation (GDPR), and newer regulations in the U.S. such as those seen in Colorado and California. Violating these data privacy laws comes with stiff penalties and additional costs that very few enterprises can afford.

Between the high probability of project failure and the quick shifts in consumer demand, along with a myriad of regulations and laws that loom over every industry, requirements elicitation will help you increase project success.

REQUIREMENT ELICITATION STEP BY STEP

These can be tweaked to suit your particular project, but there are a few must-haves such as a business case (which includes a situation statement and the product scope), and a stakeholder register that will organize and detail the who, what, where, when, why, and how of your requirements elicitation system.

Requirement Elicitation Inputs: Before You Begin

You need to know the “what” and the “why” of the product. As such, if you haven’t already done so, and you want to make sure your requirements elicitation is going to produce accurate results, it’s wise for you to clearly identify the need or opportunity for the deployment of a new product/service by creating a business case.

The business case doesn’t need to be a multi-page research paper. It can be as simple as a short statement that contains the current/future/goal state, a description of the problem you’re solving or the opportunity you’re focused on leveraging and a rough draft of a product (or service) development roadmap.

Nothing is set in stone, meaning most products or services (except for major real asset development such as building a home or mass-producing widgets) are developed via iterations. So, the business case is iterative and may shift as your stakeholders reveal aspects of the product that haven’t yet been considered.

Stakeholder Analysis: A Non-Negotiable Input

Stakeholder analysis is crucial since you’ll be communicating with these stakeholders during your requirements elicitation process. Indeed, how else will you know the “who” of the project if you don’t know who your stakeholders are, their level of involvement in the project, and how to contact them? As a general rule, you’ll likely have a relatively standard list of stakeholders that include, but are not limited to:

• Sponsor or product owner
• Customer, client, SMEs
• End users (can be the same as the customer/client/SMEs)
• Project manager
• Solution team, technical team members who will be providing information such as the feasibility of the solution, potential costs, time (time, scope, cost)
• Legal: compliance adherence

Creating a Stakeholder Register doesn’t need to be arduous. Creating a simple spreadsheet will suffice and should have, at the very least, the following information:

• Name
• Role (e.g., SME, engineer, etc.)
• Contact information (e.g., email address, phone number, Skype or other video conference/VoIP tool, etc.)
• Initial Product Expectations (if available)
• Interest Level (can be colour-coded in reference to High, Medium, Low)
• Influence Level (same as above; some stakeholders will have more influence than others)
• Preferred Communication Channels

You can continue to use the spreadsheet format and expand upon it to incorporate useful information for future elicitation. This could include elicitation techniques you used that yielded the most stakeholder information, or your analysis of stakeholder responses during the requirements elicitation process.

Learn how QVscribe can transform your design process.

Download a PDF copy of this guide.

YOUR REQUIREMENT ELICITATION PROCESS

Keep the information within a collaboration tool for greater transparency. If you used a spreadsheet for your stakeholder register, then make sure everyone who is performing the requirements elicitation has access so they can quickly update the information.

Step 1: Choose the Optimal Elicitation Approach

You may not know which approach to use with each stakeholder unless you’ve worked with that stakeholder before. If this is the case, then start planning at a high level by considering the most common elicitation tools and techniques:

• Brainstorming: create a list of ideas using words and/or pictures.
• Interviews: formal or informal, in person or virtually.
• Document Analysis: review any recent documentation, schematics, lessons learned from prior projects that are similar to the current one, etc.
• Surveys or Questionnaires: SurveyMonkey or other automated (and easy to use) digital surveys can streamline the administration of surveys or questionnaires; you’ll need to be judicious about how you phrase your questions and the types of responses that will collect the right information, e.g., open-ended vs. closed-ended questions, etc.
• Workshops or Focus Groups: if you need input from SMEs or end-users in the same department or a cluster of targeted consumers that share similar end-user characteristics, then this may be the best choice.
• Prototyping: humans are heavily reliant on visual inputs, so creating a picture, model, or mock-up of the product is a great elicitation tool.
• Observation: if you have a prototype or mockup, you can observe the stakeholders using the product, and then ask clarifying questions.

By no means are you locked into using one type of tool or technique for a stakeholder or group of stakeholders during your elicitation session. You can read the guide to the 2020 Engineering Tool Stack here. If you’re interviewing an SME on a one-to-one basis, you can collaboratively brainstorm, review documents (with several questions you’ve generated after your initial document analysis) and send them a follow-up survey. You can do the same for workshops or focus groups.

Once you have your tools list, you can further refine and define your approach by generating a document that answers the following questions:

• What information are you eliciting?
• Where can you find the information (or from who)?
• Which method is best for obtaining the information based on the stakeholder analysis and elicitation tools available?
• When is the best time to conduct the elicitation sessions (also based on your answers to the prior questions)?

Step 2: Elicitation Preparation

It’s time to develop your elicitation plan. If your project is small, this will be a quick process. Larger projects are, of course, going to exponentially consume much more time as more stakeholders are involved. Your elicitation approach and any product requirements information you currently have are going to be monumental for ensuring that this step is efficient and completed correctly (the first time). While you can utilize a set of informal notes you should, at a minimum, have established:

• An objective for elicitation activities
• The specific participants
• The resources or other supporting materials needed during the elicitation activities
• A predetermined set of questions and how stakeholder responses are to be recorded
• An agenda with definitive start and end times

STEP 3: CONDUCT THE ELICITATION

After following the above steps, you’re well prepared for conducting the elicitation process. This doesn’t mean that surprises won’t occur human behaviour has unpredictable quality. But, preparation does help to significantly reduce potential blunders like forgetting to bring the prototype to a focus group (hint: always have a backup plan).

Elicitation activities have four stages:

1. Introduction: You set the stage by introducing the purpose and goals of the elicitation activity: establish the tone of the interaction, discussion of activities, timing, etc.
2. Body: Depending on which tool or technique you chose, the body will differ. For example, if you’re interviewing a stakeholder, you’ll likely launch into your questions or if you’re conducting a workshop, you’ll transition the group into the scheduled activity. Questions may arise organically throughout the interaction. Take detailed notes even if you have a post-activity questionnaire or survey prepared.
3. Close: The transition to elicitation activity closure can be a smooth one if you’ve kept an eye on the time in relation to the flow of the activity. Some elicitors will mention that the end time is near to signal the close process, others may ask closing questions, e.g., “Do you have any questions”, “Is there any information you think is important about the product that we didn’t discuss?”, etc. Definitely ask if the stakeholder is open to follow up questions, new ones may surface as you analyze the elicitation results.
4. Follow-up: This step isn’t always needed, but can prove to be extremely useful. Some stakeholders may be short on time for the initial interview, brainstorm session, etc. Follow-ups provide you with the opportunity to ask clarifying questions and ensure that the information you did record is accurate.

Once all of your elicitation activities are completed, and you’ve gathered all of the data/information into some sort of repository (this can be digital as well as an aggregation of handwritten notes, drawings, etc.) your next step is to analyze everything you’ve collected.

Step 4: Analyze Elicitation Results

Analysis can be as straightforward as reading through your notes and other documents then summarizing them. Using Natural Language Processing (NLP) is an algorithmic method for identifying keywords and ideas that were derived from stakeholder elicitation activities. QVscribe uses NLP to analyze requirements for quality and consistency to catch errors before they turn into late-stage rework.

If you used a prototype where user behaviour was tracked, then this quantitative data can be analyzed in conjunction with surveys or qualitative information sources used during the elicitation process. Your analysis approach is going to be unique to your project and any enterprise requirements in terms of reporting, which brings us to the final output for requirements elicitation.

REQUIREMENT ELICITATION OUTPUT: YOUR RESULTS

Some enterprises may require a full report that details your requirements elicitation methods and findings. Others may simply want a spreadsheet that gives a summary of the aforementioned who, what, when, where, why and how along with a ranking of the requirements by the most influential stakeholder requirements vs. the least influential. For major projects, you may go through several elicitation iterations. Even after the product is launched, more elicitation may be needed.

As stated above, each project is going to require a variation of the elicitation process described in this guide. Certainly, plans can go awry, and they often do. But, establishing a system for gathering requirements is the best way to ensure that you understand how to create and implement the best product for your end-users as quickly and as efficiently as possible given the available time and resources.

THINKING AHEAD

Throughout the elicitation process, it’s important to keep in mind that the final requirements need to be clear, concise and compliant. For example, avoid the use of vague or ambiguous terminology. This will become more important as the requirements mature, but clear communication from the start will prevent wasted time and confusion later on. By remembering this goal while gathering requirements, you set yourself up for a smoother overall project.

You can ensure requirement quality by assessing requirement clarity and consistency along the way. Once your requirements have been established and documented, use QVscribe to ensure they are up to par for those that will be authoring and/or reviewing them. Qvscribe will ensure your requirements are concise and unambiguous and ensure you are following requirements best practices.

Learn how QVscribe can transform your design process.

Download a PDF copy of this guide.