We are writing for an audience that doesn't know how to code but does know what it wants - I suppose its the same every where, really. So we have divided the process up into three parts documentation wise:
1. Overview document - this addresses the overall goal of what the software is to do, how it will do it, what type of resources will be needed to support it, etc. its meant to be a high level overvieew readable by Managers and other techie types ;)
2. Funtional Requirements Document - here we detail use cases, functional response of the software, pseudocode and table structures, if necessary. This is a more low level typs of document designed for users with a reasonable level of computer experience. It has enough information in summary sections to allow pointy haired bosses to read it and have a clue while detailing nitty gritty details for detailed analysis. This step normally has anough info to allow us to build a model or prototype of the code for users to evaluate functionality and see what is missing.
3. End Documentation - actual documentation to go with the finished product. It has class descriptions, schema ERDs, and user/admin manual type of docs. It is meant to be pretty comprehensive.
For designing systems, I'm reading through UML Toolkit by Ericksson and Penker, Wiley Press. I seem to remember a doc from Sun that spoke about making readable documents but I forget the actual reference, sorry.

MadraghRua
yet another biologist hacking perl....