Functional Specification / Requirement Document (FSD / FRD)

This post is to share a glimpse on Functional Spec and its contents. It is not very exhaustive but shall clarify the audience that reads this. There are umpteen documents and articles written on this topic and be searched over internet for more details.

Definition (from my perspective)

The Functional Specification Document (FSD) in software development is a formal document that describes the functions of the software/system or its component(s). A function can be described as a set of inputs, the behaviour, and intended / exceptional outputs.

Functional requirements may be calculations like business logic or revenue model or formulae, technical details, data manipulation & processing and other specific functionality that define what a system is supposed to accomplish. It is an intermediate document between the Business Requirement Document (BRD) and the Technical / Design Document.

Functional requirements may also cover Behavioural requirements.

Functional requirements are supported by non-functional requirements (a.k.a quality requirements), which impose constraints on the design or implementation (such as performance requirements, security, accessibility, scalability, reliability, etc.).

Generally, functional requirements are expressed as “system must do <<requirement>>“,  while non-functional requirements are “system shall be <<requirement>>“.

The implementation plan for functional requirements is detailed in the system design.  The implementation plan for non-functional requirements is detailed in the system architecture.

It will also enable you to manage the expectations of your clients or management, as they will know exactly what to expect.

Note: It is better to get the FSD signed-off with the stakeholders (Client, Architect, Technical Team & QA) in order to keep everyone synced up and to avoid rework in the later stages.

What is a System?

The black box terminology “System” features “Interfaces” and “States”. Interfaces are through which external entities (human & other sub-systems, generally called users) can interact with the system through inputs and outputs. States are result of interactions with the users based on the functions chosen and the data furnished.

Consider the eCommerce site as a system and its login feature as an example of a feature/component of the system. The following are few Use Case Scenarios that needs to be considered while describing the functional flow and behaviour/UI for each scenario in the FSD:

  1. User registers during checkout and thus logged in.
  2. User registers first and logs-in, and then shops.
  3. Already registered user logs-in first before shopping.
  4. Already registered user logs-in while checkout.
  5. Already registered user cannot login due to incorrect login credentials.
  6. Already registered user, reset password through forgot password link and logs-in.
  7. Already registered user experiencing account locked during log-in attempt.
  8. Account locked user, getting account reset and logs-in.
  9. A logged-out user re-logging-in to shop.
  10. An affiliate user logs-in and shops.

Note: The above being example, various functions like validation for Username and Password are not highlighted here. Though from the above scenarios “Checkout” is a separate component tied up with another component called “Shopping Cart”,  the integration scenarios are not explained in this post.

Why write FSD?

  1. FSD streamlines the development process by incorporating all of the functions and data used respectively.
  2. Every engineer working from the FSD has all their questions answered about the system to start building it.
  3. Using the stakeholder signed-off FSD ensures the development of system nothing less than what the client is expecting.

Producing a comprehensive (Clear, Unambiguous and Understandable) FSD is an arduous task. This may contain multiple sections detailing each of the requirements necessary to deliver the project. Hence writing this needs some domain expertise and is generally written by BAs or SMEs.

To achieve the comprehensiveness:

  • Be consistent in style and layout – Use headings and formatting
  • Numbering items and bullet points appropriately – Use abbreviations and define in glossary
  • Use diagrams for visual-oriented readers in addition to the text descriptions.
  • Break up text with screen shots, tables, and other graphical material
  • Develop detailed light-hearted scenarios – use unambiguous terms and keep sentences simple.
  • Define the System – What is the system supposed to be, supposed to do, users, metrics and any precedent for this system.
  • Develop models – User’s conceptual model (UseCases) and Designer’s model (Visio Diagrams).
  • Define Information Flow – Navigational Elements, Organization of Information, Prototype, Wireframes and Mockups
  • Write the Functionality – Cover everything, use screenshots, write concisely, correctly and consistently.
  • Coverage of functionality – For every screen, cover all elements and its functions and data from Top left corner to bottom right corner.
  • Review the document – Check Table of Contents, proof-read the document, and finally review from the hardcopy of the same.

What is in the FSD?

The conventional format of FSD contains information of Identification Control, Relevant Business Requirement, Functional Behaviour & User Interface Navigation Control, Data & Business Logic and Quality Criteria.

Download a sample template of FSD.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Blog at WordPress.com.

Up ↑

%d bloggers like this: