One of the key points that enables James’ approach is “tight collaboration†between the program manager and the developers. He talks about the miracles that can happen when you have this, as conversations can cause time to miraculously appear in the schedule. And his use of the toaster analogy is spot on.
Stop Wasting Your Time – Don’t Bother Writing Functional Specs
Don’t do it. Don’t use a functional spec to get superficial agreements and navigate the beurocracy that accompanies large projects. Don’t validate the specification trivially. Don’t deploy with a waterfall process (the spec is done, whew, now – on to design) and never revisit the spec. Don’t work with new developers, or remote developers, or anyone else who doesn’t have the context of direct eyeball-to-eyeball conversations with the customers. Also don’t hire any programmers without complete domain expertise in the customer’s business
How To Deal With Untestable Requirements – Rewrite Them
The premise behind the rule that requirements must be testable is driven by the goal of avoiding ambiguous language in your requirements. Statements like “the application must have a clean user interface†or “search response times must be fast†are also untestable, but more because of language than anything else.