A functional specification document, an FS document, or a functional requirement document, will help your team sail through the overview, user levels, deliverables/platforms, features, and their dependencies, use cases, limitations, assumptions, finalized wireframes, and UI. A functional specification document should be simple, understandable, and readable for your team members. However, the format for a functional specification document varies based on the company and the project. The FS document helps reduce the number of change requests and the development team’s efficiency and returns us with a happy client.
The overview section gives an overall idea of the customer, the type of customer’s business, and the type of project. The team gets an idea of the market to which the customer wants to launch the application, the aim of the client in building the application, and the approximate launch date. The team should be able to identify the basic requirements of the customer from the overview itself so that it prepares for the upcoming features.
The user levels outline all the different types of users who will be using the application. Let’s take an example. For a multi-vendor e-commerce application, the following are some of the possible user levels: customer, vendor, delivery agent, sub-admin panel, and admin panel. Similarly, for a single vendor e-commerce, the following are some of the possible user levels: customer, delivery agent, sub-admin panel, and admin panel. In the above examples, we have just discussed the possibilities of the user levels and it does not mean they are must-haves. For example, if a vendor is willing to take responsibility for processing a product and completing the delivery with the help of their in-house employees then the delivery agent can be excluded from the user level.
The platforms section gives the team a detailed listing of which of the platforms each of the user levels has to be launched in. To make it much easier continue with the example mentioned above. If the client wants only an Android application for the end customers, then it should be specifically mentioned here. It is solely the discretion of the client to fix the platforms for application release. The platforms can be Android, iOS, or a website. However, it is always the business call of the client to go for all the platforms or only one or any two of the three. For each user level, which all platforms are needed should be specifically mentioned in a functional specification document. This listing helps the development team get an overview of the total number of platforms that they have to build.
This is the main part of a functional specification document that enlists all the features which have to be included in the application. The features must be listed in such a way that while going through the document your development team should be able to under the flow in which the application works. Each feature must have a title, description, purpose, limitations, and acceptance criteria. This in turn gives the team a clear picture of the feature with almost all the edge cases covered.
Let us understand the process of providing a feature description with the help of an example.
Feature: Login using a phone number with OTP verification
Description: Once signed up customers can log in to the application using the phone number registered and OTP verification
Enter phone number: Users can log in to the application using their phone number registered with OTP verification. If the user enters a mobile number other than the mobile number registered then an error message should be displayed. Only after entering the phone number registered, the ‘Send OTP’ button will become available for the user
Verify OTP: After entering the correct registered phone number, the user can click on the ‘Send OTP’ button and will be directed to a screen having a field to enter the OTP. The OTP sent to the user's mobile number can be entered manually or auto-filled. If the user is entering an incorrect OTP then an error message shall be displayed. If the user is entering the correct OTP and clicking on the ‘Verify OTP’ button, the user will be directed to the home screen.
Resend OTP: On the OTP verification screen a ‘Resend OTP’ button should be provided. If the user has not received an OTP even after clicking on the ‘send OTP’ button on the phone number entering the screen then they can click on the ‘resend OTP’ button.
The description should cover the purpose and limitations of the feature. Based on the description the different acceptance criteria should also be mentioned below it.
Wireframes and UI
There can be two ways for including wireframes and UI in the functional specification document. The first is by just keeping the link for the wireframe and UI and the second one is keeping each of the wireframe and UI screen/page beside the corresponding feature. The second one is more recommended since the development team will get a picture of the entire functionality quickly. After viewing the wireframe and UI and going through the description the development team thoroughly understands the feature and its functionality
Once a functional specification document is generated then it helps to bridge the gap between the client and the technical team. Everybody will be on the same page and there won’t be any confusion. This practice will help in saving time, money and increases the work efficiency of the team.