What is a Functional Specification and How to Create One

What is a Functional Specification?

A functional specification is a document that describes the details of a digital product (a mobile or web application, an IoT system, etc.), i.e. the idea of the project, its business objective, the scope of work, system functions, interactions between the system and the user, or non-functional requirements such as security requirements. In addition, it may contain an outline of the working methods (unless there is a so-called ‘statement of work’ document).

The functional specification accurately acquaints the software house with the client’s expectations and performs two main functions:

It provides a cost evaluation of the project—it is the basis for an exact valuation of the idea presented.
It defines what development work should be conducted— it is the basis upon which the development team creates the final product.

When the client sends a functional specification at the cost evaluation stage, the software house may accurately estimate the expenditures required to build the product. This is the case when it is easiest to apply the valuation in the fixed price model, where the price is determined ‘in advance’ for given system functions. On the other hand, the absence of such a document incurs a high risk of wrongly estimated production resources. Overestimation or underestimation may cause a host of problems that may ensue during the course of software production.

For more on how the functional specification facilitates software evaluation, check out the article: What information does a software house need in order to assess a project?

The functional specification also helps the development team understand how the system should function, provides a guide as to what to build, and acts as a reference point during development.

Download the functional specification

How to Make a Functional Specification?

At Appchance, we often receive inquiries presenting an idea for software. We then sit down and work with the client to develop the final vision of the product along with its scope. Creating such a specification requires an in-depth knowledge of software development and an awareness of the dependencies between individual system modules as well as the interplay between the various members of the team: business analyst, UX/UI designer, and the programmers. A document prepared in this way can accurately reflect the features of the software not only in terms of the idea but also its system architecture. Therefore, it constitutes the most reliable method of building a mutual agreement, which saves time in the long run.

Of course, the client may feel free to come up with such a document independently (a process in which we currently try to assist) and, on this basis, commission the software house to make the product. Our experience, however, shows that a specification prepared in this way is less detailed than one developed in cooperation with the software house. This is the cause of further questions during the development process. Therefore, when preparing this document independently, it’s crucial to focus not only on WHAT you want to do, but HOW you would like to get there e.g. how to sort the list out, what is the character limit in a given field, what are the roles of the administration panel users and authorisations for particular roles. It is good to list any edge case, e.g. how should the application behave after a user has been banned, and then after removing the blockade. The more precisely the project is described, the lower the risk of delay in the schedule, and the greater the chance that the product delivered meets the expectations of the project owner.

Therefore, before preparing a functional specification, it is also worth designing and writing down a business model, e.g. by using the Business Canvas model and deciding whether the project will be implemented and verified in its basic form, the so-called MVP, as well as thinking through and designing the flow of applications by using, for example, user stories.

There is no doubt whatsoever that it is worth investing some of yours or the software house’s time in creating such a specification. The more work you put in at the start of the project, the less disappointment you’ll suffer during the implementation.

What Should the Specification Include?

Define the purpose of the application

What is the main idea of the application? What is it designed for and what problem does it solve?

Perhaps it is an application to streamline processes inside a company, e.g. logistics or employee management, or for external processes such as communications or sales. Define the business objective and the changes you want to see after the application is introduced. Indicate whether you are embellishing an existing application or building an entirely new product from scratch.

Specify your user

Who will use your application and why? What type of user will your clients be and what do they care about? What experiences does your app provide?

If you have a description of the people, market information about your users, behavioural analyses, or key conclusions drawn from such data, this is the moment to present them to the team so that they can come up with a better system. Describe the user type, how they figure in the system and what their key roles are.

List all the functions

What operations or actions will the user be able to perform via the application? How will the application guide the user through the necessary functions after logging in? Is there any sequence of actions that the user must follow?

Examples of functions within the application may include: logging in, browsing, comparing or buying products, tracking shipments, sending messages, receiving push notifications, and geolocation. Specify the priorities for individual functions and indicate which are crucial for the application and which are optional. Explain which elements should be included in individual screens, how they should behave, what role they play, and what form they might take.

Define integration with all the systems

Will the application have to integrate with, for example, the payment system, your CRM, social media, or other platforms? With which systems will it need to cooperate with in order to work properly?

If you have an API or hardware documentation that the application should connect with, or information about the systems with which the application should integrate with, payments for example, you need to define this in the specification.

Specify the scope of cooperation and materials provided

Which areas of the application’s development will the given software house be responsible for and which elements fall under the jurisdiction of your company or other subcontractors? Is it your responsibility to provide the API, design, mock-up or copywriting?

If you supply the necessary materials – specify in the document whether items are ready, or by when you will deliver them.

Additional information

At various stages of negotiations with a software house, additional questions may arise as well as other documents such as a brief or statement of work. These help to define the terms of cooperation, the constraints, the budget, the deadline, the project risks, how the project should proceed, the people involved, as well as the method of communication and benchmarks of other applications.

14 Questions That May Help You to Come Up With Decent Application Specifications:

Before starting to draw up the specifications of a mobile or web application, you should ask yourself the following questions:

What is the main idea of your application? What business objective does it fulfil?
Is this an application to be built from scratch or development of an existing one?
Who is the end user?
Which platform (Android, iOS, web) and system versions should the application run on?
Which devices should the application be designed for (smartphone, tablet, desktop)?
What functions should the application feature (what will the user be able to do with it)?
Will the application have features such as: login, in-app purchase, payments, push notifications, geolocation, etc.?
Will the application integrate with external systems: CMS, devices (hardware), cloud synchronization, beacons, Bluetooth, social media, etc.?
Should the application include analytical modules, e.g. Google Analytics? Will the application require in-depth analysis of user behaviour (in which case you will usually need some additional configuration in terms of Google Analytics plus implementation in the application).
What materials will the software house be provided with: design, copywriting, an API along with documentation?
Does the customer have accounts on Google Play and the AppStore or will the application be self-published?
What jobs should be done by the software house: product workshops, UX/UI design, development, tests, product development strategy, project maintenance?
What is to be excluded from the project—i.e. what goes beyond the scope of the software house’s work, e.g. tasks related to server configuration, domain and certificate installation?
What is the schedule and the planned budget?

Answers to the above questions will result in clearly specified product requirements and, therefore, a properly construed functional specification. The example below shows a table of contents from a document prepared in this way. This was the result of cooperation between the software house and the client.

*Functional Specification table of content*

As you can see, each function is a separate subchapter, so the document itself is quite extensive.

See a sample of the functional specification for an application

Download the functional specification

The specification under the development process

When building a functional specification, we should always consider which elements are essential for achieving the assumed objective. Therefore, depending on the project, the specification is less or more extensive.

It often turns out that during the product development and testing of its individual modules, the final vision of the project changes. While verifying the software, the client sees what is missing, what would be good to do differently, what should be added. In this case, the functional specification must be updated along with any new provisions.

How well a product is defined will have a bearing on whether the product will meet customer requirements. Anything left unsaid translates into future delays in the schedule, which is why it is of the utmost importance to understand each other’s intentions and scope of action.