Software Reality
Programming with
a dose of satire.

Site Map Search


Agile Development
 
Extreme Programming
 
Code Generation


Articles
Lifecycle
Design
Programming
Soapbox
Reviews
Cthulhu

Use Case Driven
Use Case Driven Object Modeling with UML: Theory and Practice
Get from use cases to working, maintainable source code. Examples use Spring Framework, JUnit and Enterprise Architect

Agile UML
Agile Development with ICONIX Process
A practical subset of agile development techniques, illustrated by example

Get Controversial!
Extreme Programming Refactored
Extreme Programming with a dose of satire
Available now:



Java Swing
Swing's greatest threat isn't SWT, it's Flash
Swing Survival Guide

Check out our ageing Reviews Section




Lifecycle

How to Write a Functional Specification

By Dino Fancellu
May 26, 2002

With the advent of use cases and object oriented analysis & design techniques, "traditional" functional and requirements specs have faded into the background somewhat: they appear to be less "trendy" than they once were.

Agile processes, which are an important advancement in software thinking, have had the unfortunate effect of "de-emphasising" functional specs in peoples' minds. It is important to understand that the point of agility is not to write no documentation, but to write just enough: to use documentation and modeling as a means to an end, a way of getting to the code.

The fact remains: functional specs are no less important to a software project than they were ten, twenty or even thirty years ago.

They can be used in tandem with use cases: in fact, this symbiotic relationship can help to keep the functional spec a short, meaningful document that says just enough about the required functionality. The use case realizations can then form the examples (e.g. scenarios depicted as sequence diagrams derived from the use cases). The use cases can also help to identify gaps in the functional specification (and vice versa).

So, what should go into a functional specification?

The template linked to below provides a good starting point, and is a decent checklist for the sort of things that should be included in any functional spec.

If any of these items are included elsewhere in the project documentation, the functional spec should provide a reference to them: hence it becomes a useful, centralised document.

Although it is generally referred to in the singular, the functional specification is really a collection of documents (including the use cases) that define the functional requirements of the system.

It is important not to regard this document (or any other standard, or template, or set of guidelines) as being sacrosanct, set in stone, unchangeable or inflexible. Every project is different; and every document should be adapted to suit the local conditions.

Functional Specification Standard: MS Word  HTML

 

 

<< Back to Lifecycle

All trademarks and copyrights on this page are owned by their respective owners.
Stories and articles are owned by the original author.
All the rest Copyright 1998 onwards Matt Stephens. ALL RIGHTS RESERVED.