Improve requirements
Ideally, all requirements would be perfect and implementable, but the reality is that some will need refining, consolidating, or removing so that you'll have a solid set of requirements. By evaluating each requirement, you can look for areas of improvement.
As you evaluate, consider asking yourself the following questions:
Are the requirements clear and complete?
Do gaps exist that you know will need to be addressed but aren't captured in requirements?
Have all regulatory and compliance needs been included?
Is this requirement a duplicate of another, and should it be consolidated?
Does the requirement include components that are out of scope?
Does the requirement include specific design/implementation?
Does the requirement specify how the legacy system handled the problem, not the actual business problem?
Requirements are intended for explaining the problem that needs to be solved, not how to solve it. Solving the problem happens by examining all requirements and mapping them to a solution as part of the design process. Users who provide the requirements shouldn't need to know how the problem will be solved when they provide input on a requirement.
Example - includes design specifics
This example describes a requirement that includes design specifics.
The customer account manager will be notified by email from a Microsoft Power Automate flow that's triggered on the creation of a new case in Dynamics 365 when they're the owner of the account row in Microsoft Dataverse.
This requirement could have been more simply stated as: As a customer account manager, I want to be notified when my customer has opened a new case.
When possible, try to bring a requirement back to what, who, and why and avoid including how it will be done in the new solution. By elevating the discussion to the business need, you'll get a clearer understanding of the problem that needs to be solved. In many cases, a better way might be available for implementing the requirement than how it was done in the legacy system.
Example - missing details
This example describes a requirement that's missing details.
Accounts won't have a high credit limit during their first year as a customer.
As written, this requirement's not implementable because you don't know what the limit is and what is considered high. Also, this aspect would make the requirement not testable. The real requirement for a limit could be as simple as a hard value of $2 million, or it could be more complex, such as a limit for each region. The latter makes the overall complexity of the requirement higher. While this example is simple, imagine that if it was a more complex requirement, not having good clarity can affect the project scope and resources.