Requirements management in GENESYS differs from approaches used by other systems engineering tools, modeling or architecture tools, and databases. In keeping with academic and INCOSE processes, GENESYS leverages the full power of MBSE for requirements management using its systems metamodel as a guide. (See: What is the Difference Between a System Model and a Systems Metamodel?) The systems metamodel is instantiated in GENESYS as the database “schema” of a framework on which each model is built. In GENESYS, there is a specific process for handling source requirements, refining source requirements to be clear, concise, and testable, and finally deriving functional, performance and non-functional system requirements.
With MBSE based on a systems metamodel, MBSE tools can be more integrated, allowing us to be more rigorous and deliberate with the requirements management process.
The Basics
In a world without a requirements database, we wrote requirements in a document. When requirements were changed or updated, changes were made to the document and a new document was released. We could track changes to the requirements by examining the revision history of the document. Similarly, in a database-oriented way of doing requirements management, we recorded requirements in a database. The database would track changes to the requirements, and new documents could be produced on demand with the requirement updates. We could track changes to a requirement by querying the revision history of the requirement within the database.
In GENESYS, MBSE is based on a systems metamodel that unites modeling with database storage. GENESYS records requirements, not as simple text, but rather, treats source requirements as a root node in a hierarchy of refined requirements. We can view and query the hierarchy to see the evolution of the requirement.
Building a Requirements Hierarchy
In GENESYS, requirement hierarchies can be constructed using the “refines/refined by” relationship to create a parent-child relationship between two requirements as shown in Figure 1.
Figure 1. Developing a Requirements Hierarchy
The way we create a parent-child relationship should be a conscious decision that is governed by two important Requirement class attributes: Origin and Type.
The Origin attribute is used to designate whether the requirement has been imposed on the system by stakeholders, or has been inferred by systems engineers from another requirement. The Origin attribute has three designated values: Originating, Derived, and Design Decision. All “originating requirements” are intended to be marked as “Originating” in the Origin attribute of a requirement entity. For a program manager, originating requirements may be provided in the form of needs and objectives expressed by stakeholders. For a project manager, originating requirements may be provided by program management. For a contractor, originating requirements may be contained in a contractual specification. Each originating requirement, as provided by stakeholders, forms the root parent for a hierarchy to follow.
The Type attribute in GENESYS has seven designated values used to specifically categorize requirements: Functional, Performance, Constraint, Programmatic, Test, Verification, and Composite. All originating requirements should be evaluated and classified according to these types.
Dealing with Composite Requirements
Originating requirements as provided to the systems engineer vary as to their quality. Many may not be phrased or constructed according to best practices, so the first step is to deconstruct and improve requirements. Rather than merely rewrite the requirement or add new ones, we use the “refines/refined by” relationship to track the evolution of the requirement throughout the systems engineering journey. The first step is to identify composite requirements—those requirements with compound statements or lists.
We deal with composite requirements by breaking them into two or more requirements. But rather than deleting the original requirement, we keep that requirement and set the Origin attributes as “Originating” and the Type attribute as “Composite.” New requirements are then created from it and related as child entities with the Origin attribute set as “Originating,” since no change has been made to the underlying purpose or authority of the requirement. With these requirements focused on single ideas or capabilities, the Type attribute may be set according to the nature of the requirement. Figure 2 shows an example of a composite requirement and three refined child requirements with the Type attribute set as Functional.
Figure 2. Deconstructing a composite, originating requirement
When necessary, we can improve a requirement, clarifying any vague statements, adding new requirements to the hierarchy, and also using the “refines/refined by” relationship. An example of using the hierarchy to record the newly “improved” requirements is shown in Figure 3. Here, requirement X, refined from a composite requirement, is still vague in some respects. A systems engineer refines the requirement further by creating a new requirement with more clarity and associating the requirement with the vaguer version using the “refines/refined by” relationship. The process can be further documented by generating a Concern from the vague requirement and adding a “results in” relationship to the improved requirement.
Figure 3. Improving on a vague originating requirement
Aligning a Functional Design with Derived Functional Requirements
Once we have cleaned up our set of originating requirements, we can further elaborate our system design. This process is iterative and proceeds to expand the granularity of the model layer by layer.
Based on our originating requirements, we may develop a high-level functional design of our system and relate that to our requirements, as shown in Figure 4.
Figure 4. High-level functional design (based on originating requirements)
Suppose we further identify the functionality necessary in accomplishing functions X, Y and Z. Figure 5 depicts a notional decomposition of Function X.
Figure 5. Decomposition of a high-level functional design
We now must add derived requirements to our requirements to account for the newly identified functionality. An updated requirements hierarchy is depicted in Figure 6, showing requirements for functions X.1, X.2 and X.3. The Origin attribute is set to “Derived,” and the Type set as “Functional.” The Origin attribute is set to “Design Decision” if the requirement came as a result of a specifically defined Risk or Concern, and is identified by the “results in/result of” relationship.
Figure 6. Creating derived requirements based on the updated functional design
Mapping Functional Requirements to the Functional Design
Finally, we can relate functions and requirements using the “basis of” relationship as show below in Figure 7. In this example, the relationships are shown as 1 to 1, when in reality with more complex behavioral models, there may be a many to many mapping.
Figure 7. Mapping requirements to the functional design
We can view the resulting mapping in the following hierarchy. Figure 8 shows the refinement of the requirements X, Y and Z, including new sub-functions. Each function also becomes the basis of the associated requirement.
Figure 8. A requirements hierarchy showing refinement of originating requirements and mapping to the functional design
Eliminating Duplicative Efforts
It may look like in the above exercise that we are duplicating efforts, and we are. Based on a given set of requirements, we derive functionality and then follow up with a refined functional requirement, with the Type attribute set to Derived. To streamline the approach and eliminate the duality, we can use a new approach. We can use the Description attribute of the function to record the statement of the functional requirement.
Figure 9 shows the resulting requirements hierarchy. Given the simplified functional design, each leaf requirement becomes the basis of an equivalent function, and the function becomes the root node for the sub-functions, now phrased as requirements. Vitech recommends this latter approach to managing functional requirements. Duplicative efforts are reduced and the functional design is fundamentally integrated into the functional specification.
Figure 9. A simplified requirements hierarchy using functions in the functional design to also track functional requirements
Summary
The Vitech systems metamodel is the basis for the schema used in each GENESYS project. Using the systems metamodel enforces a more rigorous and visible approach to requirements management. Requirements are specifically called out as to their origin, thereby facilitating audit-trails. The source requirements can be improved further by deconstructing composite requirements and making the requirements clear, concise, and testable.
A requirements hierarchy is constructed via the “refines/refined by” relationship to show the evolution of the originating source requirements. The requirements hierarchy can be extended further to include derived requirements aligned with the functional design. The GENESYS approach also allows the functions in the functional design to contain requirements statements to reduce duplication of effort and eliminate the need to track separate requirement and function entities. This is all thanks to an MBSE solution powered by a systems metamodel.
