Functional specification
From Wikipedia, the free encyclopedia
In software development, a functional specification (also, functional spec or specs or functional specifications document (FSD) or Program specification) is the set of documentation that describes the requested behavior of an engineering system. The documentation typically describes what is needed by the system user (design-goal), which internal functions are necessary, as well as, requested properties of inputs and outputs (for ex. of the software system. As a design document, a functional specification does not typically define the inner workings of the proposed system, it means it does not yet include the specification how the system function will be implemented. Instead, it focuses on what various outside agents (people using the program, computer peripherals, or other computers, for example) might "observe" when interacting with the system.
A typical functional specification might state the following:
When the user clicks the OK button, the dialog is closed and the focus is returned to the main window in the state it was in before this dialog was displayed.
Such a requirement describes an interaction between an external agent (the user) and the software system. When the user provides input to the system by clicking the OK button, the program responds (or should respond) by closing the dialog window containing the OK button.
It can be informal, in which case it can be considered as a blueprint or user manual from a developer point of view, or formal, in which case it has a definite meaning defined in mathematical or programmatic terms. In practice, most successful specifications are written to understand and fine-tune applications that were already well-developed, although safety-critical software systems are often carefully specified prior to application development. Specifications are most important for external interfaces that must remain stable.
Contents |
[edit] Purpose
There are many purposes for functional specifications. One of the primary purposes on team projects is to achieve some form of team consensus on what the program is to achieve before making the more time-consuming effort of writing source code and test cases, followed by a period of debugging. Typically, such consensus is reached after one or more reviews by the stakeholders on the project at hand after having negotiated a cost-effective way to achieve the requirements the software needs to fulfill.
[edit] Process
In the ordered industrial software engineering life-cycle (waterfall model), functional specification describes what has to be implemented. The next system specification document describes how the functions will be realized using a chosen software environment. In not industrial, prototypical systems development, functional specifications are typically written after or as part of requirements analysis.
When the team agrees that functional specification consensus is reached, the functional spec is typically declared "complete" or "signed off". After this, typically the software development and testing team write source code and test cases using the functional specification as the reference. While testing is performed the behavior of the program is compared against the expected behavior as defined in the functional specification.
[edit] See also
- AMBA specification
- Bit specification
- Design specification
- Diagnostic design specification
- Extensible Firmware Interface
- Multiboot Specification
- Product design specification
- Real-time specification for Java
- Software development process
- Software Requirements Specification
- Specification (technical standard)
- Single UNIX Specification
- Verification and Validation (software)
- XML Paper Specification