Functional specification

Systems engineering model of Specification and Levels of Development. During system development a series of specifications are generated to describe the system at different levels of detail. These program unique specifications form the core of the configuration baselines. As shown here, in addition to referring to different levels within the system hierarchy, these baselines are defined at different phases of the design process.Note: There is one minor (and ironic) typo in the image above. SI&T is "System Integration and Test" not "System Integration and Text".

A functional specification (also, functional spec, specs, functional specifications document (FSD), functional requirements specification) in systems engineering and software development is a document that specifies the functions that a system or component must perform (often part of a requirements specification) (ISO/IEC/IEEE 24765-2010).^[1]

The documentation typically describes what is needed by the system user as well as requested properties of inputs and outputs (e.g. of the software system). A functional specification is the more technical response to a matching requirements document, e.g. the Product Requirements Document "PRD"^{[citation needed]}. Thus it picks up the results of the requirements analysis stage. On more complex systems multiple levels of functional specifications will typically nest to each other, e.g. on the system level, on the module level and on the level of technical details.

Overview

A functional specification does not define the inner workings of the proposed system; it does not include the specification of how the system function will be implemented.

A functional requirement in a functional specification might state as follows:

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.

Functional specification topics

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.

To let the developers know what to build.
To let the testers know what tests to run.
To let stakeholders know what they are getting.

Process

In the ordered industrial software engineering life-cycle (waterfall model), functional specification describes what has to be implemented. The next, Systems architecture document describes how the functions will be realized using a chosen software environment. In non 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.

Methods

One popular method of writing a functional specification document involves drawing or rendering either simple wire frames or accurate, graphically designed UI screenshots. After this has been completed, and the screen examples are approved by all stakeholders, graphical elements can be numbered and written instructions can be added for each number on the screen example. For example, a login screen can have the username field labeled '1' and password field labeled '2,' and then each number can be declared in writing, for use by software engineers and later for beta testing purposes to ensure that functionality is as intended. The benefit of this method is that countless additional details can be attached to the screen examples.

Examples of functional specifications

Types of software development specifications

References

^ ISO/IEC/IEEE 24765:2010 Systems and software engineering — Vocabulary

External links

Painless Functional Specifications, 4-part series by Joel Spolsky

[1] ISO/IEC/IEEE 24765:2010 Systems and software engineering — Vocabulary

[1]

v t e Systems engineering
Subfields	Aerospace engineering Biological systems engineering Cognitive systems engineering Configuration management Earth systems engineering and management Electrical engineering Enterprise systems engineering Health systems engineering Performance engineering Reliability engineering Safety engineering Sociocultural Systems Engineering
Processes	Requirements engineering Functional specification System integration Verification and validation Design review System of systems engineering
Concepts	Business process Fault tolerance System System lifecycle V-Model Systems development life cycle
Tools	Decision-making Function modelling IDEF Optimization Quality function deployment System dynamics Systems Modeling Language Systems analysis Systems modeling Work breakdown structure
People	James S. Albus Ruzena Bajcsy Benjamin S. Blanchard Wernher von Braun Kathleen Carley Harold Chestnut Wolt Fabrycky Barbara Grosz Arthur David Hall III Derek Hitchins Robert E. Machol Radhika Nagpal Simon Ramo Joseph Francis Shea Katia Sycara Manuela M. Veloso John N. Warfield
Related fields	Control engineering Computer engineering Industrial engineering Operations research Project management Quality management Risk management Software engineering
Category