by Thomas Ruckstuhl (ERNI Switzerland)
In developing complex medical systems like automated diagnostic devices or patient monitoring platforms, precise requirements capture is both a regulatory and design necessity. Document-driven approaches fall short. We show how requirements engineering as a strategic modelling discipline lays the foundation for digital system models.
The impact of complexity
Each regulated area has its own set of specific requirements that demand intense attention to detail. Especially in heavily regulated domains, but also in others, it is most often mandatory to carefully document the work performed, how the system should operate, what it can and cannot do, and how it needs to be tested. Having experience with complex projects in any regulated area can be of huge benefit for any other regulated domain.
Aviation and aerospace are just two more examples of complex branches where the development environment is characterised by rigorous regulatory requirements, a focus on quality and risk management, interdisciplinary collaboration and the integration of advanced technologies. Companies must remain agile and proactive in addressing these complexities to successfully bring safe and effective medical devices to market.
Requirements engineering as part of systems engineering
A defined systems engineering approach as described by INCOSE (International Council on Systems Engineering) is becoming more and more important because the industries are increasingly confronted with complex projects. For companies acting in heavily regulated environments which develop complex smart devices, systems engineering is an effective approach to address their challenges. As a transdisciplinary and integrative approach to enable the successful realisation, use and retirement of engineered systems, it uses systems principles and concepts, as well as scientific, technological and management methods.
The V-model (or Vee model) in systems engineering is a visual framework that illustrates the systems development lifecycle in a structured, sequential manner. It emphasises the relationship between each development phase on the left side of the ‘V’ and its corresponding validation or verification activity on the right side.
There are three specific SE technical processes where the requirements engineer is strongly involved:
- Business or mission analysis
- Definition of stakeholder needs and
requirements - Definition of system requirements
These steps define the stakeholder needs and requirements and further convert the stakeholder, user-oriented view of desired capabilities into a technical view of a solution that meets the operational needs of the user. The system requirements become the foundation for architecture, design, implementation and verification. By establishing RE in this segment of the SE lifecycle, we keep the requirements visible, verifiable and aligned throughout the entire lifecycle.
Complexity demands more than knowing the craft
Experienced requirements engineers know the craft and the essentials – all the context, use case and activity diagrams and how to elaborate requirements based on these fundaments. However, the challenge only starts when the requirements turn from static artifacts to living interconnected assets that need management across tools, teams and time. It requires systems thinking, collaboration and adaptability.
ALM tools: A good start, but not the finish line
ALM (Application Lifecycle Management) tools are crucial in regulated domains like medical devices, finance and aerospace because they help manage software development from start to finish, ensuring compliance and quality.
Requirements that were elicited and elaborated out of the requirements engineering artifacts are stored and managed in text form in an ALM tool – which is, of course, already a great start. However, the era of storing requirements in spreadsheets is behind us.
Moreover, requirements engineering artifacts are stored in different documents or different tools, and it is challenging to keep these diagrams updated and aligned during the project and especially also during the operation and maintenance phase. Sometimes, it can happen that tools like Microsoft Visio have been already decommissioned before the project is finished, and thus the diagrams are lost or can no longer be maintained. And in which project does one not wish for a single source of truth?
Design traceability and impact awareness – A missing link
Another big challenge in complex projects arises if the Requirements Engineers do not know which system functions or components are impacted by their requirements. Or, the case may be that they do know, but it is not properly documented and transparent for the project. Each requirements engineer should be able to track the key requirements against the design (know the delta). Therefore, in addition to traces being maintained between requirements and from requirements to test cases, the connection between requirements and their associated design and architecture elements needs to be maintained as well.
Our experience has shown that requirements engineering is not only a key component of the systems engineering process. RE itself also benefits from the systems engineering approach, especially when it comes to Model-Based Systems Engineering (MBSE).
MBSE arrives on the scene
Model-Based Systems Engineering (MBSE) is a standardised methodology used to facilitate requirements, design, analysis, verification and validation in regard to the development of complex systems. Unlike document-centric engineering, MBSE centres around models of system design. The increase in digital modelling environments within the industry over the last couple of years has directly impacted the pace of the MBSE uptake. In January 2020, NASA observed this trend and reported that MBSE “has been increasingly embraced by both industry and government as a means to keep track of system complexity.” As far as the methodology is concerned, MBSE represents a collection of related processes, methods and tools.
The INCOSE Systems Engineering Vision 2020 (2007) defines MBSE (Model-Based Systems Engineering) as: The formalised application of modelling to support system requirements, design, analysis, verification and validation activities beginning in the concept stage and continuing throughout development and later life cycle stages.
From a requirements engineering point of view, it is important to contribute to the model by creating artifacts like activity and sequence diagrams and – of course – elaborated requirements. As soon as the system design and architecture are available, the requirements can be traced to the corresponding elements of the model. This way, a relationship between the text-based requirements and the model elements is established and maintained.
Model-Based Systems Engineering (MBSE) plays an important role because it enhances clarity and communication among stakeholders through visual representations, facilitates early validation and verification of requirements, and supports better risk management by allowing for simulation and analysis of complex systems. MBSE promotes traceability, ensuring that all system elements are aligned with requirements, and enables iterative development, making it easier to adapt to changes. Additionally, it improves collaboration among cross-functional teams and provides a structured approach to managing complexity, ultimately leading to more efficient and successful system development.
Cost-benefit relationship
Implementing MBSE requires bigger upfront investments compared to traditional approaches. Time and
resources are needed early in the lifecycle – for tool integration, modelling, training, and adapting workflows.
However, these initial efforts are strategic investments. Projects that adopt MBSE realise significant returns in the later stages of development, especially during verification, integration and compliance. Understanding this relationship is key. Analysing both the cost drivers of early MBSE adoption and the value levers in later phases helps build a strong business case for change. Common early investments include process alignment, tool configuration and model creation; downstream gains include faster traceability, reduced rework, easier change management and smoother regulatory audits. When viewed across the full lifecycle, the economics of MBSE clearly favour long-term efficiency and product quality.
As soon as change management is required and a function needs to benchanged, the requirements engineer
can easily identify the corresponding requirements. Conversely, when a requirement changes, we can see
which functions or parts of the model are impacted. All diagrams are part of the model representing a single
source of truth. This applies not only to the development phase but also to operation and maintenance, when documentation becomes even more important.
MBSE offers a range of significant advantages. It ensures that the model is inherently consistent, which supports full traceability through semantic relationships. This enables clear links between requirements, design elements and system behaviour. MBSE also supports high levels of reuse, improving efficiency and reducing error rates across the development lifecycle. Moreover, Requirements Engineers can derive requirements systematically from the model itself, providing grounds for automated document generation.
Practical case: A complex diagnostic system
In our wide experience in the MedTech area, we once accompanied the development of a fully automated diagnostic system capable of measuring different parameters – all in a compact form factor.
In such a system, several factors play a crucial role:
- Ambitious product vision and scope
- Market competitiveness and cost
sensitivity - Advanced technological development
- Extensive integration of hardware and
software - Rigorous regulatory and compliance
framework - Complex project management
Using an MBSE approach, the development team linked each stakeholder requirement to a system function, component and test case. Changes in one area – meaning a new regulatory requirement for bilirubin measurement – automatically propagated through the model, revealing the impact on architecture and verification plans. This traceability ensured confidence in compliance, minimised late-stage rework and supported faster documentation generation for regulatory submissions.
Conclusion
Integrating systems engineering and MBSE does not only mean using new tools or methods. It means making a company-wide shift in how the organisation thinks and works across disciplines. Making that step requires both technical expertise and knowledge of change management. Having an experienced partner by your side helps in figuring out complex projects both in regulated and non-regulated areas. The difference does not simply lie in implementing frameworks, but in tailoring them to the industry-specific context and internal capabilities, and ensuring that every step on the way is aligned with the overall strategic goals.
