It's a very comprehensive document that specifies the expected functionality, interactions, and business rulesin the design. It can include user stories or use cases.
The purpose of this document is to:
- Tell the stakeholders what they are getting and get them to approve
- Tell the developers what functions to build
- Tell the testers what functions to test
It is typically written at the end of the design engagement - in the Design Implementation Support phase. This document is intended to include details therefore it is time comsuming. Therefore it's only done when time and budget allows.
- The functional specs document should follow the hierarchy of the design. First, sort out what components there are, for example: No.1 Header component.
- Then specify the different objects within the component. For example, within the Header component, there are Page Navigation Buttons, Search Bar, Notification Button, etc.
- Describe each object, including:
- The purpose of this object (could be in the format of a user story)
- Different states of the object
- Attributes of the object (or items within the object)
- How the user can interact with it, such as hover or click on it
- What happens when the user interacts with it
- Data elements involved in it (entity names should match data dictionary)
- Business rules associated with it