diff --git a/docs-kits/kits/requirements-kit/adoption-view.md b/docs-kits/kits/requirements-kit/adoption-view/adoption-view.md
similarity index 68%
rename from docs-kits/kits/requirements-kit/adoption-view.md
rename to docs-kits/kits/requirements-kit/adoption-view/adoption-view.md
index 98334c3f1455..6328c35512ac 100644
--- a/docs-kits/kits/requirements-kit/adoption-view.md
+++ b/docs-kits/kits/requirements-kit/adoption-view/adoption-view.md
@@ -1,18 +1,54 @@
---
id: adoption-view
title: Adoption View
-description: 'Adoption View Requirements Kit'
-sidebar_position: 2
+sidebar_position: 1
---
+
+
+
+
import Kit3DLogo from '@site/src/components/2.0/Kit3DLogo';
+
+
+Welcome to the **Requirements KIT Adoption View**. This view provides business value, strategic benefits, and use cases for business stakeholders and decision-makers.
+
+:::info Target Audience
+Business Managers, Product Owners, Solution Architects, Industry Experts, and Decision Makers.
+:::
+
+---
+
## Vision & Mission
### Vision
+:::note Vision Statement
+Requirements Engineering shall be a cross-company activity where different companies refine the requirements together to create an optimal specification and thus enable a fast and reliable product engineering.
+:::
+
Our vision is to establish a seamless, secure, and efficient engineering platform within the Catena-X ecosystem. In a first step a collaborative platform for cross company requirements management that enables quick information access and multiple company collaboration via a standardized solution in the Catena-X dataspace, inspired by ReqIF (Requirements Interchange Format). By leveraging ReqIF, we aim to optimize the information flow and collaboration between OEMs and their suppliers, fostering a deep understanding and clear communication of requirements across company boundaries, while reducing time for exchanging requirements from point to point using common data exchange tools.
At the heart of this commitment is the guarantee of data sovereignty any time. Each partner should be able to share their data securely while retaining full control over their own information. This enables transparent and trustworthy collaboration in product development by providing all stakeholders access to relevant requirement sets and documents without compromising proprietary or confidential information.
@@ -27,11 +63,17 @@ This vision opens the way for innovative and collaborative product development b
### Mission
+:::note Mission Statement
+The KIT shall describe usable data models and approaches to aggregate and align Requirements in a data ecosystem.
+:::
+
The Requirements Kit aims to meticulously outline requirements by incorporating essential standards, aspect models and business logics. Its approach is designed to facilitate the exchange of requirements information between OEMs and Tier-N suppliers, ensuring that all relevant data is gathered and enabling authorized stakeholders to collaborate effectively. The data exchange process adheres to the Catena-X network's principles of data sovereignty, ensuring secure and compliant interactions. By following a standardized pipeline and utilizing data models within a data ecosystem, each partner is empowered to use their preferred applications, fostering a flexible and efficient collaboration environment.
-## Business Value & Benefits
+---
+
+## Business Value
-### Business Value
+### Value Proposition #1: Reliable and sovereign requirements data exchange system
The "Requirements-KIT" provides guidelines and standards, such as semantic models and data exchange processes, which help companies create a reliable and sovereign data exchange system with their partners.
@@ -39,15 +81,9 @@ This reduces cost and effort needed to integrate data-driven engineering process
Since this KIT is built on the Industry Core KIT and will be closely connected to upcoming other KITSs within the Engineering Domain, investment and implementation costs to integrate requirement services are reduced.
-### Todays Challenge
-
-As product development becomes more and more cross-company, the requirements that are necessary for the specification of the product to be developed must also be exchanged and harmonized across companies. This exchange for coordination between the customer and the development partner takes place in an iterative process that results in various documentation and changes to the specifications.
-
-Nowadays, the exchange of requirements is largely file-based, with the files being provided or exchanged via company portals (B2B platforms), for example. In most cases, the requirements are first managed by the client in special requirements management software. As a starting point for collaboration in the product development process, one or more files for the product to be developed are extracted from the requirements management software with the requirements and possibly other information and made available to the development partner. In order for the development partner to view and evaluate the requirements, they must import the file into their requirements management tool (which may or may not be the same as the customer's). Once the requirements have been evaluated by the development partner, the partner exports another file from its requirements management tool and makes it available to the client. The client then imports this file back into its system and evaluates the development partner's scores, comments, etc.
+---
-This involves the circular processing of requests between partners, which can result in multiple file exports and imports to and from the respective systems. Each import/export results in a break in the data. Changes within each version of the files must be tracked and displayed by the requirements management tools. This method of working with requirements is very time consuming and requires a lot of manual effort that has nothing to do with the actual evaluation of the requirements.
-
-In addition to the challenges mentioned above, there is also the issue that the files can be designed in a variety of content forms and the formats of the files can also vary. The formats can be divided into structured and unstructured files. Unstructured files are texts, tables etc. that are not organized into individual requirements without prior processing. These increase the effort required to organize the document into individual requirements. This also makes the exchange with the partner more difficult, as the partner does not know the newly created structure. With structured files, the aforementioned circumstances no longer exist, as the requirements are already organized. In the best case, a standardized form, such as the ReqIF format, is used. However, even when using standardized formats such as ReqIF, it is still necessary to agree on a common data model for exporting and importing in advance so that data exchange via the various requirements management tools works as smoothly as possible.
+### Summary of Business Benefits
### Benefits for OEM, SME and Solution Provider
@@ -84,11 +120,29 @@ Catena-X offers solution providers a variety of strategic advantages to leverage
9. Access to data and analysis: With access to valuable industrial data, solution providers can develop and enhance their analytics and optimization solutions to boost operational efficiency and decision-making processes for customers.
10. Accelerated digital transformation: Catena-X allows solution providers to position their transformation strategies directly within the context of the automotive industry, a sector that is continually moving towards digital technologies.
-## Customer Journey
+---
+
+## Use Case Context
+
+### Industry Challenge
+
+As product development becomes more and more cross-company, the requirements that are necessary for the specification of the product to be developed must also be exchanged and harmonized across companies. This exchange for coordination between the customer and the development partner takes place in an iterative process that results in various documentation and changes to the specifications.
+
+Nowadays, the exchange of requirements is largely file-based, with the files being provided or exchanged via company portals (B2B platforms), for example. In most cases, the requirements are first managed by the client in special requirements management software. As a starting point for collaboration in the product development process, one or more files for the product to be developed are extracted from the requirements management software with the requirements and possibly other information and made available to the development partner. In order for the development partner to view and evaluate the requirements, they must import the file into their requirements management tool (which may or may not be the same as the customer's). Once the requirements have been evaluated by the development partner, the partner exports another file from its requirements management tool and makes it available to the client. The client then imports this file back into its system and evaluates the development partner's scores, comments, etc.
+
+This involves the circular processing of requests between partners, which can result in multiple file exports and imports to and from the respective systems. Each import/export results in a break in the data. Changes within each version of the files must be tracked and displayed by the requirements management tools. This method of working with requirements is very time consuming and requires a lot of manual effort that has nothing to do with the actual evaluation of the requirements.
+
+In addition to the challenges mentioned above, there is also the issue that the files can be designed in a variety of content forms and the formats of the files can also vary. The formats can be divided into structured and unstructured files. Unstructured files are texts, tables etc. that are not organized into individual requirements without prior processing. These increase the effort required to organize the document into individual requirements. This also makes the exchange with the partner more difficult, as the partner does not know the newly created structure. With structured files, the aforementioned circumstances no longer exist, as the requirements are already organized. In the best case, a standardized form, such as the ReqIF format, is used. However, even when using standardized formats such as ReqIF, it is still necessary to agree on a common data model for exporting and importing in advance so that data exchange via the various requirements management tools works as smoothly as possible.
+
+---
+
+## Business Processes
-
+:::tip
+For industry-specific business processes, see the [Industry Extensions](../industry-extensions/automotive/Overview.md) documentation.
+:::
-## User Journey
+### Core Business Process: User Journey
```mermaid
flowchart TD
@@ -113,13 +167,158 @@ flowchart TD
```
+### Access & Usage Policies
+
+:::warning Industry-Specific Policies
+For industry-specific policy requirements, refer to the [Industry Extensions](../industry-extensions/automotive/Overview.md) section.
+:::
+
+#### Example Access Policy
+
+```json
+{
+ "@context": [
+ "https://w3id.org/catenax/2025/9/policy/odrl.jsonld",
+ "https://w3id.org/catenax/2025/9/policy/context.jsonld"
+ ],
+ "@type": "Set",
+ "@id": "some-id",
+ "permission": [
+ {
+ "action": "access",
+ "constraint": [
+ {
+ "and": [
+ {
+ "leftOperand": "Membership",
+ "operator": "eq",
+ "rightOperand": "active"
+ },
+ {
+ "leftOperand": "BusinessPartnerNumber",
+ "operator": "isAnyOf",
+ "rightOperand": [
+ "BPNL012345678910"
+ ]
+ }
+ ]
+ }
+ ]
+ }
+ ]
+}
+```
+
+In the Engineering Context most data exchange is done bilateral, therefore the access policy focuses on specific partners (here with a ``BPNL`` for automotive data ecosystems.)
+
+---
+
+## Semantic Models
+
+The core semantic model within the Requirements Engineering is the Requirements Model.
+It is used to describe a single Requirement.
+
+:::info Upcoming versions
+It is currently planned to refactor the Requirements Model such that it is easier to maintain the relationships between different requirements and make them better accessible and easier to register in a Digital Twin Registry.
+:::
+
+### Core Semantic Models
+
+| Model Name | Version | Purpose | Link |
+| ------------ | --------- | --------- | ------ |
+| Requirement | 1.0.0 | Describe a single Requirement in the Requirement Engineering process | [Semantic Model][1] |
+
+[1]: https://github.com/eclipse-tractusx/sldt-semantic-models/tree/main/io.catenax.requirement/1.0.0
+
+### Model Example: Requirement
+
+**Description**: This model describes a Requirement. It is based on ReqIF and thus uses some parameters in a common format.
+
+**Key Attributes**: `requirementId`, `requirementStatus` (customer and supplier), `requirementInformation` (actual requirement content), `requirementRelations`
+
+**Example**:
+
+```json
+{
+ "requirementRelations" : [ {
+ "requirementRelationshipType" : "RequirementSpecialismOfRequirement",
+ "relatedRequirementId" : "urn:uuid:e6b31BC2-8102-64AF-034D-C2DC35E37cEE"
+ } ],
+ "requirementId" : "urn:uuid:48878d48-6f1d-47f5-8ded-a441d0d879df",
+ "requirementInformation" : {
+ "foreignId" : "3.1.1",
+ "longname" : "Plastic deformation of the bogie",
+ "versionPredecessor" : {
+ "versionPredecessorNumber" : "1.4.5",
+ "versionPredecessorId" : "DaCfB4BD-15e7-edf0-77B6-Eb30De54aFbE"
+ },
+ "reqIfName" : "Plastic deformation of the bogie",
+ "reqIfType" : "Functional",
+ "metadata" : [ {
+ "value" : "2025-11-30T00:00:00.000+02:00",
+ "metadataDescription" : "Timestamp of the expected finalization of the requirement",
+ "key" : "ExpectedFinalization"
+ } ],
+ "author" : "Lisa Dräxlmaier GmbH",
+ "description" : "eOMtThyhVNLWUZNRcBaQKxI",
+ "specification" : [ "https://www.prostep.org/fileadmin/prod-pay-download-8c1d/Recommendation_ReqIF_V2.2.pdf" ],
+ "creationDate" : "2026-01-26T15:01:53.446Z",
+ "version" : {
+ "versionNumber" : "2.0.0",
+ "versionId" : "fA8Df9A9-3399-89AB-32eB-e7e61Bce8cFF"
+ }
+ },
+ "requirementStatus" : {
+ "customerStatus" : [ {
+ "customerStatusComment" : "Requirement needs to be evaluated",
+ "customerStatusValue" : "",
+ "customerStatusTimestamp" : "2026-01-26T15:01:53.449Z"
+ } ],
+ "supplierStatus" : [ {
+ "supplierStatusTimestamp" : "2026-01-26T15:01:53.449Z",
+ "supplierStatusValue" : "",
+ "supplierStatusComment" : "More information needed from customer"
+ } ],
+ "statusValue" : "transition status",
+ "statusTimestamp" : "2026-01-26T15:01:53.448Z"
+ }
+}
+```
+
+---
+
+## Standards
+
+:::warning Industry-Specific Standards
+For industry-specific standards, refer to the [Industry Extensions](../industry-extensions/automotive/Overview.md) section.
+:::
+
+### Supported Standards
+
+| Standard | Version | Description | Compliance Level | Link |
+| ---------- | --------- | ------------- | ------------------ | ------ |
+| CX-0154 | 1.0.1 | Standard describing how to handle Master Data in Engineering. This includes parameters of | Optional | [CX-0154][CX-0154] |
+| CX-0155 | 1.0.1 | Describes the required data models and API usage for the Requirements Engineering Use Case | Mandatory | [CX-0155][CX-0155] |
+
+[CX-0154]: https://catenax-ev.github.io/docs/standards/CX-0154-MasterDataManagement
+[CX-0155]: https://catenax-ev.github.io/docs/standards/CX-0155-RequirementsEngineering
+---
+
+## Tutorials & Resources
+
+### Whitepaper
+
+A Whitepaper was developed tother with the Manufacturing-X Topic Group Engineering, which should soon be available at: [https://mx-guidanceboard.org/downloads/](https://mx-guidanceboard.org/downloads/).
+
## Notice
This work is licensed under the [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode).
- SPDX-License-Identifier: CC-BY-4.0
+- SPDX-FileCopyrightText: 2026 Fraunhofer-Gesellschaft zur Foerderung der angewandten Forschung e.V. (represented by Fraunhofer IPK)
- SPDX-FileCopyrightText: 2025 Dräxlmaier GmbH & Co. KG
- SPDX-FileCopyrightText: 2025 Schaeffler AG
- SPDX-FileCopyrightText: 2025 Mercedes Benz Group AG
- SPDX-FileCopyrightText: 2025 ZF Friedrichshafen AG
- SPDX-FileCopyrightText: 2025 Contributors to the Eclipse Foundation
+- Source URL: [https://github.com/eclipse-tractusx/eclipse-tractusx.github.io](https://github.com/eclipse-tractusx/eclipse-tractusx.github.io)
diff --git a/docs-kits/kits/requirements-kit/development-view/development-view.md b/docs-kits/kits/requirements-kit/development-view/development-view.md
new file mode 100644
index 000000000000..f8880dea6d9c
--- /dev/null
+++ b/docs-kits/kits/requirements-kit/development-view/development-view.md
@@ -0,0 +1,379 @@
+---
+id: development-view
+title: Development View
+sidebar_position: 1
+---
+
+
+
+
+
+import Kit3DLogo from '@site/src/components/2.0/Kit3DLogo';
+
+
+
+
+
+Technical documentation for developers, architects, and implementers.
+
+:::info Target Audience
+Software Developers, Solution Architects, Technical Leads, API Developers, Integration Engineers.
+:::
+
+---
+
+## Core Components
+
+### Component 1: Requirement System
+
+**Purpose**: Core component responsible for requirement management at the data consumer or provider
+
+**Technology Stack**: Implementation depends on solution provider.
+
+**Interfaces**: Typically ReqIF Export
+
+### Component 2: Eclipse Dataspace Connector (EDC)
+
+**Purpose**: Facilitates contract negotiation and data exchange between partners in the data space
+
+**Technology Stack**: Java
+
+**Interfaces**: Dataspace Protocol
+
+### Component 3: Digital Twin Registry
+
+**Purpose**: Stores and manages digital twin information
+
+**Technology Stack**: Java, Go
+
+**Interfaces**: AAS API
+
+#### Component 4: Submodel Server
+
+**Purpose**: Handles submodel data and operations
+
+**Technology Stack**: Java, Go
+
+**Interfaces**: AAS API
+
+---
+
+## Sequence Diagrams
+
+### Data Exchange Flow
+
+```mermaid
+sequenceDiagram
+ participant oemReqSys as Requirement System Customer
+ participant oemDtr as DTR & Submodel Service Customer
+ participant oemEDC as EDC Customer
+
+ participant supEDC as EDC Supplier
+ participant supDtr as DTR & Submodel Service Supplier
+ participant supReqSys as Requirement System Supplier
+
+ oemReqSys->>oemDtr: Requirement (DTR + Submodel)
+ oemReqSys->>oemEDC: Notification
+ oemEDC->>supEDC: Notification
+ supEDC->>supReqSys: Notification
+ supReqSys-->>supEDC: Request Requirement
+
+
+ supEDC-->>oemEDC: Request Requirement
+ oemEDC-->>oemDtr: Request Requirement
+
+ oemDtr->>oemEDC: Requirement
+
+ oemEDC->>supEDC: Requirement
+ supEDC->>supDtr: Requirement (DTR + Submodel)
+
+ supDtr->>supReqSys: Requirement
+
+ supReqSys->>supDtr: Update Requirement
+ supReqSys->>supEDC: Notification (updated Requirement)
+ supEDC->>oemEDC: Notification (updated Requirement)
+ oemEDC->>oemReqSys: Notification (updated Requirement)
+```
+
+The sequence diagram illustrates the requirement exchange flow between a Customer (e.g., an OEM) and a Supplier:
+
+1. **Initial Requirement Creation**:
+
+ - Customer creates a requirement in their requirements system and registers it in their DTR and creates a submodel.
+ - Customer's system sends a notification through the EDC to the Supplier
+
+2. **Requirement Request**:
+
+ - Supplier's system requests the requirement details through the EDC
+ - The requirement is transferred from Customer's DTR to Supplier's DTR and submodel service
+
+3. **Requirement Update**:
+
+ - After processing, Supplier updates the requirement in their requirements system
+ - Supplier sends a notification about the update through the EDC back to the Customer
+ - Customer is notified about the requirement update
+
+4. **Next interactions**:
+
+ - The process can be repeated for further updates or new requirements in an interactive manner between the Customer and Supplier.
+
+---
+
+## Standards Compliance
+
+| Standard | Version | Compliance | Description |
+| ---------- | --------- | ------------ | ------------- |
+| CX-0154 | 1.0.1 | Optional | Standard describing how to handle Master Data in Engineering. This includes parameters that are fulfilling requirements but also versions of model |
+| CX-0155 | 1.0.1 | Mandatory | Describes the required data models and API usage for the requirement use case |
+
+### Standard Details
+
+#### Requirements Engineering v.1.0.1
+
+**Compliance Level**: Mandatory
+
+**Implementation**: The Requirements Standard describes the data model and the API to use for requirements engineering in Catena-X. The data model defined is based on ReqIF and can be used in other domains then automotive as well.
+
+**Reference**: [CX-0155 Requirements Engineering](https://catenax-ev.github.io/docs/next/standards/CX-0155-RequirementsEngineering)
+
+#### Digital Engineering Master Data v1.0.1
+
+**Compliance Level**: Recommended
+
+**Implementation**: The Digital Engineering Master Data standard describes the main artifacts required in Collaborative Engineering use cases with a focus on Catena-X. It is designed industry-agnostic and can be used in other industries as well.
+
+**Reference**: [CX-0154 Master Data](https://catenax-ev.github.io/docs/standards/CX-0154-MasterDataManagement)
+
+---
+
+## Logic & Schema
+
+### Data Schema
+
+#### Schema: Notification Schema
+
+**Purpose**: The notification format used for the requirements exchange is based on the [Industry Core Kit's standardized notification format](../../industry-core-kit/software-development-view/notifications.mdx). The following example illustrates a notification sent from a Customer to a Supplier when a new requirement is created:
+
+```json
+{
+ "$schema" : "http://json-schema.org/draft-04/schema",
+ "x-samm-aspect-model-urn" : "urn:samm:io.catenax.shared.message_header:3.0.0#MessageHeaderAspect",
+ "description" : "Aspect model describing the shared message header.",
+ "type" : "object",
+ "components" : {
+ "schemas" : {
+ "UuidV4Trait" : {
+ "type" : "string",
+ "x-samm-aspect-model-urn" : "urn:samm:io.catenax.shared.uuid:2.0.0#UuidV4Trait",
+ "description" : "The provided regular expression ensures that the UUID is composed of five groups of characters separated by hyphens, in the form 8-4-4-4-12 for a total of 36 characters (32 hexadecimal characters and 4 hyphens), optionally prefixed by \"urn:uuid:\" to make it an IRI.",
+ "pattern" : "(^[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}$)|(^urn:uuid:[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}$)"
+ },
+ "ContextCharacteristic" : {
+ "type" : "string",
+ "x-samm-aspect-model-urn" : "urn:samm:io.catenax.shared.message_header:3.0.0#ContextCharacteristic",
+ "description" : "Defining a string value for the context"
+ },
+ "Timestamp" : {
+ "type" : "string",
+ "pattern" : "-?([1-9][0-9]{3,}|0[0-9]{3})-(0[1-9]|1[0-2])-(0[1-9]|[12][0-9]|3[01])T(([01][0-9]|2[0-3]):[0-5][0-9]:[0-5][0-9](\\.[0-9]+)?|(24:00:00(\\.0+)?))(Z|(\\+|-)((0[0-9]|1[0-3]):[0-5][0-9]|14:00))?",
+ "x-samm-aspect-model-urn" : "urn:samm:org.eclipse.esmf.samm:characteristic:2.2.0#Timestamp",
+ "description" : "Describes a Property which contains the date and time with an optional timezone."
+ },
+ "BpnlTrait" : {
+ "type" : "string",
+ "x-samm-aspect-model-urn" : "urn:samm:io.catenax.shared.business_partner_number:2.0.0#BpnlTrait",
+ "description" : "The provided regular expression ensures that the BPNL is composed of prefix 'BPNL', 10 digits and two alphanumeric letters.",
+ "pattern" : "^BPNL[a-zA-Z0-9]{12}$"
+ },
+ "SemanticVersioningTrait" : {
+ "type" : "string",
+ "x-samm-aspect-model-urn" : "urn:samm:io.catenax.shared.message_header:3.0.0#SemanticVersioningTrait",
+ "description" : "Constraint for defining a SemVer version.",
+ "pattern" : "^(0|[1-9][0-9]*).(0|[1-9][0-9]*).(0|[1-9][0-9]*)(-(0|[1-9A-Za-z-][0-9A-Za-z-]*)(.[0-9A-Za-z-]+)*)?([0-9A-Za-z-]+(.[0-9A-Za-z-]+)*)?$"
+ },
+ "HeaderCharacteristic" : {
+ "description" : "Characteristic describing the common shared aspect Message Header",
+ "x-samm-aspect-model-urn" : "urn:samm:io.catenax.shared.message_header:3.0.0#HeaderCharacteristic",
+ "type" : "object",
+ "properties" : {
+ "messageId" : {
+ "description" : "Unique ID identifying the message. The purpose of the ID is to uniquely identify a single message, therefore it MUST not be reused.",
+ "x-samm-aspect-model-urn" : "urn:samm:io.catenax.shared.message_header:3.0.0#messageId",
+ "$ref" : "#/components/schemas/UuidV4Trait"
+ },
+ "context" : {
+ "description" : "Information about the context the message should be considered in.\nThe value MUST consist of two parts: an identifier of the context (e.g. business domain, etc.) followed by a version number.\nBoth the identifier and the version number MUST correspond to the content of the message.\nIf the content of a message is described by an aspect model available in the Catena-X Semantic Hub, then the unique identifier of this semantic model (e.g. urn:samm:io.catenax.:1.x.x) MUST be used as a value of the context field. This is considered the default case.\nIn all other cases the value of the context field MUST follow the pattern --