in the first place. Post-requirements traceability. Not only the requirements themselves should be traced but also the requirements relationship with all the artifacts associated with it, such as models, analysis results, test cases, test procedures, test results and documentation of all kinds. Even people and user groups associated with requirements should be traceable. Requirements are realized into design artifacts, implementation, and finally, verified. Artifacts tied to the latter stages should be traced back to the requirements as well. This is typically done via a requirements traceability matrix. Establishing traceability beyond requirements into design, implementation, and verification artifacts can become difficult. When implementing software requirements for instance, the requirements may be in a requirements management tool, while the design artifacts may be in a design tool . Furthermore, implementation artifacts will likely be in the form of source files, links to which can be established in various ways at various scopes. Verification artifacts such as those generated by internal tests or formal verification tools. Repository or tool stack integration can present a significant challenge to maintaining traceability in a dynamic system. Usage of traceability information The usage of traceability, especially when tracing beyond requirements to all artifacts located in the tool chain, can bring several benefits: Change impact analysis – if a requirement is changing, trace links inform about related and dependent artifacts. These artifacts can easily be verified and if required be adjusted. The probability to overlook related artifacts is reduced. Coverage analysis – traceability ensures that no requirements are overlooked. Especially when certifying safety-critical products it is necessary to demonstrate that all requirements are realized. Project status analysis – tracking of the project status is possible: analyzing the traceability data allows seeing the completion status of the requirements. Requirements without links or with incomplete trace chain (e.g. requirements with implementation but without tests) indicate that further work is necessary. The missing links show which concrete artifacts are missing and need to be realized. Reuse of product components – it is possible to structure requirements and their linked artifacts in packages. These packages can be used for different products. Persisting relationships – often knowledge of a project or product is in the head of specific persons. By use of traceability this knowledge is saved by visualizing the relation between the different artifacts. This knowledge remains even if a person leaves the project. Test optimization – by linking requirements, source code,