Re: Requirements/Specifications

[David Girardot <dmgirard -at- CORNETLTD -dot- COM>]

Miles asked about requirements documents...

Seems to me that the place to start is a needs and audience analysis.
First, find out who your users are and find out their strengths and
weaknesses.  You also need to list, at a high level at first, what the
client wants the software to do.  "Track my projects" or something is too
general, you might really want to "track hours for multiple resources,"
"generate monthy reports," and so on.

One you have that initial list of needs you'll want to interview the users.
It's not uncommon to have different divisions at the client to have
different needs (field representatives, home office personell, management).
You need to find out this stuff, especially if you're dealing with an
information services organization which may have incomplete information
about its user's needs.

Your interviews will help you trim and improve your list of needs.  This
list is easily developed into requirements by expanding each need into a few
specific requirements.  If "business rules" are an issue it's a good idea to
attach them to the requirements document.  IMHO specific interface
descriptions don't belong in requirements, but in specifications.
Specifications are the designer/programmer's response to the requirements
document.  In other words, how the client's requirements will be met in
software.

The better you define your client's needs -- keep in mind that a client may
not know or fully realize what their needs really are -- the better the
whole project will run.  You may want to develop a kind of "product map"
which assists clients in figuring out what needs they have.  Perhaps there's
a thought process you can lead them through to figure out what they really
want and need.  Finally, part of the whole process should be contigency
planning -- what if the client needs last minute changes, what about
overruns, etc.

-- David