In this post, we will learn about ‘Object-Oriented Systems Engineering Methodology (OOSEM)’, one of the modeling methods. Even if you have knowledge of SysML, you can often feel at a loss about the starting point and progression sequence when designing a system in real life.
Modeling Method plays a role in resolving these difficulties. A modeling method is like a roadmap. This refers to the series of documented design tasks that a modeling team performs to build a system model. More specifically, this methodology helps everyone on the team build a consistent system model and work toward a common goal. Without guidance, there will be significant differences in the quality of the system model each team member handles.
For reference, this post was written with reference to chapter 17 of “A Practical Guide to SysML, 2nd Edition.”
OOSEM is a top-down, scenario-driven process that uses SysML to support analysis, specification, design, and verification of systems. This process leverages object-oriented concepts and other modeling techniques to help you design more flexible and scalable systems that can accommodate evolving technologies and changing requirements. OOSEM is also intended to ease integration with object-oriented software development, hardware development, and testing processes.
Typically, the systems engineering life cycle consists of the following stages: development, production, deployment, operation, support, and retirement. The result of a successful development process is a proven system that meets requirements for operational requirements, functionality, production, deployment, support, and decommissioning.
One of the development processes to achieve this is the Object-Oriented Systems Engineering Method (OOSEM). OOSEM includes the “manage system development” process, “specify and design system” process, and next stage development, “Integrate and verify system” process, as shown in the Activity Diagram below. This is similar to a general V-Cycle Process and can be applied repeatedly across multiple system layers.
OOSEM System Specification and Design Process
Among the entire OOSEM process, the part that we are particularly interested in as engineers developing systems is the “specify and design system” process. Therefore, in this post, I will limit my explanation to the “specify and design system” process.
The main contents of the “specify and design system” process are as follows.
- Model setup activity: This is the initial step in establishing modeling guidelines and model construction, establishing basic prerequisites for model development.
- Stakeholder Requirements Analysis: Evaluate the limitations and potential areas of improvement of the current system and define the mission requirements that the future system must meet.
- System Requirements Analysis: Specifies system requirements through input and output responses and other black-box characteristics required to support mission requirements.
- Define Logical Architecture: Decomposes the system into logical components and defines how these components interact to realize system requirements.
- Candidate Physical Architecture Synthesis: Assign logical components to physical components such as hardware, software, data, and procedures.
- Optimization and Evaluation of Alternatives: Perform engineering analysis to support design optimization and trade studies.
- Requirements Traceability Management: Manage traceability from mission-level requirements to component requirements.
The level of detail of the process is tailored to organizational and project needs, and process documentation can be elaborated to produce more specific modeling artifacts.
1. Setup Model
1-1. Establish modeling conventions & standards
Establishing rules and standards for modeling tasks plays an important role in ensuring model consistency and accuracy. The rules and standards established during this process increase modeling efficiency and help all project participants easily understand and follow.
Modeling conventions and standards ensure that the model maintains consistent presentation and style, and naming conventions for all model elements improve the clarity and readability of the structure. Additionally, a clear understanding of the capabilities and limitations of the modeling tools used provides the optimal approach for model construction.
Layout standards for diagrams ensure visual consistency by establishing templates for each diagram type, which increases the readability and understanding of your project.
Finally, these rules and standards are defined at the organizational level, minimizing customization for each project and contributing to uniform modeling quality across the organization. This initial step lays the foundation for the success of your modeling effort, significantly improving the efficiency of your project and the quality of your results.
1-2. Organize the model
Organize the model emphasizes how important the organization of the model is in system modeling. This process manages model complexity, helps model developers maintain consistent models, and provides effective configuration management control. The complexity of a system model can overwhelm users and make the model difficult to work with. Maintaining model consistency and configuration management is especially important in large distributed teams.
The OOSEM process provides a standard approach to organizing models using a package structure. This structure builds the model organization on the concepts introduced earlier.
2. Analyze Stakeholder Needs
Stakeholder needs analysis activities are a very important part of the systems engineering process. This activity focuses on understanding stakeholder issues and clarifying the mission-level requirements needed to solve those issues. Highlights include:
- Understand the current system and company characteristics: In this step, the operating limitations of the current system are evaluated, and the cause of the problem is identified by understanding how the company operates.
- Perform causal analysis: Perform causal analysis to determine the limitations of the system and potential areas for improvement from the stakeholders’ perspective. This can help reveal structural or performance issues in your current system.
- Eliciting requirements for future systems: Use information derived through causal analysis to establish mission requirements and overall goals that future systems or enterprises must meet. This may include future models for the domain, enterprise use cases, and efficiency measures.
- Mission Requirements Review: This is the process of reviewing whether the established mission requirements actually meet the expectations and needs of stakeholders.
2-1. Characterize As-Is System and Enterprise
The “Characterize As-Is System and Enterprise process” step plays an important role in the process of identifying and modeling the current state of the system, users, and enterprise. This step provides an accurate understanding of the current system and its usage environment, providing critical insight needed to troubleshoot problems and improve the system.
In this process, by selectively modeling only the necessary information, you can utilize resources efficiently and focus on important elements. The current system is used as a starting point for analysis to clearly identify existing problems and serve as a basis for setting future requirements.
It also allows you to define your mission requirements and take a targeted approach when there are no suitable existing solutions. This approach provides critical information for system design and improvement decisions and helps make the overall process clearer and more effective.
2-2. Perform Causal Analysis
Analyze your current systems and enterprise to assess their capabilities and limitations and identify potential areas for improvement. Other data sources may be needed to support this analysis, including marketing data such as customer surveys and competitive data.
2-3. Specify Mission Requirements
The “Specify Mission Requirements” step plays a very important role in the system design process. In this phase, mission requirements are specifically defined and specified to meet the needs of end users and overcome the limitations of the current system. Key objectives are converted into text requirements and displayed on a requirements diagram, which clearly visually communicates the content and importance of each requirement.
In this process, all mission requirements are systematically managed within the requirements package and their relationships with other elements of the system are organized to ensure design consistency.
It also manages traceability between lower-level requirements linked to mission requirements, performing an important function in the design and verification process of the system. This step increases the accuracy and efficiency of system design and ensures that the final product meets user expectations and needs.
2-4. Capture Measures of Effectiveness
Measures of Effectiveness (MOE) are mission-level performance requirements for a system that reflect customer and stakeholder values. MOE is set as a target value to satisfy stakeholder needs and secure competitive advantage.
These MOEs are defined through parametric diagrams, which are linked to an objective function that measures the cost-effectiveness of the overall design solution. Additionally, engineering analyzes are performed at all stages of development to support and improve these MOEs.
2-5. Define To-Be Domain Model
The “To-Be Domain Model” is a tool for scoping future systems and enterprises, structured through block definition diagrams that reflect existing analysis results and mission requirements. This model describes the hierarchy of the intended operational domains with a top-level focus and supports the development of future operational domains with significant changes.
Additionally, we aim to design a system that effectively meets the needs of users and stakeholders by establishing measurable operating effectiveness (MOE).
2-6. Define Enterprise Use Cases
Use cases are defined to represent each mission objective corresponding to the mission requirements.
3. Analyze System Requirements
System requirements analysis is the process of clarifying the black box requirements of a system and defining how the system should interact with users and external systems. Key points of this process include:
- Definition of black box requirements: Clearly define externally observable characteristics of the system, such as input, output, interface, control, storage, performance, and physical requirements.
- Scenario Analysis: For each enterprise use case, we describe how the system will interact with external systems and users based on the domain model. This is modeled through an activity diagram or sequence diagram.
- System Context Diagram: Described using an internal block diagram of the operational domain to define the interfaces between the system and external systems.
- Design Constraints and Requirements Variation Analysis: Evaluate the potential for design constraints and requirements changes to ensure the architecture can accommodate them.
- Requirements Review: A review is performed to ensure system requirements meet stakeholder and mission requirements and ensure the quality of the requirements.
3-1. Define Mission Scenarios
Defining mission scenarios is an important process to clearly understand and design the interactions between the system, external systems, and users. This process specifies how the system should behave in various situations, which provides the basis for system design. Mission scenarios are modeled through activity diagrams or sequence diagrams, which provide a visual representation of the behavior and interactions between the system and users.
These scenarios include common use cases, as well as situations that stress the performance of the system or are likely to result in exceptions and failures. This allows designers to adapt the system’s response to different situations.
Additionally, using activity partitions in an activity diagram helps to ensure efficient operation of the system by clarifying the roles of the system and external entities and specifying the inputs and outputs required for each activity. All of these processes contribute to designing the system to meet the diverse needs expected in a real operating environment.
3-2. Define System Context
System context definition is the process of utilizing system context diagrams to clearly identify the interfaces between a system and its external systems and users. This diagram provides a visual representation of the interconnectedness of a system, showing the domains in which the system operates and the entities that participate in it. Additionally, we model the input and output flows that appear throughout the mission scenario, thereby assigning item flows through connectors between parts in the diagram.
Ports and connectors define the interface between systems and specify the properties of items flowing through the port. The interface block contains the flow properties of these items and is designed to adhere to the defined compatibility rules.
All of these processes serve as important steps to systematically define the system’s interactions with the outside world and facilitate system integration and operation. This approach is critical to the efficient design and management of the system and greatly helps in clearly understanding the interface between the system and external systems.
3-3. Capture Critical System Properties and Constraints
The process of capturing the critical performance requirements and constraints of a system is essential to ensure that the system is efficient and responsive. This includes capturing performance requirements and timeline analysis to determine exactly how much time each activity requires.
3-4. Specify Black-Box System Requirements
The process of specifying black box system requirements is an important step in defining the external characteristics and behavior of the system. This process defines the observable behavior and physical properties of the system, but does not specify how they are implemented. Key elements include modeling the essential functions the system must perform and the interfaces for those functions. Here, the required performance and physical properties are captured through specific parametric constraints, and the storage and control requirements of the system are also defined.
Additionally, the block specification of the system is linked to an activity diagram to specify specific behavior, which, together with parametric constraints on performance properties, supports engineering analysis. The black box specification also ensures the universality of the system and provides traceability to mission requirements, expanding applicability at the system, element, and component levels. All of these processes are carried out systematically through the OOSEM methodology, contributing to increasing the efficiency and accuracy of system design.
3-5. Define System State Machine
System state machines play a key role in systematically managing and controlling the behavior and reactions of a system. It specifies exactly what actions are required for each scenario, and transitions between each state are determined by a variety of events and conditions.
These transitions are made taking into account the current state of the system, input values, availability of resources, etc., and each transition is designed to have a specific effect. The complexity of a state machine causes the various states of the system to perform specific tasks, which must be tailored to the physical and logical design of the system.
Additionally, the configuration of the state machine can be represented visually through activity diagrams, which is important to ensure efficient management and stable operation of the system. These factors make state machines a central part of system design.
3-6. Analyze System Requirements Variations
Requirements variation analysis is an important process that systematically evaluates and prepares for various changes that may occur during system design and operation. This analysis allows system designers to identify and understand potential changes in requirements due to changes in external interfaces, increased number of users, or addition of new features.
Additionally, we evaluate the system’s functionality and interfaces to determine which elements are likely to change. The probability and impact of these changes are quantified into ‘high’, ‘medium’, and ‘low’ ratings to assess technical, cost, and schedule impacts.
Based on the analysis results, you can develop strategies to minimize risks and effectively respond to future requirements by applying approaches from similar systems. This approach makes an important contribution to the continuous development and maintenance of the system and has a decisive impact on the success of the project.
3-7. Identify System Design Constraints
Design constraints play an important role in determining the performance and quality of a system. Particularly in complex systems, there are a variety of technical and operational constraints, making it essential to effectively identify and manage them. Starting with the first step of identifying and classifying constraints, clearly capturing them in a requirements package, interpreting them theoretically, and assessing their impact.
This is then applied to the physical architecture to ensure that the design meets the constraints. This process allows system designers to accurately understand how constraints impact the system and make appropriate design decisions, which are critical to ensuring project success and product quality.
4. Define Logical Architecture
The activity of defining a logical architecture involves decomposing a system into logical components, which abstracts the functionality of the system by separating it from its physical components. This process satisfies system requirements, ensures implementation flexibility, and helps you respond to design changes. Each logical component realizes the functionality of the system and allows specific technology choices to be modified when changes are needed. Additionally, the logical architecture serves as a system reference architecture that supports a variety of physical implementations and can include state-based behavior. This structure maintains traceability to system-level requirements and leads to physical architecture development.
4-1. Define Logical Decomposition
Logical decomposition definition activities play an important role in the system design process and involve breaking down the system into logical and physical components to manage its complexity. This process divides the system into smaller, manageable blocks, with each block containing specific functions, storage, properties, and ports.
In logical decomposition, logical blocks are decomposed into logical components that inherit the functional elements of the system and are used to implement the black box system. On the other hand, physical blocks are decomposed into physical components, mapped to actual hardware elements, and represent the physical implementation of the system.
Each logical component performs a specific role, including managing external interfaces, operating applications, and supporting infrastructure. These components are responsible for handling the system’s business logic, managing interfaces with external systems or users, and providing internal support services. This decomposition process contributes to clarifying the structure of the system and increasing the efficiency of design and implementation.
4-2. Define Interaction between Logical Components to Realize Each System Operation or Allocated Activity
The process of defining the interactions between logical components to effectively realize system operation is an important step in determining the design and functionality of the system. This clearly shows through the activity diagram which logical block each Action will be implemented, and ensures how each task supporting the mission scenario is realized by logical design.
In an activity diagram, the allocation and execution of activities is managed through high-level calling action tasks.
4-3. Define System Logical Internal Block Diagram
A system logical internal block diagram is an important tool for representing the logical components of a system and the interconnections between them. This diagram provides a clear understanding of the overall structure of the system, showing the function of each component and how they are integrated within the system.
The frame of the diagram represents the entire system logical block, and each internal port represents a connection point to the outside. These connection points are set up to communicate with the external environment through external interface components. Application components are responsible for the business logic of the system, for example, collecting sensor data and detecting events.
These logical components interact with each other through specific connectors, which enables efficient coordination of various system functions. For example, the system controller can communicate with other components to manage alarms and sensor data. This contributes to increasing the stability and responsiveness of the system.
The internal block diagram contains all the necessary components to complete the logical design, but a simplified version can be created, emphasizing only specific subsystems or functions, as needed. This is useful when you want to focus on a specific task or understand a specific part of the system in more detail. These diagrams can greatly help systems engineers control the overall design and determine exactly what each component does.
4-4. Specify Logical Components
The specification of each logical component includes a functional specification captured in that block in the same way described for specifying a system block. Tasks in an activity diagram are captured as tasks. Logical interfaces are captured as ports. Persistent storage is captured as a reference property with the «store» stereotype applied. Performance and physical characteristics are captured as value characteristics.
4-5. Define Logical Component State Machine
State machines are powerful tools that allow logical components within a system to react differently depending on their state. It plays an important role in describing the state-dependent behavior of a component and clarifying event handling in each state. This makes the behavior of the system predictable and manageable.
The component’s state machine essentially starts in a waiting state, and when it receives an input event, it performs the action defined in the activity, then returns to the waiting state and has a circular process to wait for the event. This allows the component to react to continuous input and take appropriate action as needed.
By using state machines, we can fine-tune the response of each component. This is especially important for components that handle complex or critical tasks, as it can increase the stability and reliability of the system and protect it from unexpected errors. State machines make it clear what actions are required in each state and help components collaborate efficiently with other parts of the system.
5. Synthesize Candidate Physical Architectures
Candidate physical architecture synthesis involves the activity of integrating various physical components to satisfy the requirements of the system. These components include hardware, software, data, and operating procedures, which are located in a specific physical location or under the responsibility of an organization. The architecture is segmented to optimize performance, reliability, and security, with each component logically structured and efficiently distributed. Architectures are also defined separately to meet specific requirements for software, hardware, and data. Ultimately, engineering analysis and review are performed to ensure that these architectures meet system design constraints and meet stakeholder needs.
5-1. Define Partitioning Criteria
Partitioning criteria are central to system architecture design, effectively separating functionality, data, and control between logical and physical components. By applying these criteria, cohesion between components is maximized and coupling is minimized, reducing interface complexity and better meeting system performance, stability, maintainability, and security requirements. Examples include refactoring components that share common functionality, partitioning components based on update rate, and partitioning data stores based on security level. This segmentation plays an important role in reducing the ripple effect of technology changes or requirements changes. Additionally, it is implemented as part of a robust design strategy, such as the use of modular and reconfigurable components and the adoption of standard interfaces.
5-2. Define Node Logical Architecture
The node structure is a key element of the system, determining how components are distributed according to their physical locations and how functionality, control, and persistent data are managed. Nodes can be as varied as fixed facilities or mobile platforms, or they can be formed based on the roles played by specific departments within the organization. These nodes play a critical role in the overall system, including both logical and physical components.
In OOSEM, a logical node represents a set (or sets) of logical components at a specific location. A physical node represents a set (or sets) of physical components at a specific location. Logical components on a logical node are assigned to physical components on a physical node.
In the design of a distributed system, the distribution of functions among nodes is important, which can be configured so that each node can perform the overall function independently, or it can be configured so that a central node performs the main function and local nodes provide interfaces with external systems. . Additionally, functions can be partially distributed to regional or local nodes, so that each node can perform only part of the required function.
These deployment methods must be carefully considered to optimize system performance, reliability, security, and cost. These principles are applied in a variety of complex systems such as information systems, power distribution systems, and transportation systems through network communication, contributing to improving the efficiency and responsiveness of the overall system.
5-3.Define Node Physical Architecture
Node physical architecture involves the process of assigning the functionality of each logical node to physical elements based on the logical components defined in the ESS logical architecture. During this process, quality attributes such as performance, reliability, and security are considered to determine the optimal location of each component. For example, a logical component, such as an entry sensor, may be assigned to a specific node, for example a site installation node, regardless of its technical characteristics. These decisions are important to maximize the efficiency and performance of the overall system design.
Logical-physical allocations between nodes are made to reflect various design constraints. For example, logical components may be assigned to specific commercial off-the-shelf components (COTS), a decision that directly impacts the physical architecture. Additionally, each logical component is assigned from physical components to hardware and software components, which supports the design and operation of the overall architecture.
Additionally, alternative physical architectures can be created considering a variety of options. For example, alternative assignments of optical and contact sensors for entry sensors are possible, with the components selected being determined by the performance criteria of the overall system. These decisions are made based on architectural patterns and related technologies, and common solutions can increase the efficiency of the system.
Ultimately, the node physical architecture is optimized through trade studies, which take into account critical system requirements such as performance, cost, availability, etc., resulting in a balanced solution. This process is essential for the overall operation and management of the system, including the allocation of data storage and operating procedures, as well as the software and hardware components assigned to each node.
5-4. Define Software Architecture
Software architecture is the process of systematically defining software components and their interrelationships to meet the functionality and requirements of a system. That is, it embodies the software assigned to each physical node. This structure clearly represents the decomposition of the software and how each component connects to each other, which is important for maximizing the overall performance and efficiency of the system.
5-5. Define Data Architecture
Data architecture is a structure that systematically addresses how data is managed and organized within a system. This architecture defines how persistent data is stored, managed, and used, and specifies how the data is integrated into the physical architecture. This structure improves data accessibility, reliability, and maintainability, and plays an important role in ensuring the consistency and efficiency of the overall system design.
Data architecture defines the different types of persistent data and describes where this data is stored in the system and how it is managed.
5-6. Define Hardware Architecture
Hardware architecture is a part of the physical architecture that encompasses all the hardware components of a system and their interrelationships, which are critical to meeting the functional needs of the system. This architecture organizes the system’s hardware components and defines how they interact to maximize the system’s overall efficiency and performance.
Hardware architecture details the interconnections of hardware components, including the communication protocols, signaling characteristics, physical connectors, and cabling that make these connections possible. It is designed to ensure efficient communication and data transfer between hardware components, ensuring system stability and reliability.
5-7. Define Operational Procedures
Operating procedures provide essential guidance for the effective management and operation of the system. It is a process that explicitly defines what activities operators inside or outside the system must perform and how they will interact with the system.
5-8. Specify Component Requirements
Component requirements specification is the process of clearly characterizing the core components of a system: software, data, hardware, and operating procedures. These requirements define the functionality, performance, interfaces, and other important properties of each component, providing the detail needed for system design and integration.
5-9. Defining Other Architecture Views
Architectural views and perspectives are essential tools for managing the complexity of a system and meeting the needs of specific stakeholders. Each view highlights one aspect of the system, and perspectives reflect stakeholder concerns to guide design decisions.
6. Optimize and Evaluate Alternatives
Alternative optimization and evaluation activities play an essential role in engineering projects. This course focuses on supporting a variety of engineering analyses, identifying required analyzes and defining the context for the analyses. Additionally, parametric diagrams are used to clarify the constraints of each analysis and thereby perform engineering analysis. The use of SysML serves as a powerful tool to capture important system characteristics into models and integrate them with a variety of engineering analyses. This integration enables analysis of system performance, reliability, and mass properties, supporting effective decision-making during development.
6-1. Identify Analyzes to Be Performed
The process of identifying which analyzes to perform focuses on characterizing or predicting the performance, reliability, mass properties, and cost of the system. These analyzes are essential to assess design sensitivity, drive optimization, and select and evaluate the optimal solution among design alternatives. We also support technical planning through design verification, cost estimation, and risk analysis. During this process, it is important to define the different engineering analysis types and fidelity, as well as to manage metadata containing the required analysis tool or solver information. This enables effective analysis throughout the design process and improves the overall quality of the system design.
6-2. Define the Analysis Context
Defining the analysis context is a key part of analyzing complex systems. This course utilizes block definition diagrams to clearly establish the context for each analysis.
The analysis block is also used to evaluate the overall value of the system, including cost-effectiveness analysis. This is linked to equations that calculate the efficiency of operating costs, ensuring that the purpose of the analysis is accurately carried out. Each element of the analysis refers to the top block of the system hierarchy, linking the characteristics of the object of analysis to the parameters of the analysis equations. By doing so, the analysis comprehensively evaluates various characteristics of the system and provides in-depth data for optimization of the design. This approach increases the accuracy of analysis and contributes to improving the overall efficiency of the project.
6-3. Capture Constraints in Parametric Diagram
Parametric diagrams are important tools for integrating system design and analysis models. This diagram connects the parameters of each analytical equation to the properties of the system, making the analysis clearer.
Parametric diagrams provide the ability to maintain explicit relationships between each element of a system and its component properties. This allows designers to clearly constrain the inputs, outputs, and input-output relationships associated with the behavior of the system. Parametric diagrams are also useful when dealing with value properties that represent the state of the system at a specific point in time, and are used to bind state-dependent constraints to those state properties.
These features make parametric diagrams play a key role in analyzing and optimizing the performance of your system. It supports critical decision-making during the design process and helps improve the efficiency and effectiveness of complex systems.
6-4. Perform Engineering Analysis
Parametric diagrams play a key role in performing engineering analysis. To implement the equations defined in this diagram, highly computationally demanding engineering analysis tools are required. These tools accurately calculate the values of system properties that satisfy various constraints, and these values are reintegrated into the design model of the system and used to evaluate the efficiency and feasibility of the overall design.
For example, data produced from availability analysis shows how well the system meets availability requirements. This translates into concrete values for important performance metrics such as mean time between failure (MTBF) and mean time to repair (MTTR).
These analyzes help you make important decisions at all stages of system design and enable the development of more robust and reliable systems. This process is also essential to discover opportunities for design improvement and maximize efficiency.
7. Manage Requirements Traceability
Requirements traceability management activities focus on linking the project’s stakeholder requirements with the system specifications and design model. This process captures text-based requirements within the model and associates them with model elements to meet, validate, and improve requirements. This activity also generates traceability reports and specification documents, which are essential to clearly track and manage fulfillment of requirements throughout the project. These processes, together with language concepts for requirements modeling, contribute to increasing the transparency and accuracy of system development.
7-1. Define Specification Tree
A specification tree provides a structured, hierarchical specification of a system. This tree expresses the specifications for each layer of the system and includes various levels, starting from mission requirements, through system specifications, and then through corresponding hardware and software specifications. These specifications are linked together through traceability relationships to ensure requirements are met and integrated throughout the system. Additionally, this tracking relationship demonstrates traceability from mission requirements to stakeholder requirements assessment documents, increasing the consistency and efficiency of the overall requirements management process. Traceability between detailed requirements is managed through other, more granular requirements relationships.
7-2. Capture Text-Based Requirements in Model
Requirements traceability management is one of the key activities in systems engineering projects. This process transfers stakeholder requirements from text documents to SysML models to structure and visualize the requirements. SysML modeling tools provide the ability to import these requirements directly and maintain synchronization between models and text documents. The requirements captured in the model are organized into a structure that corresponds to various specifications, and each requirement can include additional properties such as importance, uncertainty, changeability, and verification method.
This process ensures that requirements are met at all stages of system design and development, and that each change to requirements is effectively managed and documented. For example, the requirements of a system are managed by nested packages created for each specification, and these packages form a requirements hierarchy that encompasses the system’s interfaces, functionality, performance, reliability, etc. This structured requirements management reduces project complexity and increases the efficiency of the development process.
7-3. Establish Requirements Relationships and Rationale
Requirements traceability management is a pivotal activity in systems engineering, ensuring that requirements are systematically satisfied by establishing links between all design elements and test cases. Requirements diagrams clearly trace the relationships from stakeholder requirements to final system components, visually representing the connections and rationale between each requirement.
The level of detail of traceability is determined by project needs and coordination. Fine-grained traceability management makes it easier to assess the impact of system changes, but it also increases management complexity and effort. Therefore, traceability management must be appropriately tailored to the size and complexity of the project. This approach ensures that any changes to the system meet stakeholder expectations and that system requirements are thoroughly implemented.
7-4. Analyze Traceability Gaps
Traceability gap analysis is performed to evaluate how well the system design meets the requirements. Analyze gaps through traceability reports and use metrics to assess coverage of requirements. The results of these analyzes are reflected in improving system design and verification, and are used to update traceability data. Model queries identify elements that meet specific requirements, which are expressed in reports in a variety of formats, including diagrams, tables, matrices, and trees. This clarifies requirements relationships and gaps and increases consistency in overall system development.
7-5. Managing Requirements Updates
Requirements management activities are an essential element in the system development process. During this process, you can update existing requirements or introduce new requirements. In particular, new requirements are defined for the system and its components, which helps clarify and improve ambiguous or inconsistent requirements. Changes to requirements are systematically managed through the project’s change management process.
In large-scale projects, integration of requirements management tools and system modeling tools is very important. This integration ensures that the relationships between requirements and model elements are synchronized, ensuring that changes in requirements are reflected in the model. Changes to requirements text are made in the requirements management tool, and those changes are managed through the modeling tool. Additionally, the modeling tool allows you to directly generate requirements specification documents using standard requirements templates and automatic document generation features. This approach ensures requirements accuracy and contributes to increasing project efficiency.
OOSEM Support to Integrate and Verify System
System integration and validation are essential steps in the system development process and aim to ensure that the system meets all requirements. OOSEM supports this process in a variety of ways. This mainly involves establishing a verification plan, executing verification procedures, analyzing results, and writing reports.
The system model is used as a basis for developing test cases for verification. For example, Systems Modeling Language (SysML) includes test cases and verification relationships that can be used together to verify requirements at the system, element, and component levels.
Additionally, model-based approaches use executable models to conduct testing to verify requirements without the need for hardware or software. This is useful for ensuring that requirements are met in the early stages of development, and for validating more detailed design models by integrating them with the system model as development progresses.
Test case execution requires an appropriate validation environment to generate stimuli and evaluate responses. This environment may include hardware, software, facilities, and personnel along with the devices under test. Verification methods include inspection, analysis, verification and testing, and each method is applied differently depending on the requirements.
This complex verification approach ensures system performance and helps proactively identify and resolve problems that may arise during the development process. This thoroughly ensures that all system requirements are met, ultimately contributing to building a more robust and reliable system.
Developing Enabling Systems
Enabling system development is an essential element in supporting the entire system life cycle. This process includes the development of a variety of support systems, including manufacturing, maintenance, and verification, which are often developed concurrently with the operational systems. Through this, we seek ways to minimize production and maintenance costs in the early stages and effectively meet system requirements.
For example, considering the capabilities of your manufacturing system early can significantly reduce production costs. Likewise, verification systems can be more stringent than the requirements for the operating system under test, requiring the development of more precise measurement equipment. The OOSEM methodology can be applied for the specification and design of these enabling systems, providing additional modeling constructs that are particularly suitable for the test domain.
Each enabling system can be subject to the full OOSEM methodology or parts of it, depending on its complexity.
This approach ensures successful construction and operation of the system by early identifying and addressing the impact of the system’s various support elements on the overall design and efficiency of the system. Therefore, proper development and integration of enabling systems is very important to prevent negative impacts that may occur during the entire life cycle of the system.
If you are interested in other articles about the MBSE Methods, please refer to the links below!