Review managing and administration

When we conduct a review, for example a collection of requirements relating to performance, in person during a meeting, in the presence of performance specialists, the participants in this review are either reviewer or validator.
To secure this review, no one should be able to change any requirements present in this review.
However, during the course of the review, the requirements listed there must be able to be modified live because it is possible to have to adjust the body of the text of the requirement.
Project members must therefore be able to see here or there that a requirement is locked against modification because it is included in a review.
Only the designated validator should be able to do this or, failing that, Doors NG should provide new operations dedicated to reviews.
Project members must be able to continue to modify any other requirements not documented in a review.
IBM documentation recommends creating a baseline before doing a review. Then launch the review. Then at the end of the review, create a reference version again.
Putting a requirement in a review should lock it down.
If by chance, the members of the project realize that after the review, even when finalized, something has been forgotten, they must be able to get out of this by allowing the review to be reopened.
Concretely, new operations dedicated to journals would be useful:
- Reopen a finalized review
- Authorize the modification of an artifact registered in a journal
- Authorize the modification of an artifact to any member of the journal
- Limit the modification of an artifact to the approver only
- Limit the modification of an artifact to the journal pilot only
- Block the modification of an artifact to any member not declared in a journal
- Warn project members of the presence of an artifact in a journal