Whether you have included a formal Executive Summary or a less structured Introduction, the first section of the document proper is the System Overview. This is one section of the document where the needs of all sections of your audience are similar. Both the development team and the client need to understand the overall scope of the project. The difference is only one of detail.
If you haven't prepared a formal Executive Summary, some of the information that might otherwise have been in that section should be included in the System Overview. Even if you have prepared an Executive Summary, you might want to discuss some of the issues in greater detail. Alternatively, some issuessuch as the comparison of alternative solutions or risk managementcan be extensive enough to warrant separate sections.
Whether you include these topics or not, your main goal in this section is to establish the "big picture" of the system, which you should be able to accomplish by explaining the system parameters: the system's goal and scope, the design criteria, and perhaps an overview of the work processes.
There isn't a great deal to say about communicating the system goal and scope. If you've understood them, you simply write them up in terms your audience can understand. If you haven't understood them, you better go back and find out now.
Again, I recommend being as explicit as possible about areas that are excluded from the scope of the system, including those that might be implemented later. Anything considered for inclusion in the system should be listed here, even if you've decided to exclude the area from the system's scope. Spend some time identifying areas that you think might have been considered for inclusion but were never explicitly discussed. This is the time and place to make sure you and your client are operating under the same assumptions.
If you have prepared a cost-benefit analysis for the system, it should be included in this document but not necessarily in this section. It's a question of style, but I prefer not to embed pages and pages of tables in the main document. It makes for a much more readable document if you include only summary informationperhaps one or two tablesin the main document and put the rest in an appendix.
The same holds true for documenting goals and scope. You might have prepared a detailed analysis of functionality, cross-referenced by the goal it supports, and normalized by the importance of the goals. This is a wonderful tool and will be useful throughout the project. But if the table is more than one page long, it belongs in an appendix rather than in the main text. Just include a summary table with a textual description and refer the reader to the appropriate appendix for more details.