-
Notifications
You must be signed in to change notification settings - Fork 20
Open
Description
For versioning requirements, it was agreed that we will try the 'Hash calculation' approach.
What should it do?
- Calculate a hash for each requirement based on certain attributes of said requirement. Attributes so far selected: ("id", "title", "content", "reqtype", "security", "status".)
- Find all links to current requirement and populate the linked requirements hashes too.
- Implement warnings that run during build & incremental that will warn the user if a hash of a requirement that it depends on has changed and show the appropriate method of fixing it.
- Have an 'overwrite' option that allows for overwriting 'linked-hashes' values to bring them back up to harmony with changed requirements.
Current Progress:
There is an MVP in the works, that implements this as a Builder, this way it can be specified as a seperate 'bazel run //docs:hash_calc_build` command or similar, and there is no 'accidental' usage of it, which might be the case if we would add it to a 'docs:incremental' or similar command as an option.
A 'finished' requirements then might looks something like this:
.. feat_req:: input
:id: FEAT_REQ__TESTING
:own_hash: 06bb68
:linked_hashes: STKH_REQ__8[aa506c], STKH_REQ__9[d82c1c], STKH_REQ__20[68a015], STKH_REQ__30[0ddffe]
:reqtype: Functional
:security: YES
:safety: ASIL_B
:satisfies: STKH_REQ__8, STKH_REQ__9, STKH_REQ__20, STKH_REQ__30
:status: valid
This is a TEST feature, and this is it's content.Here own_hash as well as linked_hashes are populated automatically, and have not to be touched manually.
Since the underlying RST file will be changed, it should be made sure that the user understands this clearly and is okay with doing so.
Metadata
Metadata
Assignees
Labels
No labels
Type
Projects
Status
Draft
Status
No status
Status
No status