# Traceability Concept

![Traceability Concept](resources/diagrams/traceability-concept.png)

## Description of the layers

**Stakeholder Requirements**: It's crucial to understand that we always start with the stakeholder requirements where regulations are an important input. This is the customer's point of view, defines “what” should be done.

**System Requirements**: The system requirements are the answer to the stakeholder requirements. It describes “how” it is going to be implemented. Quality requirements, often called non-functional requirements, are part of the system requirements. They are stated as testable requirements e.g. latency time must be less than 200ms. Furthermore we also add potential risks at this level.

**Functional Specification**: ... to be continued

**Configuration Specification**: ... to be continued

## Implementation in Azure DevOps

We are following the CMMI process template in Azure DevOps.

Regulations are mapped as requirements work item in Azure DevOps that affect other requirements. In that way we see all regulations that affect a requirement and all requirements that are affected by a regulation. This is a bidirectional traceability.

All requirements are listed in a use case specific document. The requirements are linked to the regulations and the tests. The tests are linked to the requirements. This is a bidirectional traceability.

This results in a traceability matrix that documents the requirements from the regulation to testing.
