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.

Scott Manning has been writing FDSs for years. At MortgageRamp, he was the Lead Interface Designer in charge of training and managing a team that produced over 3,000 pages of documentation for MortgageRamp's DealCentral Lender application (Read more in Scott's Resume.

Samples of Functional Design Specifications:
	FDS for Digital Survivor's Homepage

Benefits of Using a Functional Design Specification
The benefits of having an FDS before starting development are numerous. 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

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.

FDS Creation, Review, and Approval Process

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.

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.

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.