Often business analysts struggle with ambiguous requirements from the business departments.
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
There are many ways to deal with that problem. You can use a formal declarative syntax with a restricted amount of words. Or you can try the agile approach and sit with the business user and work with him on a prototype.
There is a third way, however. It's easy, and you might already be using it.
You've probably heard about the "test-first" approach for development. That is, before a developer writes the implementing code, he writes a unit test for it.
If you move this thought to the requirements level, you'll end in this rule: A functional requirement is well defined if the implementing subject is enabled by the specification to check if the requirement is successfully implemented.
In other words, you tell the business department to provide you with information for how the developers could prove themselves if the requirements are fulfilled.
Compared to the normal effort behind requirements definition, following this rule would result in a version of the Pareto principle where it would take 20% of the normal effort but it would result in at least 80% accuracy/completeness.
Of course, this could mean a strong paradigm change for your company. But the benefits would basically be the same as the obvious benefits coming with the test-first approach at the developer's side. Only now you've shifted to the earliest stage of the project.
From my personal experience, following this rule ends in very accurate requirements, as the test-driven way of thinking avoids lots of uncertainties that normally come up during the test phase of a project.
Dig Deeper on Software Requirements Gathering Techniques