In this blog post, James Christie starts from the fact that perfect requirements don’t exist to discuss the idea that the quality of requirements is directly influenced by the time and money you invest in crafting them.
His own opinion is that “that is true to only a very limited extent; it’s certainly less true than software developers and testers have traditionally chosen to believe.” He starts by discussing some of the common issues with requirements:
* treating requirements as being a shopping list
* confusing design solutions and requirements
* the difficulty to define what is an essential feature or just an optional fuction
He thinks that “It’s bad enough that we don’t really understand requirements, but to make matters worse we don’t understand design either.” The problem is that user are often biased to present requirements assuming already what their solution will be, even if they are unaware of what is really possible. This remind me of a project that included some reporting aspects where a business analyst had included in the requirements document some reports that were impossible to produce with the technology used for the product or available on site.
Regarding the perfection of requirements, his conclusion is that “messiness, uncertainty and experimentation are inevitable features of building software. That is the reality; denying it merely stokes up problems for the future, whether it is a failed project, or an unsatisfactory product.”
Read the complete blog post on http://clarotesting.wordpress.com/2013/04/29/perfect-requirements-selective-inattention-and-junk-categories/
