For reference:

http://en.wikipedia.org/wiki/Accuracy_and_precision

Requirements are interesting in software development. It is used as the contract that the developer has to fulfill to succeed, if there is something missing then the requirements are incomplete, missing, wrong. This is surprising, because we expect the Business analysts or whichever groups writes the requirements, to envision how something that doesn’t exist would work and interact in great detail. In effect developers are asking for precision, we want to know how things work exactly so that we can fulfill the contract. Accuracy really does not have much value to developers until they find out that what they build was not what was needed and they have to re-work it. On the other hand the Business want accuracy.

Precision has an interesting effect on the development life cycle. First of the developer will have fewer questions as they have the details they need. This will reduce the communication between the developer and the business since there is no reason to initiate by the developer. In the ideal scenario the developer would implement the entire feature without asking a question. Deliver the feature and succeed, hand it over and …. Get bugs.

These “bugs” are then often referred to as bad requirements, missing requirements etc. The developers are annoyed because they succeeded at fulfilling the contract and then a fast one was pulled on them. The contract changed and they are held accountable to the new terms after meeting the original ones.

Good times.

If there is no accuracy then the developer will be handed some piece of paper that will function as little more than a conversation topic to have with the business. A requirement that states that the application needs to “add X’s to customers” is useless for building the feature because there is no information about where this feature should be, any of the details of the relationship like one to many, many to many, etc. The only thing this will do is create a bunch of questions that the developer needs to ask before wring a line of code.

This is because software can’t be un-precise. Software is the act of locking actions down into a concrete system that will be absolutely precise. To be un-precise is to have randomness, and that is one of the hardest software problems to solve.

For a successful project it is therefore important that the direction is accurate because the precision will be forced by the translation to software.

This direction comes from the requirements. Requirements should be accurate, if you don’t know exactly how something should work, don’t write it down. Let the process find the accuracy during implementation.

Accuracy is more valuable than precision; not only that, precision becomes a cost when accuracy is not there. The later in the process a change is found the higher the cost. And the more precise the requirements the later in the project the communication will be started.