Charlie,
First of all, I apologize for the overly belated follow up, and I hope John's templates were helpful.
When I've have to create these kinds of documents in the past, a good general rule is to focus on the future state of the project. If you are performing an upgrade to an existing system or process, a brief statement describing the current state helps put the changes in context. I like to break things into high-level groups of functionality or business processes, as that is how most users tend to view systems.
For example, if you are describing the implementation of a new Change Management process in eProject, it might look something like this:
Current State: Users fill out a change request Word document and email it to the IT Manager, who coordinates new and outstanding change requests for the weekly change control conference call. The IT Manager manually updates requesters on the status of open CRs on an ad hoc basis.
Future State: Users complete and submit the Change Request intranet webform. The IT Manager will be automatically notified of the new request via workflow notifications. A series of global Change Management views in eProject will be created to manage the weekly change control conference call and for requesters to track the ongoing status of their change requests.
This is typically enough detail for end users to understand the nature of the changes and you can certainly include screenshots, mockups, or workflow diagrams to more clearly illustrate the changes where appropriate.
If your target audience is functional management or higher, including some kind of value statement or measurement of the impact of work to be done. Continuing the example above, you might include a statement such as "Using eProject to manage the change control process eliminates the need for the IT Manager to follow up on change requests, which currently consumes an average of 5 hours of her time each week. It also provides a more reliable and accessible archive of historical change requests for our quarterly IT audit."
For testers, you should include the above summary detail, as well as a detailed description of the to-be workflow and expected outcome so testers know what to expect when their work starts, and how to determine if the actual behavior deviates from the expected outcome. This kind of scenario-based detail, especially early in the project, will help developers understand how the system will be used, and will generally be enough to write UAT scripts for business users later in the project.
Finally, if you're not making changes to an existing application or process, simply leave out the Current State elements, however the Future State and value statement elements can work by themselves to give the audience a good understanding of what is being developed and why, and they can validate your ideas and design based on this kind of data.
Hope these tips are helpful!