Requirement Elicitation - "Evaluating Requirements"

Hi guys, welcome to the next installment in our requirement elicitation series! In parts 1 and 2, I talked about a few approaches to gathering requirements. Today, I'll introduce the next step, which is what you'll need to do immediately after those two steps: evaluate the requirements.

Why Evaluate Requirements?

The reason is simple: not every requirement that stakeholders (clients or other involved parties) provide is usable. Their opinions are often subjective, based on personal experience, and may or may not bring value to your project. This is where you need to filter and identify the truly useful information.

Evaluating Requirements During Stakeholder Meetings

Uncover the real purpose behind the requested feature. Gathering requirements isn't just about asking questions and recording the information received. By asking "What is the purpose of this feature?", you can identify the usage goals and assess whether the feature requested by the client is the best solution. This also allows you to suggest better solutions (if available) to address the actual problem.

Example:

• The client requests an approval workflow for creating new accounts. After investigating, you learn that the purpose is to prevent spam accounts from being created on the system.
• For this issue, you can suggest to the client that using SMS OTP to verify new accounts would be much simpler. If the client is concerned about the cost of a third-party SMS OTP service, you can further suggest verifying users via email and explain that while email verification is not as secure as phone verification, it doesn't incur any costs.

Provide an initial assessment for each requirement.

Preliminary requirement evaluation is usually not for newcomers with limited experience. However, that doesn't mean you can't do it. There are many requirements that sound quite unreasonable from the get-go. And obviously, for those requirements, you can absolutely ask questions and offer advice to the client.

Evaluating requirements often stems from questions like:

• Is the requirement feasible?
• If so, will it take a lot of time?
• If the requirement is necessary but too time-consuming and effort-intensive to develop, are there any alternatives?

Example:

• The client wants to apply IoT to track drivers' travel distances and use AI to analyze the data to optimize routes based on cargo and weather conditions. -> This is too complex and convoluted.
• Advise the client to break down the request into smaller requirements, such as:
  • Implement vehicle tracking using IoT.
  • Collect and store tracking data, apply AI...

You should prioritize each requirement and proceed step-by-step.

Filtering Information

If you've read my second post, you'll remember that BAs should take notes during meetings (Minutes of Meeting). During the meeting, you usually won't have enough time to categorize what to keep and what to discard. Therefore, your notes after the meeting will likely be a jumbled mess. This is when you should filter the recorded information:

• Is the information relevant to the meeting content?
• If not, is the information within the project scope?
• Does the information affect previously collected information?
  • If so, how? If there is conflicting information, who needs to be consulted for clarification?
• Is the information provided by the client clear enough? If not, who needs to be asked for clarification?

After answering all of these questions, you'll probably have another list of questions and concerns to revisit from part 1 of this series. Keep going until you have clearly verified information that falls within the development scope. This is where we'll begin the next part of the Requirement Management Life Cycle.