Strong requirements lead to strong solutions. What are strong requirements? Strong requirements can be defined as the documented details of a customer request that provide readers a request from the customer point of view.
While weak requirements can be defined as documented details of a customer request that do not provide the reader a request from a customer point of view. Weak requirements slow the build factory, increase time to delivery, encourage misinformation, trigger unexpected adjustments to the build plan causing time and resource waste.
The quality of requirements impacts an entire chain of events and resources that are used to drive a customer request all the way to delivery. This chain, high level, starts with communicating your understanding of the customer request, planning and prioritization of the work entailed in the request, assuring development’s understanding of the request so they create the solution wanted, and then back to the customer to assess the solution created to confirm alignment.
Initial conversations with customers over a request are a start point in the elicitation process. Well thought out requirements is the goal and accomplishing this may take several iterations.
A recent example of an initial customer request was as follows:
– “Delivery / vs internal transfers, Split delivery UI from transfer UI”
This start point told me, generally speaking:
- The customer has a request,
- The request is not well defined,
- The initial request implies:
- There is an existing system with a combined delivery and transfer feature,
- A transfer feature is a sub-feature inside of the delivery feature,
- The customer wants the Delivery and Transfer features separated,
- This request will probably entail UI and workflow changes,
- I have questions and clarifications…
Refining this request into a strong requirement entailed interviewing the customer to get their understanding of what was wanted.
A hidden risk to manage in the goal of refining the customer ask into a strong requirement is in the form of “Analysis Paralysis”. Only go as far as needed with details, and not beyond. Do this at speed so you deliver results in a timely manner. The line here is as much an art as it is a science.
The benefit of doing the upfront work that supports strong requirements may be in the form of reducing unexpected events on the way to delivery, assuring the same understanding and expectation of the request by the stakeholders, and supporting the notion that business and technical resources are aligned. In other words, no surprises.
Skilled business analysts will use the IIBA BABOK Elicitation and Collaboration techniques and method to refine requirements so that they are relevant and useful. Preparing, conducting, confirming, managing stakeholders and communication are key guidelines to apply.
In conclusion, Business Analysts with the skill to craft strong requirements will enable the build factory to deliver robust solutions at speed and without surprises.
Strong requirements lead to strong solutions.