Photo by Christina @ wocintechchat.com on Unsplash. This article is originally published on dev.to on 14 Feb 2021.
When we have a project to develop a system, we would be gathering requirements before diving into feasibility study. Whether it is for a client or for ourselves.
Assuming we have received an email from an education provider saying that they are looking to develop their own application system and asking if we can develop them. The first thing we want to know is if that's feasible to develop, so we sent them back an email to schedule a meeting in several days.
At this point, let's say we already have some ideas on the outline of the system and get excited about the project. Probably, we'll be saying in our mind, "Oh, maybe we can use the new technology that is popular these days." or "Perfect! This is a great opportunity to use the programming languages that we've been interested in".
So, what will we do in the first meeting? Will we tell them about our ideas and what we are capable of?
Not quite. That's actually what we should avoid doing. What we must to do is to focus on being an active listener and gather all the information including underlying needs. Requirements gathering techniques will help us achieve it.
But why do we have to do that? Why not jump into the feasibility study right away?
Reasons for running requirement gathering
There are many reasons that we need to allocate time for gathering requirements.
1. Help to discover important requirements that could influence the development cycle.
Imagine we decided to start designing the online application system for the education provider mentioned earlier. The head of the organization told us to implement specific functionalities, so we simply implemented them.
But what if she/he didn't understand what the senior management team really needs? What if we discover that the system is being used mostly by the management team, then we need to align the project with the management team's need after deployment?
It's not always the case that essential requirements are always evident and visible, that's why we need to take time to gather requirements from all users.
2. Solve possible misinformation or misconception
We, humans, are not perfect. Especially when it comes to understanding others, it requires certain skills and techniques.
As English is not my first language, I often find myself misunderstanding what others really meant more often than when I communicate with others in Japanese. So, at least to me, when misunderstanding each other, we have a different definition of certain words in mind.
This is applicable especially in the IT field where you communicate with people who do not have the same understanding of technology.
Assuming we are aiming to create a sensible system for their business, then it's not for ourselves, therefore we need to avoid misunderstanding what the client means at all cost by having jargon-free conversations.
Because small things add up to a big difference.
3. Put their mind to the systems development.
It is important the client feel they are heard and understand that their involvement and voices are crucial for the successful project.
For instance, if we talk too much about our vision or explaining about new technologies instead of listening to the client, they are more likely to feel that their opinions are not in the highest priority, or they may conclude that they don't need to put their mind to it because we sound like knowing enough about the project.
Requirement gathering techniques can help us to avoid deepening the gap between the client and the development team's perspective and motivation.
To sum up, the effect of gathering requirements should not be underestimated and the techniques should be learned and used effectively.
Technique 0: Preparation
Now we will discuss the techniques useful for the meetings and interviews. The first thing is preparation.
What we do here is to research the client as much as possible. When you think about an interviewer you believe they are highly skilled, you may surprise how much they have given research about the interviewee. If I were to be interviewed by them, I would be more open-minded to answer questions.
To achieve the same effect on our client, we could gather information online but recommended to review documents if they are available from the client.
What we aim here is to examine:
- Company's objectives and goals
- Organization structure
- Their information systems
Getting ideas about these topics will enable us to identify what kind of questions we should ask the specific person.
After the research, interview questions can be listed and organized carefully, so the questions are complete and can be answered without confusion.
Technique 1: Open-Ended Questions
Open-Ended questions let the interviewee talk about the topic freely rather than providing a specific answer. For instance, questions such as "What are your reactions to the current/new online application system?" can be one of them.
This style of questions is especially helpful if we want to delve into the topic and look into the underlying issues.
Technique 2: Closed Questions
Closed questions, on the other hand, is the way to clarify the ideas and specific answers. Questions can be answered with "Yes/No", "Agree/Disagree" or specific numbers.
For example, "Do you agree or disagree that the current system is obstructing your productivity?" can lead the interviewee to one of the other answers.
We can also alter the above question to be more specific, by asking "What specifically is the problem on the current system that is obstructing your productivity?".
This can be altered depending on how much you already asked or understand the interviewee's perspective about the topic.
Disadvantages of Open-Ended and Closed questions
There are possible disadvantages if we use only one of the other style of the question mentioned above.
If Open-Ended questions make up the majority of the questions, it is harder for us to control the interview. Moreover, we may not be able to obtain a sufficient amount of information compared to the time we spent on the interview.
Oppositely, only asking closed questions may fail to take out detailed information because they could answer single word if we don't delve into it.
As far as I imagine, it's rare to be using only closed questions in a real conversation, so most of us use mixed styles or open-ended style only.
Technique 3: Pyramid Structure
In order to prevent falling into a vicious cycle of interviews or meetings, we need to organize the order of questions depending on who we are interviewing.
Pyramid Structure is one way to organize them. Under this method, the sequence of questions starts from very detailed, often closed type. And then we can gradually broaden the topics.
If the interviewee is the lower-level users in the current system, then they might need this structure of questions to warm up to the topic.
A good example is questionnaires, where the level of understanding about the topic may not be the same among respondents.
Technique 4: Funnel Structure
Not like the Pyramid, Funnel Structure can start with general questions and gradually narrow the topics, and conclude with the closed type of questions.
This method is especially effective for an interviewee who could have deliberated the topics already. It's likely that the person you see at the first meeting has clear opinions about the topic already, so it might be a good idea to structure questions funnel style.
Technique 5: Modelling
Because the requirements can be complicated, it is often difficult to see each component and relationships in a big picture. Especially for the client, it can be challenging.
Modelling is a diagrammatic way of representing system components enabling us to study the requirements intuitively.
UML (Unified Modeling Language) is a common way to create many styles of diagrams in a clear manner. The above image is called Use Case Diagram, which can be created to clarify how different types of users interact with the system.
In other words, we can summerise the information we collected during the interview by creating diagrams. When it's done, It can be investigated by clients and the development team.
Conclusion
Requirement gathering techniques are mostly about active listening skills, and how we could align perspectives of the client and ourselves. This can be challenging.
But if we could cover all of the mentioned above, we would be more confident about what we are doing, getting trust from the client while creating a solid base to build a successful project on top of it.
Resources
Open-Ended and Closed Type Interview Questions
All You Need to Know About UML Diagrams: Types and 5+ Examples
