Rationale

The main principle is to define the project before starting to do it. I start with assumption that both sides, the buyer and the provider, are interested in project's successful launching. There are just two things to define: what the project is (functional requirements) and what means "done" (acceptance test procedure). The benefit is mutual; I noticed that every time when something was dismissed or "saved", thing turned upside-down quite in unexpected way.

Functional Requirements

Formal Funcional Requirements (or Software Requirements) Specification document is a-must prerequisite for the project's beginning. This document defines functionality of the deliverables and lays certain assumptions for successful delivery in time. This document provides the following necessary definitions:

• Functional requirements per se: what the deliverables must provide and what behavior they expose. Everything not defined in "functional requirements" clause is considered undefined behavior, in other words imposes no requirements on the product at all.
• Assumptions and dependencies: what must be provided and be working for successful implementation of the product in the decided time terms: platforms, libraries, development tools, servers, hardware accessories etc. In many cases such a provision requires work to be done from the buyer's side, so "assumptions" draw a clear line between responsibilities of both sides.
• Risks: what are the forseeable risks that the project may face.

I can prepare the SRS according to IEEE standard's recommendations, or work with the document provided by the ordering party. Usually there is some dialog between both sides until all functional requirements are decided upon.

Acceptance Tests Procedure

ATP defines a set of tests that the ordering party should be able to reproduce upon delivery and receive the specified results. The ATP defines what does it mean "the product works". ATP is specified in Test Specifications document, which is based on functional requirements.

Implementation and delivery

After functionality and acceptance procedures are closed, it becomes possible to precisely estimate both time frame and price for the project. The project then can be developed and tested according to the specifications and delivered in time.

As any work made by humans, even with the strictest discipline it is impossible to forsee all possible pits and avoid plain errors. Humans should be excused for being non-perfect :-) However, practice shows that agreeing upon functional requirements and acceptance procedure traps most painful problems in the beginning. Additionally (last but not least!) making such a distinction on responsibilities and agreement on specifications creates an atmosphere of openness, like "cards on the table" and provides grounds of trust for solving unexpected problems by both sides together (or by an appropriate side, as will become apparent).