Quality requirements

This section includes concrete quality scenarios to better capture the key quality objectives but also other required quality attributes.

Quality tree

The tree structure provides an overview for a sometimes large number of quality requirements.

Quality scenarios

The initial letters of the scenario identifiers (IDs) in the following table each stand for the higher-level quality characteristic. For example M for maintainability. These identifiers are also used in the quality tree. The scenarios cannot always be clearly assigned to a characteristic. Therefore, they sometimes appear more than once in the quality tree.

ID	Scenario
M01	Developers with basic knowledge of the traceability use case look for an introduction to the traceability architecture. They get the idea of essential design very fast.
M02	Senior developers look for a reference implementation of the traceability use case functionalities. They get it within the source code.
M03	Developers want to implement new features. They are able to add it to the source code easily.
M04	Developers want to implement a new frontend or change some components. The efforts can be reduced by using the standardized API endpoints to do so.
I01	Users want to switch from a FOSS application to a COTS application or the other way round. This is possible since the application is interoperable with other applications within the CX network.
F01	The application uses the Catena-X standards to ensure the correct interoperability and exchange with other participants.
F02	An OEM or tier n supplier needs more information regarding specific parts. He can mark the parts in question and send a top-down notification (quality investigation) to the next entity / the partner.
F03	A company wants to have more transparency and a visualized status of the supply / value chain. By using the application they are enabled to work with the structures and enable new features / functionalities.
F04	Notifications are sent using the EDC to ensure interoperability with the CX network.
E01	Notifications between traceability apps need to be sent and received within a specified timeframe to minimize the negative impact of e.g. recalled serialized products / batches on the value chain.

Scenario

M01

Developers with basic knowledge of the traceability use case look for an introduction to the traceability architecture. They get the idea of essential design very fast.

M02

Senior developers look for a reference implementation of the traceability use case functionalities. They get it within the source code.

M03

Developers want to implement new features. They are able to add it to the source code easily.

M04

Developers want to implement a new frontend or change some components. The efforts can be reduced by using the standardized API endpoints to do so.

I01

Users want to switch from a FOSS application to a COTS application or the other way round. This is possible since the application is interoperable with other applications within the CX network.

F01

The application uses the Catena-X standards to ensure the correct interoperability and exchange with other participants.

F02

An OEM or tier n supplier needs more information regarding specific parts. He can mark the parts in question and send a top-down notification (quality investigation) to the next entity / the partner.

F03

A company wants to have more transparency and a visualized status of the supply / value chain. By using the application they are enabled to work with the structures and enable new features / functionalities.

F04

Notifications are sent using the EDC to ensure interoperability with the CX network.

E01

Notifications between traceability apps need to be sent and received within a specified timeframe to minimize the negative impact of e.g. recalled serialized products / batches on the value chain.