All Functions have Stakeholder-Values or Product-Values attached to them describing the 'how well' aspect of the Function.
A Function is Binary, i.e. it either does it or it does not do it.
A Function is always expressed in Action (“to do”) terms (for example, “to span a gap” and “to manage a Process”).
.ProduceRep: Produce a report.
.Deliver: Deliver the report to the desk.
Sometimes, for simplification, I express the Function as what it is (not what it does). The Function of a television is to receive and display movies, images and sound. I usually just define the Function as Television. A car is a car, a truck is a truck and a laptop computer is a laptop computer. At other times there is a need to express the actual pure form of ‘what it does’.
1. A Function has a corresponding implied purpose. For example “to span a gap” usually has as an implied purpose to enable something to get from point A to point B over the gap.
2. Function is a fundamental part of a System description: a System Consists-of Function Attributes, performance Attributes, Resource (Cost) Attributes and design Attributes. All Attributes exist with respect to defined specified Conditions.
3. All the System Attributes must be described together, in order to fully understand a real world System. Function is a “pure” Concept, which cannot exist in the real world alone. Functions need to have associated with them, the relevant performance and Resource Attributes.
4. Function is a System Attribute that is expressed without regard to the related performance, Cost and design. A Function needs to be clearly distinguished from Design-Ideas. Design-Ideas are a real world method for delivering all the Function, performance and Cost Attributes of a System.
5. Function itself is Binary. Function in a System is either implemented or not. It can be tested as present or not. Any real implemented Function will have some associated performance and Cost Attributes – whether we planned for them or not. Once a design with the required Functionality is specified (or later implemented), we need to consider whether that particular design has satisfactory performance and Resource (Cost) Attributes. In other words, we control these Scalar attribute”s Levels mainly by specifying appropriate design options, which deliver the required performance and Cost-Levels.
6. A Function can often be decomposed into a hierarchical set of sub-functions. For specification Clarity, prefixes such as “sub-”, “supra-” or, “family” relationships (such as kid, Parent, Sibling) can be used to express the relationships amongst the different Functions. Alternatively, the Parameters, Includes, Is-Part-Of and Consists-of can be used. 7. I have intentionally chosen the term “function” as the adjective for “function” (for example, in “function specification” and “Function-Requirement”), rather than the more common “functional.” It is the “Requirement for function” that is being expressed, rather than “making the Requirements Functional.” The logic of this choice is the same as for choosing “Product-Value” (for example, in “Product-Value-Requirements), rather than “qualitative.”
( ) In Context: ---> ( < Function Tag > ) --->
An oval (A circle would also be considered a Function.)