Requirements management is made easier when model-based systems engineering is based on a systems metamodel. An MBSE tool with a systems metamodel behind it is thoroughly integrated, allowing us to be more rigorous and deliberate in our systems engineering efforts. Last month, I discussed the process of refining requirements using MBSE to break up composite requirements into requirements focused on a single subject. (See Managing Functional Requirements with GENESYS.) I also showed how to properly map functional requirements to the functional (logical) design using the systems metamodel.
This month, I’ll discuss how the systems metamodel supports management of performance and constraint requirements. In all cases, we use the Type attribute of the Requirement class to indicate whether the requirement is a composite, functional, performance, or a constraint requirement.
Functional and Performance Requirements
Recall from the systems metamodel that functional requirements are the basis of functions of our logical design as indicated in Figure 1. We use the systems metamodel relationship basis of to map functional requirements to the associated function. Allocating functional requirement to functions rather than components helps us focus on developing the behavior necessary for our system independent of the final physical design solution.
Also, as indicated on the right in Figure 1, we use the systems metamodel relationship specifies to map performance requirements to Functions. Associating performance requirements to the functions of the logical design enforces the notion that performance is fundamentally behavioral and not physical. It is the logical domain, both in terms of functionality and performance, that drives the selection of the components in the physical design.
Figure 1. Allocating functional requirements to Functions
If we find ourselves thinking of performance in the physical dimension, we fall into the trap of pre-supposing a design solution. Using the systems metamodel as a guide can help us avoid these traps.
Constraint Requirements
Constraint requirements, however, are physical in nature. If we have a reliability requirement for example, it does not affect the fundamental function of the system. It does not affect what the system must do (i.e. send messages), or how well it must perform (i.e. message rate). Reliability is fundamentally defined by the characteristics of the components we choose to include in the physical design.
The systems metamodel supports the notion of mapping constraint requirements to Components by using the specifies relationship, as shown in Figure 2. For example, we can specify the size, weight and power of certain components in our physical design.
Figure 2. Specifying Components, Links, Ports and Items with constraint requirements
Additionally, constraint requirements can specify other aspects of the physical design. Ports that are exposed by Components, or Links that connect Components, can also be specified by constraint requirements. For example, a constraint requirement may specify that a certain link use the TCP/IP communication protocol. The formatting standards of items may also be specified using constraint requirements.
Refining and Mapping Constraint Requirements
Another important aspect of constraint requirements is how we derive new requirements for deeper parts of our physical design. While functional and performance requirements should align to the functional design (as I described in last month’s post), there are two options for constraint requirements. First, as we did for functional requirements and the logical design, we can align the derived constraint requirements with our physical design.
For example, as depicted on the left in Figure 3, if we are designing an electric vehicle and we have originating requirements that the vehicle shall attain certain levels of mileage per charge, we as systems engineers may derive a requirement (using the refines relationship, and by setting the Origin attribute to “Derived.” Note that we set the Origin attribute to ”Design Decision” if a formal trade study occurred as a result of a Concern) for the total weight of the system necessary to achieve mileage constraints.
Next, we map the constraint requirement for weight to the component representing the system-under-development using the specifies relationship. Similarly, we derive additional constraint requirements for each subsystem of the design such that, layer by layer, constraint requirements for weight are derived and mapped to each component of the system.
Figure 3. Deriving constraint requirements layer by layer
Alternatively, to avoid having to create arbitrarily derived requirements, we can simply derive constraint requirements where it makes sense, as depicted on the right in Figure 3. For example, if we have an originating, system level weight requirement, but no requirements are necessary to constrain each of the segments, we can simply map both the system component and each of the segment components to the originating requirement, while deriving requirements for important components in lower levels of the design. (Note: You can use the BasicArchitectureRollup script to sum all leaf level weight parameters to come up with a total system weight.)
Figure 4. Inserting parameter values into a requirements statement
Using Parameters
We can also make use of parameters to augment or replace our performance and constraint requirements. A typical requirements entity is shown in Figure 4 as it would appear in GENESYS. By selecting the “Insert Parameter” menu option from the right mouse click, we can insert parameter values for important metrics such as weight or volume. When we update the parameter, the requirement statement is also updated, saving the effort of tracking the same data point more than once.
While we typically think of requirements as a fundamental idea in systems engineering, with MBSE we find that we can consolidate our information by incorporating our requirements into our logical and physical design, also saving the effort of tracking the same information in more than one place.
We can record our functional requirements in the description attributes of the function in the logical model. The parameters of the functions can be used to record the performance requirements as shown in Figure 5. For example, we have noted that the system shall have a stopping distance of 180 feet when travelling at 60 mph.
Figure 5. Using parameters of Functions to record performance requirements
Similarly, we can record constraint requirements using parameters on the components of the physical design, as shown in Figure 6. Here, there is an implied requirement that the system shall have a weight between 3,000 and 3,200 lbs.
Figure 6. Using parameter of Components to record constraint requirements
Summary
A requirements hierarchy is constructed via the refined by relationship to show the evolution of the originating source requirements. Functional requirements may be mapped to functions using the basis of relationship, and constraint requirements may be mapped to elements of the physical design (components, links, ports, and items) using the specifies relationship. Also, hierarchies of constraint requirements can be derived and either aligned directly, layer by layer, to the physical design, or aligned on a case-by-case basis. Finally, parameters may be used in both cases to replace the requirements and implicitly specify the design.
Adding this extra level of rigor to our requirements management process helps us to think in all three perspectives (functional, performance and constraint) and to be aware of how the logical design informs our physical design. In the end, we clarify our thinking, get a more complete set of requirements, reduce gaps in our design, and ultimately develop a better product.
If you have any questions about how to effectively perform requirements management in GENESYS, feel free to contact me at mark.simons@vitechcorp.com.
