Often business analysts struggle with ambiguous requirements from the business departments.
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.
Requires Free Membership to View
When you register, you'll receive targeted emails designed to keep you informed of the most relevant information on Agile development, application security, testing & QA, software requirements, and more.
Hannah Smalltree, Editorial Director
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.
This was first published in June 2007