“How can all these things we are documenting and writing and calling ‘requirements’ actually be requirements when 45% of everything that is built, on average, never gets used?” asked Cook. “There is a fundamental flaw in the way industry is doing it.”
The flaw, he said, is building a prototype to the requirements, rather than using the prototype to determine them.
“We’re asking (developers) to define dynamic systems that configure themselves, based on previous answers and state changes and applying business rules,” Cook said. “There is all this complexity and we expect people to describe in words what it will do? No wonder such dismal record in terms of the results; it is the wrong medium, the wrong way to approach requirements.”
The correct approach is to build a visual prototype and then engage with the stakeholders about how the system should work. Users can then work with the initial model and give their feedback. That feedback then gets incorporated into the final design. And since it is based on actual user experience, it eliminates trying to add in lots of additional features which may not be needed. He said that doing it this way gets more people engaged in the requirements process, instead of one expert dominating the discussion of what should be built.
“It helps get rid of some of the bloat,” says Cook. “Now you have an application that is more elegant and better meets the business needs.”