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:
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.
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 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.
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.
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.
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.
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.
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.
Before starting to draw up the specifications of a mobile or web application, you should ask yourself the following questions:
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.
As you can see, each function is a separate subchapter, so the document itself is quite extensive.
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.