I'm an engineer, and as a programmer I'm just an amateur. This easied things to me, since I could take decisions about practices based on what made sense to me. But now I need to take responsability for some formal programming tasks, and I don't know which examples to follow.
I think such a contract won't help you, because after writing and using the software, you will always find things, that you now like to do different from what you wrote into the contract. I think the best to do is to divide the project into small pieces.
Thanks for all sugestions. I do agree with what you and others said, and that's what I would do. I already worked with others in my former office, and the result was pretty good with just some talk, a few pictures and around 5 points in source code saying "here the world state should be this" kind of comments. But I have an additional concern: to fit in burocracy. I need to write a contract that someone else, who understands just office applications, not software writing, will need to feel safe enough with to sign it. It's not that important to have a good contract, but actually to be able to say "someone else did it like this, and had no problems". Then I can save that contract and forget about it. I need something that won't hurt, more than something that will help development. (I do trust the programmer. Much to my surprise, he suggested Haskell as the better option for the job.) Thanks, Maurício