Open simhein opened 9 months ago
This issue has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this issue will automatically be closed in 14 days. Note, that you can always re-open a closed issue at any time.
This issue has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this issue will automatically be closed in 14 days. Note, that you can always re-open a closed issue at any time.
This issue has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this issue will automatically be closed in 14 days. Note, that you can always re-open a closed issue at any time.
The Safety Committee / WG started the effort to gather software requirements for the Zephyr project which are needed for the safety efforts and the quality of the project. For the management of the requirements the open source tool StrictDoc was identified ( after evaluation of different tools ) as tool of choice. ( Note: The tool is not absolutely necessary for adding requirements )
The requirements are gathered in the following separate repository: https://github.com/zephyrproject-rtos/reqmgmt
The requirements in the repository where gathered and formulated by the safety committee as starting point therefore they are far from complete state.
Goal: with the following tasks a requirements base shall be generate which pushes the overall quality of the project and which can be reused for the safety effort.
The tasks where defined with the starting scope (kernel/* folder) for the safety in mind which is defined in following issue: https://github.com/zephyrproject-rtos/zephyr/issues/57702 But any software requirements can be added into the requirements repository by generating an issue and a PR within the repository and linking it into this head issue.
Within these tasks the safety WG/committee also wants to gather information how we can handle the addition of new requirements and how we can describe such a process in the documentation.