A functional specification is a formal document used to describe a product's intended capabilities, appearance and interactions with users in detail for software developers. The functional specification is a kind of guideline and continuing reference point as the developers write the programming code.
The method of preparing the specifications before the product is known as "write the manual first" approach, serving as an outline of the finished program.
Typically, the functional specification for an application program with a series of interactive windows and user dialogs would show the visual appearance of the user interface (UI) and describe each of the possible user input actions and program responses.
A functional specification might also contain formal descriptions of user tasks, dependencies on other products and usability criteria. Many companies have developer guides that describe what topics any product's functional specification should contain.
Where does a functional specification fit in the development process?
For a sense of where the functional specification fits into the development process, here are a typical series of steps in developing a software product:
- Requirements. This is a formal statement of what the product planners -- informed by their knowledge of the marketplace and specific input from existing or potential customers -- believe a new product or a new version of an existing product needs. Requirements include a series of relatively general narrative statements.
- Objectives. Product designers write objectives in response to the requirements. They describe what the product will look like in more detail. Objectives might describe application architecture, protocols and standards to which the product will conform. Measurable objectives set some criteria by which the end product can be judged, such as an index of customer satisfaction or in terms of capabilities and task times. Objectives must recognize time and resource constraints. The development schedule is often part or a corollary of the objectives.
- Functional specification. The functional specification -- called "functional spec" or just "spec" for short -- is the formal response to the objectives. It describes all external user and programming interfaces that the product must support.
- Design change requests. Design change requests describe the formal changes to the functional specification when teams decide to implement them.
- Logic specification. Logic specifications are formal documents that detail the programming structure -- for example, major groups of code modules that support a similar function -- individual code modules, their relationships and the data parameters they pass to each other. The logic specification describes internal interfaces and is for use only by the developers, testers and, later, to some extent, the programmers that service the product and provide code fixes to the field.
- User documentation. In general, all the preceding documents except the logic specification are source material for the technical manuals and online information -- such as help pages -- aimed at the product's users.
- Test plan. Most development groups have a formal test plan that describes test cases that will exercise the programming that is written. Testing occurs at the module -- or unit -- level, at the component level and at the system level in context with other products. This can be thought of as alpha testing. The plan might also allow for beta test. Some companies provide an early version of the product to a selected group of customers for testing in a real-world situation.
- Final product. Ideally, the final product is a complete implementation of the functional specification and design change requests, some of which might result from formal testing and beta testing.
The cycle is then repeated for the next version of the product, beginning with a new requirements statement, which ideally uses feedback from customers about the current product to determine what customers need or want next.
Most software makers adhere to a formal development process similar to the one described above. The hardware development process is similar but includes some additional considerations for parts outsourcing and verification of the manufacturing process itself.
How to write a functional specifications document
Depending on the project and the team, a functional specification could include the following:
- Project scope. This includes the goals, features, tasks, deliverables, costs and deadlines of the project.
- Risks and assumptions. These include considerations that could affect the functional design of the product.
- Product overview. The product overview explains how the application will solve a specific problem for the target audience.
- Use cases. In use cases, the functional requirements are placed in the context of a user action. This shows what happens from the user perspective.
- Requirements. The requirements are the essential features of the product that explain what it does.
- Configuration. These are the steps needed to configure a product, such as user account setup.
- Nonfunctional requirements. These are the nonessential features that 'aren't at the core of the product.
- Error reporting. This section explains how the product will handle errors or exceptions.
What are the different functional specification formats?
There are several formats for a functional specification document, including the following:
- Business requirements document (BRD). This document describes the business and stakeholder. It also describes the high-level goals an organization is trying to achieve or the needs 'it's trying to fulfill by developing a service or product.
- System requirements specification (SRS). This details what requirements must be fulfilled to satisfy the needs of the business. As a structured document, the SRS describes the functional requirements, nonfunctional requirements and any use cases that the software must fulfill.
- Functional requirements document (FRD). The FRD describes exactly how the system should function to meet all the requirements noted in the BRD and SRS. The FRD expands on all the details pertaining to the functional requirements of a project.
Benefits of functional specifications
There are a number of benefits to creating a functional specifications document, including the following:
- Gives software engineers an accurate timeframe of the entire process.
- Allows transparency among all the stakeholders and members of the project.
- Helps nontechnical project members understand various testing and development processes.
- Helps determine whether the application is providing all the functionalities mentioned in the functional requirement of the specific application.
- Helps define the functionality of a system or one of its subsystems.
- Supports user tasks, goals or activities for easy project management.
- Provides a standard for change control.
Tools used for functional specifications
Organizations can use the following tools to create functional specifications documents:
- Documentation management. This lets users create templates and render documents. Functional requirements documents are often available as document templates.
- Spreadsheet software. This lets users add columns as needed. In addition, it's not necessary to write perfect sentences. Users can just capture the key information a developer needs to build the correct product.
- Agile project management platforms. These offer functionality for developers to capture details about requirements, use cases or user stories to incorporate into their product designs.
Difference between functional specifications and technical specifications
Functional specs are based on the business requirements and contain the details of end-user expectations of the functionality of the product.
Technical specs contain the details of how functional goals can be achieved and the final product functionality details. In the case of hardware, technical specs give the details and functionality of each component in the product.
Example of functional specification
The following is an example of a functional specification in the form of a use case diagram and its composite parts.
Use case diagram. This helps depict the interaction between the system and its users. Every user role is called an "actor" and the different functions or processes are represented in the diagram. Each of these can be broken down into steps that include the "happy path," i.e., the default scenario or the most likely positive alternative featuring no exceptional or error conditions, as well as alternative paths.
It breaks down the following way:
- Use case. Submit Application.
- Actor. Customer.
- Description. Describes the process to submit a credit card application.
- Successful completion. The user enters application information, including birth date. The system validates the input for any errors in data entry. The system then submits the application.
- Alternative. The system rejects the application submission, citing an error in the form for the birth date.
- Pre-condition. The user has been directed to the application for the credit card from an ad sent via email or on a website.
- Post-condition. The user receives a success message.
- Assumptions. None.