Fog Creek Software
Discussion Board




Functional specification examples

Reading "Painless Functional Specifications"

http://www.joelonsoftware.com/articles/fog0000000036.html

makes me curious. What does a real specification look like? How many details does it present? I've tried to search for specifications but always end up with W3C specs and APIs and stuff. Anyone know of good examples that can be found online?

Rikard Linde
Monday, March 11, 2002

W3C specs definitely do NOT count as "painless" specifications..  <:-)

Banana Fred
Monday, March 11, 2002

Not quite the same as Joel's standards but still a non-nonsense approach and a complete real-world example.

http://www.ravenbrook.com/project/p4dti/req/

Gerry Shaw
Tuesday, March 12, 2002

No, the perforce requirements specification is a requirements specification, not a functional specification.

I wonder why Joel doesn't talk much about requirements documents. Requirements describe the problems that the system must solve. At a glance, I think the perforce requirements look good. For example, I noticed a sentence beginning with "It must be easy to [do this or that with the application]" This is the essence of a requirement - WHAT we need but not HOW it's done. Sometimes, you'll say how - e.g. if your system must interface with another system in a particular way.

A functional specification is a different document. Based on the requirements, it details the design of the system. Like, what screens will we have, what will they look like, how do you perform the tasks outlined in the requirements document. A main point of this document is to keep it on a technical level where the customer understands it, yet detailed enough to minimize ambiguity. It should completely describe all features, and also specify when happens when important things go wrong.

B
Tuesday, March 12, 2002

I worked at a company that wanted to be Anderson COnsulting in the Worst way (Before they became accenture).  This company had a very detailed process for specifications that seemed to work well.  Step one was a meeting where we brainstormed and got together requirements as much as possible.  This lead to the Application development plan.  The ADP  specified originally just Page flows, but by the time I left there it went down to the grey screen level.  We definied Greyscreens as HTML mochup (usually donw in something like Visio)  That Had the Functional HTML elements described (edit boxes, links, images)

Once we got this signed off, we started working with the graphics design firm and the coders went to work getting the detailed design document written.

Personally, I think we could have started coding a little sooner.  The DDD was overkill.


A great tool from the UML is use case analysis.  Identifying the users of your system and the ways they are going to use it is probably the key element of a functional design spec.


I subscribe to the XP model in this regard:  Keep a release as small as possible to still provide value.  Release early and often. 

Adam
Tuesday, March 12, 2002

THis might help  :

http://www.mojofat.com/tutorial/

Adam
Tuesday, March 12, 2002

Thanks all for your valuable comments. I'll be writing a requirements spec the next month and will put it online for peer review and copying:-)

Rikard Linde
Wednesday, March 13, 2002

*  Recent Topics

*  Fog Creek Home