We’ve had a lot of problems with versioned documents in Integrity and the solution does not behave as the users expect - there are many use cases that the solution doesn’t seem to support.
Only items with significant field changes are considered when a document is versioned. Because of this, traceability and non-significant fields cannot be trusted in the versioned document - they will show the state of the field when the node was last significantly changed rather then when the document was last versioned.
We have a field called Change Status with values new, modified, unmodified and deleted. When the document is re-opened then the change status is reset to unmodified. This works well in the live document but the versioned document will either show new or modified. When an item is unmodified then it hasn't had a significant change to update the versioned item. If we made Change Status significant then it would cause suspect flags on every item when the document was re-opened. This also applies to other fields that are not significant.
Traceability is not typically a significant field. If a trace is added or removed, then unless the requirement text is also changed, the traceability will be incorrect in the versioned document - this is unacceptable to many of our users. The traceability cannot be made significant without massive downstream impact. If there was a requirement with 5 requirements tracing to it and then 5 requirements tracing to each of them then a trace change at the top requirement would cause suspect flags to be created on the child requirements, which would then cause suspect flags to be created on the requirements tracing to them. This would ripple through the requirements marking them all as suspect. If you then cleared a suspect flag then that would also be considered a significant change and would cause all downstream requirements to be marked as suspect again.
A change to R2 causes updates to R4 and R5 just for traceability. If there were requirement below R4 and R5 then these would also be modified.
A better solution for versioned documents is needed. One possible solution would be to store the traceability between versioned items separately to the version items themselves, otherwise changes to the traceability cause new versions of the items to be created. You could then create a release with version X of the parent document, version Y of the child document and version Z of the traceability between them. This approach would allow you to update the traceability independently of the requirements themselves. If you could do that then you could update requirements without affecting the traceability and also version non-significant fields without any downstream impact.
1 Comment
