Intent
Functional thinking allows you decouple your product description from specific technologies.
Motivation
In order to "future-proof" your product, decouple technology from what your product actually does. For instance, your product may have a display. If you developed it 30 years ago, it probably had a cathode-ray tube, later an LCD display and maybe today an LED display. But the underlying function stayed the same.
Applicability
This pattern can be applied on many levels, from the stakeholder level ("The vehicle provides transportation"), to the lowest level (control engine torque). Of course, at some point you need to make specific technology decisions. Also, be careful that often, the competitive advantage does not stem from the function ("The car must be racy").
Structure
A common approach is to follow ISO/IEC/IEEE 29148-211, which asks for "Operational Requirements" on the stakeholder level and "Functional Requirements" on the systems level.
Consequences
The pattern has the following benefits and liabilities:
- Benefits:
- System description in a technology-neutral fashion
- Liabilities:
- It is possible to loose sight of the stakeholder benefits
Implementation
In its simplest form, your data model explicitly acknowledges the existence of functions or functional requirements:
Keep in mind that a functional description can take many forms. A use case, for instance, can also be considered (see Modeling Requirements with Constraints)
Related Patterns