CSCI 265 Requirements Document

Sample versions of most project documents can be found here, based on a fictional team and project.

This document is to be named requirements.md and kept in your team's documentation directory, and is to follow the template shown in this skeleton version, but the template has been deliberately kept vague since the actual content needed for the requirements document will vary tremendously from product to product. (E.g. what you need to describe for a game will be vastly different than what you need to describe for a new social media product, and both will be vastly different that what you need to describe for a project management tool, etc.)

The requirements document should give the reader a complete picture of every facet of the product from a user perspective: what it is for, how to use it, how every feature works, what every screen, menu, option, and element looks like, what the navigation structure is for moving from screen to screen, what to watch out for when using the product, etc etc.

It should also do so in a way that is easy to read and yet also serves as a strong reference tool - making it easy to find any specific bit of information you might be seeking. From the perspective of the developer, this should describe every detail about the product they are going to code so that they are not responsible for making behavioural/value choices as they design and code.

A common failing in a requirements document is a lack of specifics: suppose it states something like
"A character starts at their maximum health value and takes damage each time it is struck with a weapon (sword, dagger, or arrow)."
Somewhere (perhaps here, perhaps in a table elsewhere, but somewhere) the requirements need to specify exact values for every aspect: exactly what is the starting health? how much damage is inflicted by a sword blow? by a dagger blow? by an arrow? If there are modifiers that influence the damage then precisely what are they and precisely how is the modified damage calculated?
After producing a first draft of the requirements have everyone read through the document looking for places where it mentions a value or feature or calculation without precisely stating the range of permissible values, the default value, a precise formula for the calculation, the behaviour expected in case of errors, etc.

The document can often be based on the original proposal, but going into much much greater detail on every aspect (again, providing complete details for every screen, every menu option, every feature, every on-screen element, every calculation, every message displayed, every user input taken in, every error check and error message, etc etc).

This is going to be one of the largest and most important documents your team produces this term: it ensures everyone (testers, developers, users, clients, marketers, asset developers, etc) can tell exactly what every aspect of the product is supposed to be doing under every circumstance.
It is strongly recommended the entire team take on responsibility for different sections, start early, and meet/review/discuss the content multiple times as you develop the document.