Content deleted Content added
Jnestorius (talk | contribs) |
|||
(19 intermediate revisions by 15 users not shown) | |||
Line 1:
{{Short description|Type of document}}
{{Refimprove|date=October 2008}}
[[Image:Specification and Levels of Development.jpg|thumb|360px|Systems engineering model of
{{software development process}}
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).<ref>[http://www.iso.org/iso/catalogue_detail.htm?csnumber=50518 ISO/IEC/IEEE 24765:2010 Systems and software engineering — Vocabulary]</ref>
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 [[
==
A [[function (engineering)|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:
Line 14 ⟶ 15:
:''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 (computing)|user]]) and the software system.
==
===
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 case (software)|test case]]s, followed by a period of [[debugging]].
# To let the [[
# To let the [[testers]] know what tests to run.
# To let [[Stakeholder (corporate)|stakeholder]]s know what they are getting.
===
In the ordered industrial software engineering life-cycle ([[waterfall model]]), functional specification describes ''what'' has to be implemented. The next, [[
When the team agrees that functional specification consensus is reached, the functional spec is typically declared "complete" or "signed off".
===
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.
==
* [[Advanced Microcontroller Bus Architecture]]
* [[Extensible Firmware Interface]]
* [[Multiboot
* [[Real-time specification for Java]]
* [[Single UNIX Specification]]
==
* [[Bit specification (disambiguation)]]
* [[Design specification]]
* [[Diagnostic design specification]]
* [[Product design specification]]
* [[Software
==
* [[Benchmarking]]
* [[Software development process]]
* [[Specification (technical standard)]]
* [[Software verification and validation]]
==
{{reflist}}
==
* [http://www.joelonsoftware.com/articles/fog0000000036.html Painless Functional Specifications, 4-part series by Joel Spolsky]
Line 70 ⟶ 71:
[[de:Pflichtenheft]]
[[hr:Specifikacija programa]]
[[pt:Especificação de programa]]
|