To What Extent Are Requirements and Specifications Useful?

During Model-Driven Development projects the question often arises as to why we should document the requirements and specifications. As business owners easily understand the model used during model driven development, it diminishes miscommunication between business and IT professionals. Therefore it could seem sufficient that the product owner and system architect only have to sit together to build a quick POC that will be extended later by the project team.
But when determining to what extent requirements and specifications are useful, keep in mind that it provides insight into the business objectives: why the application is developed at all, what functionality it should support, and what this functionality should look like.

This is very helpful to:

1. Provide a common understanding.
   Especially for the project team, so that everybody understands what they are all working on and why. Not only from a technical perspective, but also how and why choices between quality, functionality and speed of delivery have to be made.
2. Provide guidelines when change is requested.
   The requirements and specification should provide sufficient guideline to determine why, when and how the request for change should be implemented. If the change is accepted then the specifications should be updated as soon as possible to reflect all changes.
3. Provide guidelines for testing.
   Testing without requirements and specifications can lead to many missed defects or time-consuming discussions between testers and developers.

Does this mean that, concerning requirements and specifications, a project can only start when all requirements and specifications are formally accepted by the steering committee? No it does not. In my opinion the requirements and specifications in a project should be of such a quality that the following business case is optimized:

(The cost of spending more time on writing better requirements and specifications)
MINUS
(The risk of losses as a result of waste in the 3 scenario’s drawn above)

In other words, requirements and specifications should be optimized to the point that the cost of postponing the project are higher than the risk reduction, expressed in reduction of unnecessary costs, brought by writing more and better specifications. This means that one can start the project with draft versions of requirements and specifications if all the team members know what they are working on, what the project boundaries are and when the deliverables can be tested. The finalized version of the specifications can be delivered together with all the other project deliverables as agreed on in a definition of done.