Determine feasibility of requirements
Throughout the process of collecting requirements, you should always ensure that requirements are feasible. As you perform the fit gap analysis and a review each of the requirements, it's a good time to double check the feasibility. When the information was originally captured, you likely didn't have the benefit of other details that might make a requirement less feasible. Determining that a requirement has feasibility challenges should result in it being reevaluated with the subject matter experts or possibly deprioritized.
Determine if people will use the feature
After becoming acquainted with the users, you should consider whether the requirement will result in the creation of a feature that they'll actually use. For example, the feature might be an automated process that is too automated and results in too much rework for common scenarios. Another scenario could involve a feature that, while it might solve the problem, is solved by an overly complex solution.
Assess if the feature is technically feasible
The notion that if you don't ask for something, you won't receive it is true. That idea is true of requirements, too. However, users often envision and request elaborate solutions to their challenges. As you examine each requirement, you should assess whether the users' solution request fits with the current technologies that they have available. Additionally, you should evaluate if the solution that you are building is consistent with how their platform is designed to work, or if you are pushing beyond the normal limits to appease your customer's elaborate expectations. For example, if the volume of requests is high, you might run the risk of overrunning the API limits for protecting the platform; therefore, implementing the solution as planned would not be feasible.
Evaluate if the process is feasible or overlooked
As you review the requirements, they might clearly highlight a business process such as resolving new cases or a sales process. Having clear insight is excellent for those processes that you need only validate whether they are reasonable and implementable or not. However, you should ensure that you've covered exceptions that regularly occur. Scenarios also happen where 10 requirements didn't individually identify a process, but while you are evaluating them as a whole, a business process unexpectedly becomes more identifiable.
Verify if regulatory rules/laws make a requirement not feasible
If you're working in a regulated industry, make sure that you verify requirements
with a knowledgeable expert on what is allowed and not allowed. When collecting ideas, it is
easy to become enthusiastic about a requirement, only to
later realize that the requirement isn't feasible because it conflicts with a
regulatory rule or law.
As you complete collecting requirements, it is the ideal time to reflect on the full set of requirements and ensure that they are feasible as you work through your fit gap analysis or design the solution from the requirements.