Project specifications documents or “specs,” provide a comprehensive description of all of the project’s objectives. A good spec includes:
- Project goals, in both the short- and long-term, if appropriate;
- Project constraints, including technological, philosophical and human constraints, among others;
- Expected features, including those available to the user and those only available to the project’s administrators;
- Use cases, which are examples of how the product will be used in practice;
- Case studies, which are examples of how the product has been used in practice;
- Maintenance considerations, such as how the party plans to maintain the product without the benefit of the vendor’s expertise;
- A budget, unless the spec is designed to help a vendor determine a budget; and
- A timeline, for the product’s completion and for its implementation.
But a good spec does not just include these items; it communicates them well. Here are some tips on how to create an good spec.
- A spec should include as much detail about the project’s objectives as possible. The price of forgetting an important detail is too high for a party to sacrifice absolute clarity for word count. If the spec runs several pages on a mobile app, PDF or other virtual document, there is no reason to panic.
- A spec must be as explicit as possible. Repetition is not necessarily bad if it clarifies the project’s objectives.
- The language of a spec should address users and/or project developers as if they know nothing about the project. This ensures clarity of product objectives.
- Make sure use cases alternate between a list of requirements and narratives. In other words, some use cases should be “user stories,” in which the spec outlines how a person would use the product. For example, the spec might present a use case in this way: “The user enters the website and clicks on the red ‘Platform’ button, which links to a page containing the party’s platform in bullet points.”
Clear specifications ensure that both the party and the vendor or internal development team share an understanding of the project’s deliverables and timeline. Without a clear spec outline, the vendor might not be able to understand the party’s intentions, and both sides will waste time and resources.