|About us||RCL 20||Projects||Colour Selector||Library|
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:
Companies aren't expected to provide story boards for TV ads of their products but some companies 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.
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.
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.
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.
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.
Copyright © Limitless Innovations 2020