Methods commonly employed for requirement elicitation

In my last article "A starter's guide to eliciting requirements", I covered what requirement elicitation was and how a business analyst should go about collecting requirements. This article is going to extend on that and work towards various methods employed for requirement elicitation.

BABOK 2.0 mentions the process of requirement elicitation as

Meet with stakeholders to elicit information regarding their needs.

While this sounds like a simplistic task, there are around 9 methods that BABOK details that could be used for this purpose:

1. Brainstorming
2. Document Analysis
3. Focus Group
4. Interface analysis
5. Interviews
6. Observation
7. Prototyping
8. Requirements workshop
9. Survey/Questionnaire

Quick question: Which of these methods have you employed in your experience as a BA? It would be great to know any additional methods that you might have employed when eliciting requirements.

All situations/projects or requirements do not mandate use of all these methods. This often stresses out new BAs as they wonder whether they might be missing out on any requirements by eliminating usage of any of these methods. Believe me, it happened to me quite a few times at the beginning of my career.

What is important to understand is that even though BABOK classifies these methods separately, most BAs tend to use a combination of these methods to elicit requirements. It is indeed almost impossible to use any of these methods as a stand alone measure.

In the past, I have found myself using different approaches depending on projects. For most web application or mobile application development projects, I normally tend to use document analysis, interface analysis, prototyping, and interviews. For more complex projects, I end up using a requirement elicitation meeting which can be termed as a requirement collaboration workshop - a meeting that might stretch for a day or more where all attendees define what the requirements, features, etc. are and sometimes even the technical aspects of project development as well.

On the more SAAS based projects that I have worked on, I prefer to use interviews, document analysis, and observation.

The question is how do you decide which method of elicitation works for you since you cannot possibly employ all these methods when eliciting requirements for a single project. Your company's political structure, historical preferences, your personal strengths and preferences as well as your client's ability to share requirements determine which method would work better for you.

All said and done, whichever method we employ, the key is to ensure that the requirements are clearly understood and documented for all future purposes. However, below are details on some of the more common methods used by most BAs.

1. Prototyping:

A mockup of the application you are developing makes sure that you and your client are aligned on the outcome and you can still change the design while you have time.

This works better for projects where the client might be a more visual person, the focus might be on visual appeal of the product, the product might be a B2C product requiring clear ease of use, or a number of stakeholders might be from varying backgrounds and might want different behavior or outcomes from the application. As a saying goes, users will discover what they want only when they see something that they do not want.

Even though this method can be cost and resource intensive, it clearly outlines that both the customer and the development team/BA are clear on what they are going to develop reducing mistakes and re-development. This also ensures that the product owner/ customer are fully involved in forming the requirements.

2. Brainstorming:

This method allows us to make sure that we enlist as many potential problems as possible by enlisting the help of all involved parties. It also helps the team analyze a lot of information relatively quickly based on each person's expertise, helping the team understand the road-map of development.

This method ideally needs to be done without censoring ideas, and should involved all relevant parties such as SMEs, stakeholders, end users, etc. It is sort of like writing a book where all unfiltered thoughts are first penned down followed by further analysis.

This group discussion, done properly, has the potential to shed light on unknown processes, additional requirements and features, as well as undiscovered problems. In a way, this also reduces the onus on the BA as the unknowns need to be discovered by everyone involved and ensures that stakeholders take ownership of the direction of the project. The information discovered here allows you to decide the future direction of the project.

3. Requirement workshop:

This method ensures that everyone is involved in the process and all the basic requirements are obtained quickly.

This generally requires everyone involved in the project to sit down and work out the requirements. This is an event typically attended by main stakeholders and SMEs for a short period that might last anywhere from one to a few days. The period is dependent on your project and when you feel the requirements might have been completely flushed out. More often than not, stakeholders change their minds and add to requirements after around six months. Change requirement management at this point can be really difficult.

To make this workshop successful, the following items would be required.

• The right participants: All necessary participants such as SMEs, stakeholders, etc. need to be involved. If any important person is not in the meeting, then the workshop might not reach its expected result. What more? It might end up being a colossal waster of time with the SME who missed attending making last minute changes during UAT. While everyone needs to attend this workshop, you would also need to make sure that more than required people are not involved in the meeting. Too many people can slow down the workshop process. The group should gel together in such a way that all stakeholders are comfortable working together and speaking openly & honestly about their requirements.
• Everyone should be on the same page regarding the goal of the workshop, for example: scope, discovering business requirements. Explain some basic use case scenarios so that everyone knows what the current process is.
• Ask open ended questions to figure out the requirements from the end user. Closed ended questions keep your discussion under limits but also prevent you from getting large amounts of information and discovering potential point of failures.
• Document everything using either a scribe or electronic recording.

4. Interviews:

This method is to ensure an in-depth understanding of the actual problems and requirements of the end users without assuming the perceived needs.

Interviews help you understand your SMEs and users. It allows one to perceive the actual requirements and collect them in a relatively short period of time. The results of the interview can depend on the skills of the interviewer. Remember to be persistent when asking questions. Ask the five Ws - Who, What, When, Where and Why. When you cannot ask any more questions, then it means that you have come to the end of requirement elicitation.

Another important thing is to decide whether the interviews need to be structured or unstructured. Some BAs prefer unstructured interviews by asking open ended questions. The interviews need to be unstructured enough to get as many details as possible but structured enough to ensure that all bases are covered.

5. Observation

This will allow BAs to confirm where the project is and where it should be going.

Observation allows the BAs to view what is already existing and enables usage of other requirement tools. Informal use cases provide the highest bang for your buck at this stage as everyone is still trying to get their thoughts around requirements and flush out as many details as possible. It prevents you from getting caught up in the nitty gritty of requirements.

An analyst can also capture requirements through business process models and other diagrams. Since people have the tendency to adjust the way they perform their tasks when being watched, it is important to ensure that people know that you are trying to just observe them and not to judge them. Ask them to explain what they do on a normal day and to allow you to shadow them as they do it. Ask them the pros and cons of the existing processes and systems and explain any workarounds they might be using.

That will be the end of this article. Next week we will look at the various tasks that need to be performed by a BAs and how a BA could increase his/her productivity.

Question: If you have any suggestions on what you would like to read upon, please feel free to add them in the comments section.