Functional Specifications for Fast Runners

Today's agile environment is looking for quicker turnarounds on results. Yes, it’s quicker with minimal bugs. Machines are trained to build intelligent documents. Any stakeholder in a project team could hardly spend time in reading a complete functional specification documents. Therefore, it is mandatory for a simple yet concrete Functional Specification template.

A template should provided outline to capture maximum details. It should act as a questionnaire to collect all the required details including negative scenarios and validations.

Here is an example of Functional specification template "for fast runners" that is simple to use and acts as a checklist to develop. It has three sections:

1. Introduction
2. Functional Description
3. Sign-Off

Section 1: Introduction 

The Introduction section can have the following information that will help any new reader also to understand the entire project clearly.

Project Description:

Provide a simple explanation about the project; this can include the total feature as list.

Assumptions and Constraints:

Any assumptions or any roadblocks, risks can be recorded in this section.

Point of Contact: 

The stakeholders details; for example, who is the project owner, project manager, business analyst, team leader, quality analyst, and devOps engineer, should be recorded in this section along with contact details so that any questions or clarifications can be reached out instantly.

References: 

Any past histories, or any related projects, or any existing products or applications available in market; sometimes could be the competitor details which we are trying to compete and beat (Only if it is legally allowed).

Section 2: Functional Description

Describe each function with the following set of topics. This set of topics should be repeated for all the function or features used in a project. This section should be documented in such a way that it can be called as a user story, defined as a ticket to estimate and build.

Function Description: 

This is a short description about the function to be built.

Use cases: 

This can be described with a diagram, or flowchart, or in a simple step by step text describing what the function should do if used. Below is an example table with the required details to understand the use case of a function.

Graphic User Interface (GUI):

Provide a pictorial representation of the function or feature on screen as per your vision. It can be a simple hand drawn material to show where which fields should be used, or buttons displayed. Please note, this GUI provides an idea for the UI Engineer to design. While you create GUI, please ensure that you give more importance to the user experience.

Functional Description:

This is the core section where you will define the actual function and fields. Following is an example table describing the fields included with an example entry:

Business Rules: 

The rules that the business would want. It is not like “common sense”. It is how the business would run. For example, a closed group environment would want it’s user to know what is incorrect while logging in the system; is it the username or the password. Here the error message would be straight forward. “This user account does not exist” if user name is incorrect. Else, “The password you entered is incorrect.” In case of a highly secured broader environment, where the security is highly important, the message for the same above functionality would be “Either username or password is incorrect” , so that the user cannot predict the username or password.

Validations: 

Any validation which can’t go along with functional description section goes here. For example, a cascaded wizard window, with partial save feature, the validation applied on Submit could be validating if all the mandatory fields are filled in.

Alerts and Messages: 

Any messages or alerts, both positive and negative, should go here. An example is provided in the below table:

Section 3: Sign-Off

This section is to make sure that everyone in the team who will be involved in building the project has understood the functional specification. It’s a kind of agreement and approval. Following is an example table where the stakeholders can sign-off.