When the work finally finishes on a product release, the collection can be closed, at which point its frozen and cannot be modified any more.

By the way, if you havent read about the new Polarion 20R1 release, you can do so here.

What is a collection Well, simply put, a collection is a set of Polarion live document revisions or baselines that is either in an open or closed state.

Given that Polarion live documents normally represent (software) requirements at different levels of the development lifecycle, up to this point, it wasnt easy to create sets of document revisions in Polarion.

You were able to create spaces, with containing documents, but these documents would always represent current documents.

Something we hear our customers say would be helpful during audits or regulatory compliance activities.

This is because the same document revision or baseline can exist in multiple collections.

This is particularly useful when you have different teams of engineers that are responsible for different parts of your design but both teams must work with the same higher-level specification revision.

In that instance, two collections could be created to represent these two active team streams, with the same higher-level specification placed in both collections.

This means that when you open a document inside of a collection (see Figure 2), in the left side navigation pane, you only see the other documents that are contained in the collection.

Its super easy to hop around and navigate within the contents of the collection.

If you ever leave a collection, and its context, its very easy to see that too.

One of the primary goals of collections was that Polarion would ensure that links between the artifacts inside the collection would always be valid.

If you try and create a link to work item that isnt contained in a collection you will receive an error.

However, it may be the case that there are links inside a document that go to a target that isnt in the collection because the link was created before it was added to a collection.

In order to check for these potential problems, the new collection capability includes an consistency checker (see Figure 3) which will warn you if you have links from documents and their associated work-items pointing to artifacts outside the collection.

There is one important rule though and that is that a document head revision can only be contained in one collection.

This means that not only can collections be used for archiving and creating historic document revisions, they can also be used to work inside of with current document revisions, or a mix of current and historic document revisions.

We touched on this during our Polarion 21R1 release blog post.

In V-lifecycle development, organizations cannot wait for all the documents that represent the different levels of development to be completed before they move on to the next version or product release.

In Figure 4 above, as an example, as Team C works on their high level (HL) software specification version 2, Team D is working on the low level (LL) software specification Version 1.4 at the same time.

By using Polarion collections to support the V-lifecycle parallel development activities, one can organize ones documents in a manner that allows these documents to be developed concurrently.

Collections ensures that the context is always maintained and the links between documents is valid, thus reducing any room for error that could be caused because the user was working with the wrong document revision.

Callbridge Collection Siemens Software