Skip to content Skip to site navigation Skip to service navigation

Functional Design

Download Template

FSD Template

Overview

The Functional Specification Document (FSD) is written by the project's Business Analyst and provides detailed information on how the system solution will function based on what the requested behavior is. This document is created based on the high-level requirements identified in the Business Requirements Document and provides traceability from the functional specification back to the business requirements.

Process

Detailed functional requirements, including use cases, system inputs and outputs, process flows, diagrams, and mockups are part of this document. A functional specification does not define the inner working of the proposed system; it does not include the specification of how the system function will be implemented. Instead, it focuses on what various outside agents (people using the program, computer peripherals, or other computers, for example) might "observe" when interacting with the system. The Function Specification Document must be approved by both business and IT project sponsors before proceeding to the technical design phase.

EXTREMELY IMPORTANT: All projects involving a user interface must ensure accessibility by those with disabilities. UIT standard practice is compliance with WCAG 2.0, Level AA. For more information, see the W3C Web Accessibility Initiative Web Content Accessibility Guidelines (WCAG) Overview website. For Administrative Systems Project Managers, coordinate with the development lead and QA Director to identify and add the necessary accessibility related project tasks to the project plan.

What are the benefits of using a Functional Design Specification (FDS) or Functional Specification Document (FSD)?

From "Functional Design Specification" (external link) by Scott Manning, 1 April 2006:

"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 and 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

Note: At Stanford, Requirement Tracking Numbers can also be linked to JIRA requirement issues, Zephyr, and other JIRA issue types as the project progresses.

While the Functional Specification Document (FSD) is a good starting format in which to document the results of the functional design process, it is not at all instructive as to what the steps in that process should be. UIT is moving to User Centered Design (UCD) as our default methodology for functional design. That means moving away from "mapping requirements to screens" towards a methodology that places the intended users of a system at the center of the design process.

"The central premise of user centred design is that the best designed products and services result from understanding the needs of the people who will use them." — Design Council (external link)

To that end, rather than dictate a particular UCD methodology, some excellent resources to use as guidance are listed below. Further, Project Managers should not hesitate to recommend to the Practice Area Director, who has the final decision-making authority, that a UI/UX consultant be added to the project to provide guidance during the design phase. At a minimum, for any project with central/campus user facing functionality (not exclusively meaning a user interface), Project Managers should get in touch with the UIT Service Design Team as early as possible in the project to determine how they can assist. Also see their UIT service page.

Resources (all external links)

Books

Videos

IIBA

Other Groups