docs: arc42 enhancement with business context (eclipse-tractusx#158)

* docs(update):Update Architecture Constraints description
* docs:update Context and scope documentation
* docs: update Requirements
---------
Reviewed-By: Phil Schneider <[email protected]>

Author: jjeroch

docs/architecture/Architecture Constraints.md

@@ -1,33 +1,53 @@
-# Architecture Constraints
+# Architecture Constraints Documentation
 
-## General
+## Overview
 
-- The SSI Credential Issuer is a central API for the handling of credentials. It handles the wallet communication for the creation and revocation of credentials of the issuer and holder. Another purpose is the expiry handling and automatic revocation of already expired credentials. There is no plan to implement an UI at the current stage.
+The following document outlines the architecture constraints for the SSI Credential Issuer App. This App serves as a central point for credential handling, including creation, revocation, and expiration management. The constraints outlined in this document are intended to guide the development and deployment of the system to ensure it meets the specified requirements and adheres to the defined standards.
 
-- Run anywhere: can be deployed as a docker image, e. g. on Kubernetes (platform-independent, cloud, on prem or local).
+## General Constraints
 
-## Developer
+### System Purpose
 
-- OpenSource software first - FOSS licenses approved by the eclipse foundation has to be used. It could represent the initial set that the CX community agrees on to regulate the content contribution under FOSS licenses.
+- **Credential Management**: The SSI Credential Issuer App is designed to manage digital credentials, handling tasks such as creation, revocation, and automatic expiration of credentials for both issuers and holders.
+- **Communication**: The App facilitates communication with wallets, enabling the management of credentials.
+- **No User Interface (UI)**: The current development plan does not include the implementation of a user interface. However an user interface interaction got implemented as part of the portal project.
 
-- Coding guidelines for FE and BE are defined and are to be followed for all portal related developments.
+### Deployment
 
-- Apache License 2.0 - Apache License 2.0 is one of the approved licenses which should be used to respect and guarantee Intellectual property (IP).
+- **Run Anywhere**: The system is designed to be containerized and deployable as a Docker image. This ensures it can run on various platforms, including cloud environments, on-premises infrastructure, or locally.
+- **Platform-Independent**: The application is platform-independent, capable of running on Kubernetes or similar orchestration platforms.
 
-- Code Analysis, Linting and Code Coverage - Consistent style increases readability and maintainability of the code base. Hence, we use analyzers to enforce consistency and style rules. We enforce the code style and rules in the CI to avoid merging code that does not comply with standards.
+## Developer Constraints
 
-## Code analysis, linting and code coverage
+### Open Source Software
 
-As part of the standard reviews, following code analysis and security checks have been executed:
+- **FOSS Licenses**: All software used must be open-source, with licenses approved by the Eclipse Foundation. These licenses form the initial set agreed upon by the CX community to regulate content contributions.
+- **Apache License 2.0**: The Apache License 2.0 is selected as the approved license to respect and guarantee intellectual property rights.
 
-- SonarCloud Code Analysis
-- Thread Modelling Analysis
-- Static Application Security Testing (SAST)
-- Dynamic Application Security Testing (DAST)
-- Secret Scans
-- Software Composition Analysis (SCA)
-- Container Scans
-- Infrastructure as Code (IaC)
+### Development Standards
+
+- **Coding Guidelines**: Defined coding guidelines for frontend (FE) and backend (BE) development must be followed for all portal-related developments.
+- **Consistency Enforcement**: Code analysis tools, linters, and code coverage metrics are used to enforce coding standards and maintain a consistent style. These standards are enforced through the Continuous Integration (CI) process to prevent the merging of non-compliant code.
+
+## Code Analysis and Security
+
+To ensure code quality and security, the following analyses and checks are performed during standard reviews:
+
+### Code Quality Checks
+
+- **SonarCloud Code Analysis**: Automated code review tool to detect code quality issues.
+- **Code Linting**: Tools to enforce coding style and detect syntax errors.
+- **Code Coverage**: Metrics to ensure a sufficient percentage of the codebase is covered by automated tests.
+
+### Security Checks
+
+- **Thread Modelling Analysis**: Assessment of potential security threats and vulnerabilities.
+- **Static Application Security Testing (SAST)**: Analysis of source code for security vulnerabilities.
+- **Dynamic Application Security Testing (DAST)**: Testing of the application in its running state to find security vulnerabilities.
+- **Secret Scans**: Detection of sensitive information such as passwords or API keys in the codebase.
+- **Software Composition Analysis (SCA)**: Evaluation of open-source components for security risks.
+- **Container Scans**: Analysis of Docker container images for vulnerabilities.
+- **Infrastructure as Code (IaC)**: Analysis of infrastructure definitions for security and compliance.
 
 ## NOTICE
 

docs/architecture/Context and scope.md

@@ -2,12 +2,15 @@
 
 ## Business Context
 
-The SSI credential issuer is created to enable the communication with wallets and handle the creation, revocation and expiry of credentials.
-Additionally it gives the user a overview of available use case credentials.
+The Self-Sovereign Identity (SSI) credential issuer core purpose is to facilitate seamless communication with digital wallets, which are essential tools for managing digital identities. Being responsible for the critical functions of creating, revoking, and managing the expiry of credentials. This ensures that issuers maintain control over their issues digital identities.
+
+To further enhance the user experience, the SSI credential issuer provides users with a comprehensive overview of available use case credentials. By doing so, it empowers users to make informed decisions about which credentials to acquire and use. The business context of the SSI credential issuer is thus centered around providing a robust, user-friendly, and secure mechanism for identity management.
 
 ## Technical Context
 
-The SSI credential issuer comprise the technical foundation for interaction, monitoring, auditing and further functionalities. They are state of the art in terms of technology portfolio, consist of open-source components whenever possible and are open-sourced themselves 100%.
+From a technical standpoint, the SSI credential issuer is built on a foundation that promotes interaction, monitoring, auditing, and a host of other functionalities that are crucial for maintaining a secure and reliable identity management system.
+
+A key aspect of the technical context is the commitment to open-source principles. The SSI credential issuer is constructed with open-source components to the greatest extent possible, fostering a collaborative and transparent development environment. Moreover, the entire codebase of the SSI credential issuer is open-sourced, reflecting a 100% commitment to the open-source community.
 
 ## NOTICE
 

docs/architecture/Requirements.md

@@ -1,16 +1,38 @@
 # Requirements overview
 
-## What is the Portal & Marketplace Product?
+The development and deployment of the Self-Sovereign Identity (SSI) credential issuer necessitate a comprehensive set of requirements that span across various domains including functional, security, performance, and usability aspects. This overview encapsulates the fundamental requirements that will guide the design and implementation of the SSI credential issuer to ensure it meets the intended objectives and user needs.
 
-The SSI Credential Issuer is a central API for the handling of credentials. It handles the wallet communication for the creation and revocation of credentials of the issuer and holder. Another purpose is the expiry handling and automatic revocation of already expired credentials. There is no plan to implement an UI at the current stage.
+## Functional Requirements
 
-## Requirements
+- **Credential Management**: The system must support the creation, issuance, revocation, and expiration of digital credentials.
+- **Communication Interface**: Seamless interaction with digital wallets and other SSI services must be facilitated through a robust communication interface.
+- **Interoperability**: The issuer must be compatible with various wallet applications and adhere to relevant SSI standards.
+- **Scalability**: The system should be designed to scale efficiently as the number of users and credentials grows.
 
-<!-- TODO (JJ): could you please add the requirements -->
-For Catena-X Member Companies
-|ID|Title|Requirement|
-|--------|--------|--------|
-|REQ|tbd|tbd|
+## Security Requirements
+
+- **Authentication and Authorization**: Secure methods must be employed to authenticate users and authorize actions within the system.
+- **Data Protection**: Personal and sensitive data should be encrypted and protected from unauthorized access.
+- **Audit Trails**: The system should maintain detailed logs for all actions to enable monitoring and auditing.
+- **Compliance**: The issuer must comply with relevant privacy and security regulations such as GDPR, CCPA, etc.
+
+## Performance Requirements
+
+- **Response Time**: The system should provide timely responses to user requests to ensure a smooth user experience.
+- **Throughput**: It must be capable of handling a high volume of transactions and operations without degradation in performance.
+- **Reliability**: High availability and fault tolerance must be ensured to maintain continuous operation.
+
+## Usability Requirements
+
+- **Accessibility**: The interface should be accessible to a diverse user base, including those with disabilities.
+- **Simplicity**: The design should be intuitive, allowing users to easily navigate and perform actions without extensive training.
+- **Documentation**: Comprehensive documentation should be provided to assist users and developers in understanding and using the system.
+
+## Technical Requirements
+
+- **Technology Stack**: Utilization of state-of-the-art, open-source technologies to ensure robustness and facilitate community contributions.
+- **Modularity**: The architecture should be modular to allow for easy updates and maintenance.
+- **Integration**: The system should provide APIs and hooks for integration with other systems and services.
 
 ## NOTICE