## 3 Related Works
### Requirements Traceability in Embedded Software  
Requirements traceability plays a critical role in embedded software development by helping to identify the origin of safety-related requirements, clarify these requirements, and make it easier to understand the interrelationships between software artifacts, thereby facilitating the management of requirements changes [34]. For these reasons, standards related to embedded software development mandate requirements traceability. In the automotive software domain, relevant standards include ISO 26262 and the Automotive Software Process Improvement and Capability Determination (A-SPICE) [35]. ISO 26262 is an international standard for ensuring the functional safety of automotive electronic systems requiring traceability of embedded software requirements. This standard provides requirements related to requirements management, traceability, and safety analyses. A-SPICE is a process capability evaluation model aimed at improving the quality of automotive software development and processes [36]. A-SPICE uses traceability to demonstrate the implementation of requirements, managing risks and helping identify the impact of changes in requirements. Although these standards provide a framework for improving the processes and requirements necessary for the safe development of embedded software, they do not offer detailed guidelines on how to achieve traceability. Embedded software design involves unique characteristics because systems must interact with the physical environment and because factors such as real-time performance, reliability, and hardware constraints must be considered. In this design process, requirements traceability is essential for verifying that all requirements are consistently reflected from the early design stages to the final implementation [37; 38]. Numerous approaches for supporting traceability in embedded software development are based on model-driven methods. [PERSON] et al. proposed a method using Model-Driven Development (MDD) to generate traceability between Natural Language Requirements (NLRs) and Architecture Analysis and Design Language (AADL) models [39]. [PERSON] et al. proposed a traceability approach that integrates SysML with Business Process Model and Notation (BPMN) and Decision Model and Notation (DMN) to support decision-making requirements [40]. In their approach, SysML was used to model certain aspects of the system, while process and decision-making activities were defined using the BPMN and DMN standards, respectively, providing traceability between different modeling methods. [PERSON] et al. proposed a method for managing requirements in critical software, focusing on providing requirements specifications for software development, verification, and maintenance activities [41]. This method employs an integrated model using SysML, BPMN, and DMN, offering efficient requirements management techniques such as V&V (verification and validation) and traceability. [PERSON] et al. proposed a mutation-driven method that generates mutants of state-machine diagrams and uses them to identify accurate traceability links in automated requirements traceability [42]. Their process includes model checking of safety requirements and identifying trace links by ensuring that the attributes of safety requirements are preserved in the mutants, which results in higher accuracy. [PERSON] et al. modeled the traceability between requirements and code through a property-listing task [43]. Their SeFea-Trace Conceptual Model (STCM) uses mathematical notation and a metamodel to enrich the information in the conceptual model based on software artifact properties, thereby establishing links between implementations. Although advantageous for automation and intuitive understanding, model-based traceability for embedded software is often limited in its applicability because of the diverse methods used to model the requirements, as demonstrated by the results in [44; 45].