About us RCL 20 Projects Colour Selector Library
Written requirements
Windsor Half Marathon
Design guidelines
Briefs & proposals
Don't believe your web stats
The perils of mailing lists
Wasting money on web sites
dot slash ~ keep your URLs trim
Best-before dates
ISP surveys
1998 Central European ISP Survey
1996 UK ISP Survey

Written requirements

We believe that development shouldn't start until some form of requirements have been discussed and agreed. By requirements we mean a high-level document covering at least these issues:

  • the main objectives (e.g., promote a new product);
  • an overview of the context;
  • a description of the types of people who'd use it;
  • general content, functionality and features and
  • design considerations.

Who's responsible for writing requirements

Requirements document uses:

Form the basis of ITTs

Allow companies to give sensible quotes

Quotes to be meaningfully compared

The basis of a specification

Save time by defining priorities

Know when a project is finished

Companies aren't expected to provide story boards for TV ads of their products but some companies[1] expect prospective clients to provide specifications with that level of design and domain knowledge.

We don't think that clients should be expected to know what's possible and feasible on the web. That means that clients shouldn't have to specify a solution - instead, they should just have to describe their situation and goals so that the chosen web company can work with them to design a solution.

Web companies have different origins - some were design companies, others in advertising, marketing or software. They tend to vary in how much they expect clients to provide before design officially starts. We believe that defining and refining requirements is the first design step for a web site and so should be done together with people experienced in web development.

How requirements are used

As experienced software developers, we routinely used requirements and specifications on our projects. We have continued this practice as Internet developers and it has contributed to our good track record of finishing projects on deadline and within budget.

We have written requirements to help us prepare realistic quotes, to brief designers, during project management or in tender documents. You can see examples of requirements.

Purpose and limitations

A requirements document describes what is to be achieved in general terms. It doesn't discuss design or implementation specifics. It is used to externalise important information in a project; someone who wasn't at the requirements meeting should be able to read the document and get a good picture of the objectives, context, audience and goals.

For example, a requirements document for a web site wouldn't say "the site will have two rows of 100-pixel buttons" or that "the site will be implemented in Flash." Instead, the document must be left open to interpretation by those who will work from it, the experts in their field and thus best placed to make implementation decisions.

Iterative refinement

After a requirements document is drafted, it is usually refined through iterative reviews. Changes in the requirements are least costly at this stage. A "small change" once design has started, such as renaming a section or moving a page, could entail changing graphics, templates and programs, activities which will eat into the budget and prolong the schedule.

Requirements vs. Specifications

A requirements document is still just a high-level document and cannot describe all of the intended work; that is what a specification is for. And although specifications contain design and implementation detail (e.g., what will appear where on a web page or a screen), they are also limited by what they can practically describe; there comes a point where it'd take as long to specify something detail as it would to design and build it.

It is inevitable that once you see your web site developing that you will want to change and expand it; starting with written requirements means that any contingency can be used on enhancements rather than on sorting out basic requirements.

There is often a tendency to go straight to design and development. However, designing and developing web pages is relatively easy; people have been building web sites since the start of the 1990s. Figuring out who your web site is for and what it should do is the hard (and, usually, more interesting) part. There is no off-the-shelf solution for the requirements phase; it has to be discussed and defined for each web site.

References and further reading

  1. SQL and Access developers, Aldus Software, explain [off-site] How To Specify What You Want. "How to Write a Requirements Specification for Bespoke Access Development"
  2. Derek Sisson writes about [off-site] Requirements and Specifications on philosophe.com