A good analogy for software development can sometimes be legal contract drafting - a contract looks a lot like source code (and often should be more like it).

Before starting, the parties need to agree what the contract is for (analysis) and it's a good idea to write this down in a non-contentious way, before thinking about how to actually write the contract (requirements definition).

Both the writer and the eventual signatories need to think hard about how the contract will be used (use cases). Happy day scenarios are easy to define, but often the value is in the unhappy scenarios and any remedies (SLAs). Any logic and formulae should be defined, and this is worth doing outside of the main text, in a format where the intent and content are more important than the syntax (pseudo code).

Once there's agreement on what we're all aiming at (requirements sign-off), the jurisdiction which will be used should be agreed, especially where the parties are in different domains (agree the high level architecture and design).

Only we can start drafting (build). Both parties should read the draft and decide whether it works for them in as many scenarios as can be imagined (test).

Changes, either to the draft's detailed wording or the broad thrust of the contract, should be subject to negotiation, and we need to keep a trail of how we get to the final wording (change and version control). If we have got the structure agreed up front, it's more likely that we can accomodate detail change without massive revision (have a flexible design and agree it before starting to build).

Once the all parties are happy, they should sign to that effect, and the contract comes into force on the specified date (implementation). Should things go wrong, or needs change, all should come together to discuss any revisions that may be needed (support).

And finally "Whereas" seems to mean roughly the same as "#include stdio.h" (never meant much to me but they all seem to put it in).

Bill.