Use case
The requirements for a particular version (say 10.8) are reviewed, approved and released (i.e. 'Published' state). The development team starts developing on 10.8, and the test team is testing 10.7, while in the meantime the requirements analyst is already drafting requirements for 10.9.
Although the requirements have been approved, changes can still occur. A developer or tester can find things that require a requirement revision for e.g. 10.8 or 10.7. Or, because of the agile trend that fixes the release dates more than the scope, some requirements might have to be re-specified or even dropped (or added) from (or to) a version. The requirements for that particular version have to go through a change process and this without bringing in the new changes from the latest draft (10.9).
In this use case, a version is not only a point in history, it is also an item that can change. In Integrity terms it is a ‘live item’ by itself.
Our current way of working
We have a branch for every 'as released' version. This allows parallel development on the documents of 10.7, 10.8 and 10.9. But this creates a lot of similar (or even duplicate) information and requires a careful change management process with a risk to introduce mismatches to future versions. Add Integrity's versions on top of that, and we have a lot of duplicate information in the database that reduces the efficiency and adds complexity to the change management process.
What we need
Versioned documents that are allowed to undergo a change process. This would make our current way of working with branches for versioning purposes obsolete.
One possible scenario allows to check in minor versions based on an existing version (I am open to listen to alternatives and curious how PTC handles it in their development):
- Releasing requirements corresponds with a check in and creates a version: 1.0 is created
- The live document is back in the Open state and it continues to grow towards version 2.0.
- A change request on version 1.0 is created by a developer and approved: 1.1 is created (based on version 1.0, not on the live item!)
- The requirements for the next market release are approved (check in): 2.0 is created
- The live document is back in the Open state and it continues to grow towards version 3.0.
- A change request on version 2.0 is created by a developer and approved: 2.1 is created (based on version 2.0, not on the live item!)
- A change request on version 1.1 is created by a tester and approved: 1.2 is created (based on version 1.1, not on the live item!)
