Requirements Analysis Using Model-Based Systems Engineering

Whether we realize it or not, our brains will consider behavior when contemplating requirements. How, then, can we formalize this process? How do we ensure we address the functionality of our systems as we consider requirements? As systems engineers, we develop a mental model of requirements analysis based on the general concepts we learn in the workplace or through education. We learn to develop a hierarchy of system requirements and trace those requirements to the elements of our system design—both functional and physical. These concepts can be made more precise through definition of a systems metamodel that underlies your MBSE implementation.

A systems metamodel allows engineers to share their mental models of systems engineering processes, including requirements analysis. Using a systems metamodel, systems engineers can better capture and integrate design details, history, and rationale. A systems metamodel is at the foundation of all Vitech tools and helps form the framework of the underlying database, allowing the tools to fully address all aspects of systems engineering. Without a unifying systems metamodel, design details may be implemented in unconnected tools and sometimes even lost entirely. The portion of the systems metamodel dealing with requirements helps engineers tie requirements to aspects of the system design.

In this post, I will first discuss why requirements are even necessary. I will then discuss how requirements analysis is conducted at certain phases of the system lifecycle. Finally, I will discuss the systems metamodel and how it can be used to tie requirements, behavior and design to improve the quality of the requirement set.

The Necessity of Requirements
If modelling behavior and developing solutions are the fun part of systems engineering, requirements can be the necessary evil that forces us to align (and yes, sometimes constrains) our engineering efforts to the overall purpose. On the positive side though, requirements help guide development and provide a baseline on which we can measure our progress.

I see two basic situations where developing requirements is necessary. First, the engineering effort is being conducted in the context of preparing a contract statement of work (SOW) or some equivalent. Second, the engineering effort is being conducted in the context of responding to a contract SOW. In a third situation, developing requirements may not be necessary, but is still recommended. This situation arises when a contract is not involved, and the development effort is being conducted in-house with company or organizational funds. In this situation, the engineering effort is guided by a company thought leader, engineer, or manager who may choose to use requirements to guide development or some other process or approach for the development of a system.

Requirements Analysis and the System Lifecycle
Requirements analysis occurs at certain stages in the system lifecycle. I would like to call attention to three areas.

• Developing Operational Requirements – During conceptual development early in the system lifecycle, systems engineers are trying to understand the operational environment of the system. Systems engineers start by identifying operational needs, defining operational concept(s), and analyzing the operations to define requirements that a new system or process must achieve to be effective. The focus in this situation is on the operational performance of the system, or systems of systems.
• Developing System Requirements – In later phases of the systems lifecycle, system engineers are addressing how a system (as a whole) may be developed to meet the operational objective defined in the operational requirements. The focus here is on the system itself at its highest level of abstraction, rather than the operational context. A systems of systems engineering effort may spawn a number of such activities.
• Developing Subsystem Requirements (and more) – As the system design is fleshed out and more detail of the system design is being developed, a systems engineer is focused on a single sub-system (or a single component of a system). Requirements analysis may be applied at any layer of the system decomposition. The job may be to develop sub-system requirements, segment requirements, or even assembly or part requirements.

Let me explain further.

Operational Requirements
Systems engineers will find themselves in this phase of the lifecycle if they are working in-house, or if they are a contracting organization preparing a request for proposal. This is an exciting, creative time in the engineering process, with fewer boundaries and constraints. The main goal is to provide a benefit to a potential user or customer envisioned for your system. This is a highly entrepreneurial stage of system development where creative thinking can come up with novel approaches for solving real-world problems. This is also an especially trans-disciplinary effort that may involve people with diverse experience, skill sets and education. Sometimes, these “operational” requirements may be developed by an external community, such as a scientific group developing requirements. They also may come in many forms, such as scientific requirements, mission requirements, or capability requirements.

System Requirements
In this this next phase of the lifecycle, systems engineers translate operational requirements to high-level system requirements. In this setting, systems engineers may be focused on multiple system concepts and/or charged with developing a set of system-related requirements at the highest level of abstraction. The systems requirements can be used to develop criteria for analyses of alternatives (AoA) studies that select a preferred system concept to meet the operational requirements.

Subsystem Requirements
In later stages of the lifecycle during system design, systems engineers are using a set of system requirements at some level of detail and forming requirements for a component in the next deeper layer of the system design. For example, an engineer working on a subsystem of a system will take system requirements and derive necessary requirements to drive development of the subsystem; an assembly engineer may take subsystem requirements and derive assembly requirements, and so forth. At this stage, the requirements hierarchy and the associated specification tree begins to form.

A Systems Metamodel for Requirements Analysis
The systems metamodel defines relationships between classes of elements. In addition to relationships, classes in the systems metamodel also have attributes and parameters. Figure 1 shows the classes and relationships that I have discussed in my other blog posts, Understanding Your System, and Functional Analysis and MBSE. Functions decompose (or are decomposed by) other functions. Functions are allocated to components that perform those functions, and items flow between functions that represent data or physical entities involved in the exchange. The systems metamodel also includes a class for requirements. Generally, requirements of a functional nature are the basis of functions, and not directly related to a component. Requirements that are physical constraints to a design, or are performance-related, specify components directly. Use cases can be associated with requirements with an elicits relationship and can also be associated through an elaborated by relationship with functions to indicate the associated operational behavior (i.e. threads or scenarios) that describe the use case.

Requirements at a given layer can then be improved if necessary to make requirements concise, sharp, and testable. Requirements within the same layer can be associated with each other using the refines (or refined by) relationship to indicate how the requirements improved over time.

Requirements can also be tied to a SOW statement with a specified by relationship to an entity class called Program Element. The systems metamodel also allows requirements to specify a number of other classes such as Interfaces, Links, and Items. I’ll talk more about these classes in future blogs.

Figure 1. A portion of the systems metamodel for requirements

Requirements Analysis Techniques
With the systems metamodel described previously, engineers can do more than simply write requirements and build traceability matrices. Engineers can relate the requirements to the functional and physical aspects of the system design in meaningful ways to ensure a complete and thorough system design.

It is critical when defining requirements that systems engineers also give conscious thought to the behavioral model of the system, or intended operations. You can formalize the process as depicted in Figure 2. First, import a set of originating requirements from source documentation and then build out the intended behavior of your system. When functional behavior is complete, allocate functions to the physical elements of the physical architecture.

Figure 2. The MBSE process emphasizing Requirements and Behavior processes

As depicted in Figure 3, you can relate requirements to the functions that define system behavior using the basis of relationship. You can subsequently relate functions to system components with the allocated to relationship. Non-function requirements can be related to components directly using the specifies relationship.

Figure 3. Using the systems metamodel to structure requirements with behavior

Summary
Requirements are necessary to guide system development and to verify that contractual obligations have been met by the completed system. Requirements analysis differs at various stages in system development, beginning with development of operational requirements and completing when all components of the system have been identified. In the rush to write requirements, understanding behavior can sometimes become an afterthought. However, it is a necessary practice to ensure that the system is completely specified. A rich systems model helps to integrate system requirements with intended system behavior and design. A systems metamodel also helps you focus the efforts of engineers, thereby enabling better cohesion in your project.