Functional Specification

A functional specification describes how a product will work entirely from the user's perspective. It doesn't care how the thing is implemented. It talks about features. It specifies screens, menus, dialogs, and so on - joelonsoftware.com

You could consider simplifying this to the following:

A Specification overview is like the table of contents for your spec. It might be a simple flowchart, or it might be an extensive architectural discussion. Everybody will read this to get the big picture, then the details will make more sense.

# Non-goals Non-goals are things we are just not going to do. When you’re building a product with a team, everybody tends to have their favorite, real or imagined pet features that they just can’t live without. If you do them all, it will take infinite time and cost too much money. You have to start culling features right away, and the best way to do this is with a “nongoals” section of the spec.

A nongoal might be a feature you won’t have (“no telepathic user interface!”) or it might be something more general (“We don’t care about performance in this release. The product can be slow, as long as it works. If we have time in version 2, we’ll optimize the slow bits.”) These nongoals are likely to cause some debate, but it’s important to get it out in the open as soon as possible.

# Scenarios

When you’re designing a product, you need to have some real live scenarios in mind for how people are going to use it. Otherwise you end up designing a product that doesn’t correspond to any real-world usage).

Pick your product's audiences and imagine a fictitious, totally imaginary but totally stereotypical user from each audience who uses the product in a totally typical way. Chapter 9 of my UI design book (available online for free) talks about creating fictional users and scenarios. This is where you put them.

The more vivid and realistic the scenario, the better a job you will do designing a product for your real or imagined users, which is why I tend to put in lots of made-up details.

# Details, details, details The devil is in the details. You can specify them how you want either with a Screen-by-screen specification or a Flowchart. Example: we’ll have time later to go into mind-numbing detail, but for now, let’s look at a quick flowchart of the service so you get the big picture. This flowchart is not complete, but it does give you the right idea for the “storyboard”

A Screen-by-Screen specification consists of quite a few different screens. Most screens will follow a standard format, with a look and feel to be designed in the future by a graphic designer. This document is more concerned with the functionality and the interaction design, not the exact look and layout.