I would like to learn how to write a software product definition. Therefore I am looking for online materials or books which would help me to learn more about this topic. I would like to learn, for starters:

  • what must be included in such a document
  • what must not to be included in such a document
  • how to make a product definition to sell internally the product
  • finding balance between use case descriptions (the why), and feature descriptions (the how).

I am aware that it is not something that can learn in 15 minutes but I think such a discussion could help me to have a good start.

  • 3
    Please post a link to some examples of what you think of as a "product definition". We don't know what you mean by it. So please include one or two examples. – S.Lott Jun 29 '11 at 21:18

I've heard of this document as being called a Vision and Scope document. You can find a template at the Process Impact "Goodies" page. This information might also be captured in a Project Proposal document, and you can find a template for such a document at the Tigris ReadySet templates. These templates are just guidance, but you might be able to learn more about the information you need to gather to produce a full document by reading through them and making appropriate changes based on your project.

The requirements engineering course that I took also discussed vision and scope documents. The textbook we used is the Karl Wiegers book "Software Requirements". It contains a sample vision and scope as well as discussion on various topics relating to determining project scope and feasibility. Of course, when discussing project management topics, I would be remiss if I didn't mention Steve McConnell's "Rapid Development", which also discusses scope, features, scheduling, and budgeting (along with other PM topics). These should be a good book overview of project and requirements issues.


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.

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.