Definition:
Concept Number: *074
English Master: Function Requirement
Synonyms, Variations & Acronyms: none
Detailing
A Function-Requirement is Binary, and can either be a specific Function-Target or a Generic Function-Constraint.
Illustrations
none
Type
Examples
Voice Recognition: Type: Function-Requirement. Definition: The ability to recognize a human voice in terms of vocabulary and individual voiceprints.
''Step 1: Step: Voice Recognition [Europe, If Company C has this Function on the market].
Voice Recognition is defined as a Function. It is then “required” to be delivered in Evo-Step “Step 1”, only in “Europe” and only if “Company C has this Function on the market”. A Specific-Design to implement Voice Recognition at specified performance Levels and costs needs to be specified.''
Notes
1. Do not include technical Design-Ideas in Function-Requirements. Designs are quite different from Functions. If designs are mandatory, then they should be specified as Design-Constraints. A Function is an abstract Concept specifying activity of some kind, which is implemented by a design. For example: An accounting application (a design) provides a Solution to support Maintaining Accountancy Information (a defined Function).
2. Distinction should be made between a Function-Target and a Function-Constraint. A Function-Constraint implies that a Function must be present or absent (subject to its Qualifier Conditions) in a System, or a penalty of some kind will be incurred.
3. By Default, if there is no information that a Function-Requirement is actually a Function-Constraint, or “Type: Function-Constraint” specification, a Function-Requirement is assumed to be a Function-Target.
4. To Authority Levels, which are lower than the one that specified it, a Function-Target does become mandatory. If a lower Authority disagrees with a Requirement they have to take the Issue up with the higher Authority.
5. A Function-Requirement is satisfied by any design, which meets the Function description. For example, {transport via a bridge, transport by air, transport across water} all meet the Function-Requirement “to transport people from shore to shore of a river”. Note, in this example, the designs are High-Level and are actually Functions. They can be termed “Function-Designs.” A lower, more specific Level of design {by public transport over a bridge, by hot-air balloon, by canoe} can also be considered.
6. At the early rough stages of design, Function-Requirements are best satisfied by rough Function-Designs (like “bridging the river”). At the latter stages of design, Specific-Designs are better, like “rope bridge.” The Issue is that the more specific a design is, the less freedom of design choice remains, but the greater the knowledge of its attached performance and Resource Attributes. For example the Product-Value Attributes of a software package selected to satisfy the Function-Requirement, like reliability and portability.
7. Note: Functionality is one of the six characteristics for internal and external Quality in ISO/IEC 9126-1 [ISO/IEC 25010]. Functionality Requirements should not be confused with Functional Requirements. Functionality Requirements specify the Product-Value of the Functional Requirements and include Requirements for the software Product to be suitable, accurate, interoperable, secure and compliant with relevant Functional Standards and regulations. <- ISO/IEC JTC1/SC7 N2981 2004-01-22 Document Type 2 nd CD ballot Title Second CD Ballot, CD 25030.2: Software-Engineering – Software Product-Value-Requirements and evaluation (SQuaRE) – Product-Value-Requirements
Keyed-Icons
The parentheses symbolizes the oval icon.
An alternative is O.@ “A Function-Target."
Drawn-Icons
Any oval shape.
Related-Concepts
Function-Constraint
Function-Requirement
Target
Function
History-of-Concept
none
This Concept entered by Diane O'Brien.