Functional Design Specification

by Scott Manning on April 1, 2006

A Functional Design Specification (FDS) is a document used by companies in a pre-development phase to translate all notes, concepts, and scope into a complete requirements document. The document can include anything from flowcharts, screenshots, and wire frames. At a minimum, an FDS will contain an organized list of requirements that can be used for development, testing, and client sign-off.

Samples of Functional Design Specifications:

Benefits of Using a Functional Design Specification

The benefits of having an FDS before starting development are numerous. By having a completed FDS, time, resources, and most importantly, money are all saved when everyone involved in designing, developing, testing, and approving of an application have signed-off on a document containing an organized list of all design and functional requirements.

By using an FDS:

  • Development knows exactly what to develop
  • Quality Assurance knows exactly what to test
  • The client knows exactly what they will be getting
  • Requirement Tracking Numbers

Screenshots, Mock-ups, and Wire Frames

Many developers have found themselves developing from a sketch that looked like it was drawn on a moving train.

A Developer's Nightmare

Comparatively, an FDS prevents the headache of trying to translate stickynotes, cocktail napkins, and countless emails. Developers known exactly what they need to produce.

Sample of Mock-up and Wire Frame from an FDS (click to enlarge):

Digital Survivors Homepage Mock-up

Digital Survivors Homepage Wireframe

Creation, Review, and Approval Process

For a Functional Design Specification to be truly effective, it must be treated as the first and final word on a development project. In order for the FDS to reach that status, it must go through an extensive review and approval process once the requirements have been gathered.

Most development companies have an industry specialist, a development department/team, and a quality assurance department/team. The following flowchart is an example of a generic review process that would be used by most companies (click to enlarge).

FDS Review Flowchart

Requirement Tracking Numbers

Each FDS should have a set of dynamic tracking numbers. Requirements are anything related to design and functionality. For each requirement, there is a number.

GUI Numbers

Once an FDS has been signed-off on and the development phase begins, these numbers are locked. They are used for testing, bug-tracking, and approval. When something isn’t functioning properly, a tracking number is referenced within the FDS. This allows Quality Assurance to say something along the lines of, “There is a bug with Field X, because it is in the wrong format. Please refer to GUI 2.6.4.”

Testing and bug-fixing become an easier process to manage and complete.

Changes and Document History

Usability expert Jakob Nielsen says, “The most common estimate is that it’s 100 times cheaper to make a change before any code has been written than it is to wait until after the implementation is complete.”

I have found this estimate to be true. Once an FDS is completed, it typically only takes a few minutes to make a change to the document. It could take days for a developer to make the same change to an existing application.

At the beginning of each FDS, we have a Document History table that tracks the origin of the document. As changes occur (and they always do), this history table is updated to detail changes and reference the affected tracking numbers.

FDS Changes

This method of tracking changes to an application is much cleaner, easier to track, and easier to develop than the typical format changes are submitted to developers.

{ 7 comments… read them below or add one }

1 Dobbs March 10, 2012 at 1:35 PM

Wow… Thanks Mr. Manning for enlighting me into the wonderful world of function design. I have to say I think I have personal used this format in a past life and it was always worked well.

Reply

2 satish March 30, 2012 at 10:39 AM

Thanks a lot,
this article had really guided me to improve our working more better and easier than before.

Reply

3 Coffee September 7, 2012 at 9:44 AM

Thanks … This is exactly what I needed to relay to our vendor what we need from them and hopefully will make this project flow better.

Reply

4 Andrew Bloss September 14, 2012 at 11:30 AM

So lucid. Lovely to read. Thank you.

Reply

5 Vinay October 11, 2012 at 2:24 AM

Simple n well explained .. Thanks mate :)

Reply

6 kush November 22, 2012 at 8:48 AM

I Liked the way of explaining in Crisp Manner and importance of each section within FDS.

Reply

7 Chetan Vaidya August 5, 2013 at 5:14 AM

Hi,

Thank you for the elaborate information.

Request on standard components which should be a part of a FDS for CCTV Survelliance project.

Regards

Chetan Vaidya
+91 9321317673 / +91 2223788224

Reply

Leave a Comment

Previous post:

Next post: