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:
- Introduction
- Functional Description
- 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.
No comments:
Post a Comment