Re: functional specifications formats (overall rather than documentation)

[Beth Agnew <Beth -dot- Agnew -at- senecac -dot- on -dot- ca>]

 I've had excellent results with a couple of client companies by using 
Use Cases, which are then used to develop specifications. (You can 
download my Use Case info PDF from my website at 
http://www.agnewcom.com/resources.html). Written use cases break the 
product design down into tasks and features in a way that is user 
focused and task oriented. The resulting specifications are then much 
easier to write, and more complete. This approach also gets more people 
involved at the design stage, so that there is a clearer collective 
vision of what you're producing.

Many developers are familiar with the idea of use cases as they are part 
of the UML methodology. Written use cases externalize that information 
so that the product manager, techwriters, etc. can see what is going on. 
This lightens the burden on the developers (who aren't always masters of 
design) and shares the load among all the stakeholders. Typically, the 
business analyst or systems analyst is the best person to write the use 
cases, but they're not that difficult to create, so it could be any 
member(s) of the team.

There's a bit of a learning curve for implementing written use cases 
within a company, and they must have the will to do it right, but it can 
be very successful.
--Beth

Emily Goodin wrote: