[thelist] Specification parts?

[Lauri Vain]

Hi fellow evolters,

Yesterday Chris started an interesting thread about specifications and invited
people to vote whether a specification is needed when doing a project.

I, too, voted among the other 132 voters and at 4 pm, these were the results
(timezone GMT +02.00).

o   1.5 % of the voters thought that a spec is not needed at all and a total of
      4.6 % of the voters have never done one.
o   At the same time 93.8 % thought that a spec is necessary (whereby 24.6 %
      voted      "sometimes" and 69.2 % voted "Very much").

(note: another thread can be started about where the remaining 0.1 % are. Which
group would get that added to their results and thereby significantly change the
votes? :))

...today, I ask what are the major parts of a specification. I have done work
with real specifications only 1/3 of the time since I've been a programmer, but
I feel that laying out what needs to be done on paper is the base layer for
success. Specs often drastically decrease the time spent on programming, testing
and integrating.

By looking at the spec next to my keyboard and by relying on a bit of previous
experience, specs have most often the following parts.

o   Objectives of the project
o   Members of the team (list with member name and function)
o   Target audience
o   Requirements list
o   Structure of site (relational site map or something similar)
o   Deliverables
o   Workstreams
o   Phases (discovery, initation, design, build, test, launch, evaluation)
o   Deadlines (not always nescessary -- sometimes the
     coder creates a proposal based on the spec)

(some items on the list were extracted from Martin's article here at evolt "A
Project
Management Glossary")

Could some savvy people out there make additions to these? Closer comments on
the points above and on every newly suggested point, are highly welcome as well.

Alternatively, I would also like to see some real specs or examples.

Thanks!
Lauri