The Art of Project Management

7.2. Deciding what to specify

Every methodology I've seen for software development or project management defines specifications differently. I've never worried too much about this. There are four basic kinds of information that end up in specifications, and the easiest way to discuss them is by assuming that they end up in four different documents. But how these things get divided up isn't particularly important (although some people do get religious about it). What matters is that the right information is specified by the right people, and that it's produced in a way that is useful to the people who need to consume it. So, on smaller teams, these different kinds of specifications are often combined. On larger teams, they may need to be separate (but linked together) and even authored by different people.

• Requirements. To document the many things expected of a project, a requirements specification outlines all of the requests and obligations that the work must live up to. It consolidates all other requirements work and provides a point of reference for the project. At best, this is a list of victory conditions, describing what the end result will be, without explaining too much about how it will be achieved. In all cases, requirements should be defined before the design process begins (although they can be improved and updated later), and they should be derived from the vision document. They should be included with feature specifications for clarity and to aid in review (will ...