Construction projects that perform functional analyses and develop functional specifications often include functions in their Systems Engineering (SE) model. Identifying which functions need to be fulfilled by the system’s objects helps formulate requirements based on the functions of these objects. Ultimately, this describes the system’s desired performance. For example, it is common practice for clients to develop specifications outlining the requirements of each object, part of which are called functional requirements. These functional requirements are related to specific functions and help the reader understand the desired outcome for each object.
Based on observations at projects, the basic model consists of a type element named Function. Typically, the type element Function includes type properties to store the name and description:
- The type property Name has a Single line text data type (to contain a brief title for identifying the function).
- The type property Description has a Text data type (to provide more details on the function).
Structure
Projects often structure functions within a hierarchy called a Functional Breakdown Structure (FBS). When functions at lower levels in the hierarchy are fulfilled, this leads to fulfilling their parent functions, ultimately fulfilling the system function, which is the root function in the hierarchy.
In the model, for the type element, Function, the feature Configuration is set to Derived element. Further, the feature Origin relation is set to a type relation between the type element Function and itself; the cardinality of this relation is set to Single (e.g., with the name fulfills). This supports the creation of relations between child functions and parent functions. Automatically, the Hierarchical setting is enabled, which makes the type element Function a hierarchical derived type element. As a result, a tree view of functions becomes available in the functions overview.
Lifecycle
When tracking functions over time, it is common to add a Status property to the model with the data type set to List. Examples of list values include Actual and Rejected. This helps filter out functions that are no longer relevant.
If some functions are expected to become irrelevant to the project over time, it is helpful to configure the Status property as a Lifecycle property for the Function type element. Additionally, by enabling the Auto archive setting and selecting relevant archive values (e.g., Rejected), only relevant functions will be displayed in the views by default.
TIP: Be cautious when setting a lifecycle property for the Function type element, especially when combined with a hierarchy. Using Auto archive with a hierarchy can be problematic, as it becomes difficult to interpret child functions of an archived parent function. Therefore, it is advisable to use a lifecycle property only when there is no hierarchy or breakdown structure.
Result
The identified functions are often used as input to formulate system requirements and ultimately select a solution (i.e., the object). A system requirement specifies what the system should be able to do (i.e., the function) and how the function should be fulfilled (i.e., the object).
In the model, a type relation, describes performance to fulfill is created between the type elements System Requirement and Function. In most cases, the cardinality of this relation is set to Multi. This allows multiple functions to be related in case system requirements are more generically formulated.
Allocation
Ultimately, the object specified by the system requirement fulfills the function described by the system requirement. While you can indirectly determine from the system requirements which object fulfills a function, some projects prefer directly relating an object to a function. For example, in addition to deriving functions from other functions, projects may also derive functions from the hierarchy of objects, known as the System Breakdown Structure (SBS). In such cases, a direct relation could be established for traceability.
In the model, a type relation, fulfills, is created between the type elements Object and Function. In most cases, the cardinality of this relation is set to Multi, allowing for the reuse of functions to be fulfilled by solutions (i.e., objects).
TIP: Be cautious when using direct relations between objects and functions in the SE model, when system requirements are already directly related to both functions and objects, as this can lead to redundancy and discrepancies.
