The best advice I can give regarding size/scope of a specification is dependant upon it's intent. If the specification will be used to create a proposal, including an estimate that you will be required to stick to or eat the cost, then you need to spend as much time on it as you can. The more information you can finish ahead of time, the easier it is later to actually do it. Of course, the balance point with this, is that if it is not accepted, this is time lost. If it is, the time spent is just rolled into project time. The middle ground is found with a balance of trust with the customer. When defining the requirements for a project, attempt to involve them as much as possible. Perhaps even to the point of wireframing or prototyping. Sometimes you can't trust the customer, other times they trust you fully to do what is right. There is purpose on both sides: The customer needs to know that what they are buying meets their needs, and the developer needs to know what is expected/required of their product. If either party is unsatisfied, bad things can happen; breach of contract one either side. Basically you want the spec to be detailed enough to describe what the customer needs, and what you are going to do for them. It should be detailed enough to provide an estimate of time/cost of a project. It's purpose is to keep both parties satisfactorily on the same page. Brad BAMDevelopment.com