There are different documents that define a project:
- Product Vision: this document is used to communicate what the product should do and what it shouldn't do. It typically has sections that compares the product with competitors and show its advantages. It also lists stakeholders involved in production and implementation and their roles. A very important section also lists types of users (roles) and how the system will add value to them and make their work better.
- Requirements documents: They shall contain both functional and non-functional requirements. Sometimes they are separated in Use Cases for functional requirements and Supplementary Specifications for non-functional requirements. Some organizations combine all in one SRS (Software Requirements Specifications) document and others put Use Cases in the SRS and use separate document for the Supplementary Specifications.
Product Vision is usually prepared in early stage of the project where only high level specs are defined and it's intended mainly to get agreement with the customer. A Project Charter document is prepared in the same phase as well as part of project management documents. It contains even higher level description of product functions and it's intended to define the scope of the project. Some organizations use it as internal document for agreement on scope between PM and senior management. However, some organizations use project charter instead of project vision and use it for customer agreement as well.
When project kicks off, especially large ones, two documents are prepared by Business Analysts (domain expert): the As Is document and To Be document. The As Is describes the current environment and work flow in business domain (somethings are manually done for example using papers). The To Be describes the what the customer wants things to be (how the software will be used instead of paper work).
After the As Is and To Be are prepared, the System Analyst starts making Use Cases and Supplementary Specifications.
This is the largest scale I have seen in organizations I worked for. You can combine or remove documents as you like/need to suite your project. Smaller projects do not need so much documents and they do not involve many roles. Large projects need such separation because different documents speak to different people. Specially if you want to communicate with high managerial positions you should not give them documents with content they are not interested to read.
