Specification Document

delanest

Hey making a website for a friend, does anyone know where I can get a requirements specification document/template. An example one would be great too ..

It's purely for the website design part, colors/features/style/theme (many more I'm sure) .etc .etc

cheers

louie

http://www.boxedart.com/

heggie

do you mean like a brief?

http://yay.kenwallacedesign.com/resources/Business/Entrepreneur/index.html

and

http://www.mediainspiration.com/contents/downloads/designer_forms.php

have ones for different jobs.

delanest

thanks for the links, some interesting ones but I don't see what I'm looking for.

I'm looking to get something that the customer would fill out stating what exactly there looking for,

e.g. "I want a website that has a char forum, photo gallery, member sign in area, blue/white main colors .etc .etc, 5 pages home/contact ....

- that kind of thing

hey Louie are you a member of boxedart btw, ...any good ?

destraynor

I reckon you're best off establishing that information after talking to the client. Chances are they don't really know what they want, they'll end up ticking boxes thinking "Well the site does need images, but is that an image gallery? What colours, hmm, does Gold cost extra?"

The Corinthian

delanest wrote:

I'm looking to get something that the customer would fill out stating what exactly there looking for,

e.g. "I want a website that has a char forum, photo gallery, member sign in area, blue/white main colors .etc .etc, 5 pages home/contact ....

- that kind of thing

If only it were that simple... No, really, I’m not being sarcastic.

A document filled out by a client may get you a list of basic functionality points but the reality is that clients will always want specific customisations even in a basic piece of software, such as a Web site. Additionally the client understands their own business, not the Web, so giving them a form and assuming they even know what a ‘char forum’ or a ‘contact page’ is will often end up in tears.

In short, a client will often not really know what they are looking for in practical terms and the developer will not know either without a process of discovery and analysis (typically in workshops) to define them.

The specification of any piece of software, including Web sites, will typically come out of a process rather than a simple questionnaire or order form. In this a business analyst (or someone adopting that roll) in collaboration with both technical and design input will put together the business logic (essentially the functionality) of an application through a process of consultation with the client and logical design (sometimes using methodologies such as UML, although this is overkill for 99% of Web sites).

Once this has been distilled from the client it is put down on paper in the form of your specification, which is in effect a deliverables document in largely non-technical language.

So there’s no real generic template for a specifications document. I suppose you could break up one into separate sections for design, navigation, content and functionality (which would be further subdivided into specific pages or widgets), but outside of that all it generally is, is a structured list of deliverables and the business logic they will follow (e.g. if someone does not put in a valid email address in the ‘contact us form’ an error page will be displayed). The reality is that no two spec documents are – or should be – the same, which is why they are typically billable deliverables in themselves in most projects.

So if I were you, I’d Google for examples rather than templates and draw from them to create your own format.

delanest

Ok, interesting replies thanks. I did not expect this document to be the definitive specification of the site but really a starting point during consultation. I work on large IT projects myself but not in design/web and I guess I was trying to equate across.

In larger organizations I guess the consultant would have to pass some sort of specifications to the different type of designers/developers from the consultants .....

anyway, I'm getting side tracked here, what I'm doing is pretty "Micky Mouse" but I still want to do it right.

Thanks for the replies

The Corinthian

delanest wrote:

anyway, I'm getting side tracked here, what I'm doing is pretty "Micky Mouse" but I still want to do it right.

Then I'd suggest you work to the format you're already familiar with but greatly simplified. Break it down starting from global deliverables (e.g. the site's look-and-feel), then screen by screen and number (& sub-number) everything for ease of reference later.

I'd also add sections that cover payment schedules, maintenance and bug fixing while you're at it if you're simplifying everything to a single document.