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.Content Continues Below
Typically, the functional specification for an application program with a series of interactive windows and dialogs with a user would show the visual appearance of the user interface (UI) and describe each of the possible user input actions and the program response actions.
A functional specification may also contain formal descriptions of user tasks, dependencies on other products and usability criteria. Many companies have guides for developers that describe what topics any product's functional specification should contain.
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 is needed for a new product or a new version of an existing product. Requirements are usually expressed in terms of narrative statements and in a relatively general way.
- Objectives. Objectives are written by product designers in response to the requirements. They describe in a more specific way what the product will look like. Objectives may describe architectures, protocols and standards to which the product will conform. Measurable objectives are those that set some criteria by which the end product can be judged. Measurability can be in terms of some 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. Throughout the development process, as the need for change to the functional specification is recognized, a formal change is described in a design change request.
- Logic specification. The structure of the programming (for example, major groups of code modules that support a similar function), individual code modules and their relationships and the data parameters that they pass to each other may be described in a formal document called a logic specification. 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 of the preceding documents (except the logic specification) are used as source material for the technical manuals and online information, such as help pages, that are prepared for 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 is done 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 may 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.
- The final product. Ideally, the final product is a complete implementation of the functional specification and design change requests, some of which may 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 the outsourcing of parts 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:
- Project scope -- the goals, features, tasks, deliverables, costs and deadlines of the project.
- Risks and assumptions -- the considerations that could affect the functional design of the product.
- Product overview -- the explanation of how the application will solve a specific problem for the target audience.
- Use cases -- the functional requirements are placed in the context of a user action. This shows what happens from the user perspective.
- Requirements -- essential features of the product that explain what it does.
- Configuration -- steps needed to configure a product, such as user account setup.
- Non-functional requirements -- the non-essential features that aren’t at the core of the product.
- Error reporting -- an explanation of how the product will handle errors or exceptions.
Functional specification formats
There are several formats for a functional specification document:
- 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, non-functional 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 on a project.
Benefits of functional specifications
There are a number of benefits to creating a functional specifications document, including:
- Gives software engineers an accurate timeframe of the entire process
- Allows transparency among all the stakeholders and members of the project
- Helps non-technical 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
The following are common tools that can be used to create functional specifications documents:
- Documentation management – lets users easily create templates and render documents. Functional requirements documents are often available as document templates.
- Spreadsheet software -- allows users to 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 platform -- offers functionality for developers to capture details about requirements, use cases or user stories to incorporate into the designs of their products.
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. Software will be developed based on the functional specs.
Technical specs contain the details of how this is or can be achieved and the final product functionality details. In the case of hardware, technical specs will give the details and functionality of each component in the product.
Example of functional specification
The following is an example of a functional specification:
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 this way:
Use case: Submit Application
Description: Describes the process to submit a credit card application
- 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 an ad on a website.
Post-condition: The user receives a success message.