Initiate Comprehensive Kuksa Requirements Analysis for Enhanced Version Development

[rafaeling]

This pull request marks the beginning of an in-depth analysis aimed at addressing the various challenges and use cases that contributors and the developer community have encountered with recent versions of Kuksa.

The primary goals of this PR are to:

1. Analyze Software Requirements: Conduct a thorough review of the existing software requirements against the backdrop of reported issues and use cases. This analysis will help in understanding gaps in the current implementation and areas needing improvement.

2. Lay the Groundwork for Future Updates: Establish a solid foundation for the development of an updated and improved version of Kuksa. This includes proposing initial changes or enhancements to the requirements that align with the needs of the community.

3. Identify and Document Issues: Catalogue the specific difficulties experienced by users of the latest Kuksa versions, creating a clear and structured record of known issues.

New Content:

Kuksa Analysis

[codecov[bot]]

Codecov Report

All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 50.92%. Comparing base (e628c46) to head (6eceb50). Report is 38 commits behind head on main.

Additional details and impacted files

```diff @@ Coverage Diff @@ ## main #21 +/- ## ========================================== + Coverage 48.61% 50.92% +2.30% ========================================== Files 31 31 Lines 10879 11878 +999 ========================================== + Hits 5289 6049 +760 - Misses 5590 5829 +239 ```

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

[eriksven]

@rafaeling thank you for the updates

[erikbosch]

Some thought based on the requirement discussion today - do we for the requirements and use-cases in this PR need to add a "status field" that shows the approval/implementation-status so that it is clear if the requirement/use-case represents a long term goal or actually is implemented and verified.

[eriksven]

Some thought based on the requirement discussion today - do we for the requirements and use-cases in this PR need to add a "status field" that shows the approval/implementation-status so that it is clear if the requirement/use-case represents a long term goal or actually is implemented and verified.

That is very good point, and I agree that tracking the status seems to be needed.

My initial thought was that the initial requirements document would reflect the current state of the implementation and we could then use subsequent PRs to discuss changes and additions which would just be merged once we reached an agreement on the requirement and an initial implementation fullfilling this requirement. But we already moved far away from that approach so we definitly need an approach to track the status/consensus of the different requirements. I am also happy for any solution to break down this PR into smaller fractions which can be merged independently :)

[BjoernAtBosch]

Some thought based on the requirement discussion today - do we for the requirements and use-cases in this PR need to add a "status field" that shows the approval/implementation-status so that it is clear if the requirement/use-case represents a long term goal or actually is implemented and verified.

That is very good point, and I agree that tracking the status seems to be needed.

My initial thought was that the initial requirements document would reflect the current state of the implementation and we could then use subsequent PRs to discuss changes and additions which would just be merged once we reached an agreement on the requirement and an initial implementation fullfilling this requirement. But we already moved far away from that approach so we definitly need an approach to track the status/consensus of the different requirements. I am also happy for any solution to break down this PR into smaller fractions which can be merged independently :)

I am thinking to define each requirement (and maybe each use case) as a Github issue. These could then be linked from other - implementation issues, release notes, and s on). But as Github issues are not well "sortable" we would still need some other document where we could order and link the requirements.