Rule of Requirements

A requirement document must have the highest influence on how the project is implemented. It corresponds to, I believe, a collection of laws in a community in which the “Rule of Law” is upheld as sacrosanct. In this sense, writing a requirement document is akin to devising a set of laws for the contract comprising, in the simplest case, a developer and a customer.

In its most basic form, a requirement document is the communications between a customer and a developer in written form. It should include a compacted summary of final agreements.

Here are my guidelines for maintaining the “Rule of Requirements” during the development of a software system:

• The requirements must be accessible, intelligible, simple, and straighforward to both the developer and the customer.

• The requirement is the authoritative source for decisions regarding the implementation of the project. Neither the customer nor the developer may impose their interest to the other without due process. The final word should be in the requirement, and anything outside the scope should either be avoided or included via negotiation.

• Neither the customer nor the developer is allowed to make any changes to the requirement without obtaining the consensus of the other party.

• All ambiguities about a feature should be resolved by the requirement, as opposed to one party’s discretion. The requirement document must be defined in such a way that the scope for independent choice is narrow and restricted.

• The requirement should cover all the details necessary in order for both parties to be able to share a common prediction for the properties of the system being constructed.

• The developer and the customer must communicate and perform their respective tasks professionally and in good faith.