Learn to Elicit Requirements.

Requirements elicitation refers to the gathering of requirements from a person or a group of people. The term is generally used in the context of a software system. However, the process remains the same whether the requirements are for a system or for a process.

To elaborate, imagine you’re being asked to carry out a data analysis project or machine learning. Before you can figure out how to tackle the problem, you need to elicit the requirements.

Though this process seems like it should be straightforward, it’s often characterised as a form of art. Understanding the problem can be tricky.

Understanding the Problem

One of the most important aspects of problem-solving is understanding the problem. This is harder than it sounds. Sometimes you’ll be working on your own problems, other times on other people’s problems.

In either case, it is imperative that you take the time to understand the problem. Pay attention to the underlying causes — the aim is to address the underlying issue, not just treat the symptoms! To do this, it generally takes at least three meetings with the individual(s) you are attempting to help solve the problem.

“A problem well stated is a problem half solved.” — John Dewey

Clarify, Verify, Repeat

The first meeting is an introduction to the problem. Be inquisitive, listen carefully to what you are being told.

How you are being told certain details is just as important as what you are being told. 60%-70% of human communication is nonverbal.

Once you have gathered all the information you can at the first meeting, take your time to review, research and understand the situation. This lets you go back with follow up questions to verify your understanding of the problem at the second meeting.

The third meeting will close out any outstanding items and verify that your understanding of the problem and the situation is exactly as you think it is.

Ask Questions

Generally speaking, people are as helpful as they can be. In their attempt to be helpful, they often mask the underlying problem you’re asking them to describe. Rather than highlighting the problem in question, they are prescribing their understanding of how to solve the problem.

Let’s look at an example. Imagine that you’re interviewing a user about a problem they’re facing, and they say they need an email with the day’s sales. If they were to receive this email at 16:00, then they will be good to go. Easy — just write a program that pulls this information and emails it to them.

Unfortunately, you only treated the symptom, not the underlying problem. When probed, the user describes that with the information received in the email, they can check whether any new customers appear. If they do, they’ll set them up in the system. Bingo! What the user actually wants is the ability to set up new customers in the system. This opens up a world of possibilities: maybe the whole process can be automated without any user input.

A good technique to get to the root cause of the problem, is to ask Why.

Pareto Analysis

Pareto Analysis is a tool that applies the Pareto principle to your favour. The Pareto Principle states that 80% of effects comes from 20% of causes. In other words, there exists such combination of requirements that by only implementing 20% of them, you can get as much as 80% function.

The Pareto Analysis, refers to the work done to identify this core 20% of requirements.