What’s new in Polarion Collections

You might remember that over the last several Polarion releases we have made significant improvements to the Collection capability of Polarion. For those of you that might not be familiar with Collections, let me take a moment to explain what Collections are and why you might want to use them. Polarion Collections are a powerful feature within Polarion that allow you to group related live documents and associated Work Items together. Think of them as dynamic, organized containers for specific sets of requirements, test cases, defects, tasks, or any other type of work item defined in your Polarion project. Unlike a static query or a simple folder, a Collection captures a snapshot or a specific view of live documents and work items that are relevant for a particular purpose, even if those work items belong to different projects.

But what’s truly special about Collections is that they can contain a mix of head as well as revisioned work-items at the same time and present them in a distinct view. This allows them to be used to support a variety of different use cases.

Why You Might Use Polarion Collections:

Collections support many different use cases to improve organization, complex processes, tracking, reporting, and collaboration within your development lifecycle. Lets look at some of these in more detail.

1. Concurrent Development
   • Purpose: Develop work products in parallel and handle change efficiently.
   • Use Case: In complex product development with the V model, where work goes on in parallel, teams working at a lower level in the V model will often work with upstream lifecycle artifacts at an earlier baseline to their current baseline. These teams need to ensure they work with the correct baselines as well as an efficient way to handle upstream links if indeed work-items change to a later (or even earlier) baseline. It is essential for these teams to avoid having to manually relink work-items.
2. Baseline Management:
   • Purpose: To create a stable, immutable snapshot of a specific set of live documents and work items (e.g., requirements, test cases) at a particular point in time. This is crucial for formal reviews, releases, or contractual agreements.
   • Use Case: Before a major software release, you can create a Collection of all approved requirements and associated test cases. This Collection can then be baselined, providing a fixed reference point for what was delivered in that version.
3. Release Planning and Tracking:
   • Purpose: To group all live documents and work items (features, bugs, tasks) planned for a specific release or sprint.
   • Use Case: Create a “Release 1.0 Scope” Collection containing all user stories, tasks, and critical bug fixes targeted for your upcoming product launch. This allows you to easily track the progress of all items contributing to that release.
4. Compliance and Audit Trails:
   • Purpose: To demonstrate that specific sets of live documents and work items meet certain criteria or have undergone specific processes.
   • Use Case: For regulatory compliance (e.g., medical devices, automotive), you might need to prove that all safety-critical requirements have associated test cases and have passed all tests. A Collection can group these items, making it easier to show traceability for audits.
5. Cross-Project or Cross-Document Grouping:
   • Purpose: To bring together related live documents and work items that might be scattered across different projects within your Polarion instance.
   • Use Case: If a new regulation impacts requirements in multiple product lines (different projects), you can create a Collection of all affected requirements across those projects to manage the impact analysis and updates centrally.

In essence, Polarion Collections provide a flexible and powerful way to define and manage logical groupings of live documents and work items, enabling better organization, focused tracking, precise reporting, and robust baseline management for complex development efforts.

Over the last several releases we have being further improving this powerful capability of Polarion. Our focus has being principally in two different areas:

Collection hierarchy

A Polarion hierarchical collection extends collections even further by allowing parent child relationships between the collections themselves. We often use decomposition as a way to show complex structures. It provides a natural way to break work products down into smaller more manageable pieces. Polarion hierarchical collections also opens up a powerful feature where work-items links can exist across or between the collections within the hierarchy. This approach provides you with more flexibility on how you may wish to organize and group your work-items. It also helps and saves time if upstream items require change. For example, you can replace a upstream collection in its entirety with a earlier or later baseline. Any lower level collections that have work-items that have valid links to work-items in the new upstream collection baseline will automatically point to the correct baseline without any manual intervention or rework. Hierarchical collections also helps with efficient reuse, as you are able to reuse an entire collection baseline over and over again in a entirely new collection hierarchy. Polarion will only ever show links between work-items across collections that are valid to your current collection hierarchy.

Key Characteristics of Polarion Hierarchical Collections

1. Structure: Hierarchical collections organize work items in a natural tree-like structure with parent-child relationships
2. Baselining: Hierarchical collections can contain a mix of Head as well as baselined collections
3. Customizable: Collections can be customized to match specific project needs or organizational structures
4. Reusability: Reuse the same collection baseline in other hierarchies
5. Metadata: Collections can have their own properties and attributes at each level
6. Traceability: Enables complete traceability between different work items across levels
7. Efficient change management: If upstream collections change, they can be easily managed without having to spend time relinking the downstream items.

Use Case: Product Requirements Management

Example: Automotive Electronic Control Unit (ECU) Development

In automotive software development, a hierarchical collection could be structured as:

ECU Project (collection)
├── System Requirements (collection)
│   ├── Functional Requirements (live doc)
│   │   ├── FR-001: Engine Control
│   │   ├── FR-002: Diagnostic Functions
│   │   └── FR-003: Safety Features
│   └── Non-Functional Requirements (live doc)
│       ├── NFR-001: Performance
│       └── NFR-002: Reliability
├── Software (collection)
│   └── Software Requirements (live doc)
│       ├── SW-001: Engine Control Algorithm
│       └── SW-002: Diagnostic Protocol
└── Test Cases (collection)
    └── Test Cases specification (live doc)
        ├── TC-001: Engine Control Test
        └── TC-002: Diagnostic Function Test

This structure allows teams to:

• Use collections and live docs to represent each “level” of the hierarchy as shown
• Maintain clear traceability from test cases all the way up to system requirements
• Organize work by functional areas
• Track progress at different levels of granularity
• Manage dependencies between related items
• Work with different baselines of collections efficiently
• Handle change effectively
• Generate comprehensive reports showing coverage and completion status

The hierarchical collection makes it easier to navigate complex projects, work concurrently, understand relationships between work items, handle change efficiently and maintain a clear overview of the entire development process.

Collection Reporting

Collection Reporting is a powerful enhancement that allows users to generate comprehensive reports based on collections. This feature enables stakeholders to:

1. Create customized reports that aggregate data from multiple levels of a collection
2. Visualize progress and status across the entire collection structure
3. Track metrics and KPIs at different hierarchical levels
4. Reports stay associated with the collection allowing you to view them easily
5. Easily reuse reports across different collections and collection hierarchies

Use Case: ECU Development with Collection Reporting

Using our previous automotive ECU development example:

ECU Project (collection)
├── System Requirements (collection)
│   ├── Functional Requirements (live doc)
│   │   ├── FR-001: Engine Control
│   │   ├── FR-002: Diagnostic Functions
│   │   └── FR-003: Safety Features
│   └── Non-Functional Requirements (live doc)
│       ├── NFR-001: Performance
│       └── NFR-002: Reliability
├── Software (collection)
│   └── Software Requirements (live doc)
│       ├── SW-001: Engine Control Algorithm
│       └── SW-002: Diagnostic Protocol
└── Test Cases (collection)
    └── Test Cases specification (live doc)
        ├── TC-001: Engine Control Test
        └── TC-002: Diagnostic Function Test

How Collection Reporting Could Be Used:

1. Requirements Coverage Analysis
   • Generate a report showing which System Requirements have corresponding Software Requirements and Test Cases
   • Visualize coverage gaps where requirements lack test coverage
   • Calculate coverage percentages at each level of the hierarchy
2. Progress Tracking Dashboard
   • Create a real-time dashboard showing completion status across all levels
   • Display progress metrics like “% Complete” for each branch of the collection
   • Highlight critical path items that are behind schedule
3. Compliance Documentation
   • Generate a compliance report that maintains the hierarchical structure
   • Include traceability matrices showing relationships between items
   • Document verification status for each requirement
4. Risk Assessment
   • Identify high-risk areas by aggregating risk scores across the collection
   • Visualize which branches of the hierarchy contain the most critical items
   • Track mitigation status for identified risks
5. Release Readiness
   • Generate a report showing test execution status for all requirements
   • Calculate quality metrics across the collection hierarchy
   • Provide executive summaries with drill-down capabilities

Example Report: Requirements Traceability and Verification Status

A collection report might show

The coverage report shows a consolidated view of system requirements, software requirements with their associated test cases and current status. This information is pulled from the various definitions defined within the collection context.

The report instantly highlights that FR-003 needs attention as it lacks both software requirements and test cases, while FR-002 is partially implemented but testing hasn’t begun.

Collection Reporting transforms collections from organizational structures into powerful analytical tools that provide insights across the entire development lifecycle while maintaining the context of relationships between work items. In addition, the same reports can be easily reused across different collections and collection hierarchies without the need to change the report itself. Thus allowing you to define standardized reporting across multiple collections.

To help further explain the new Collection reporting capability my colleague Ondrej has created a short video to show it in action!

If you are interested in trying things out yourself in your own drive pilot project, here is the script for the report we used in the the demo.

{
    chart: {
        type: 'pie',
        options3d: {
            enabled: true,
            alpha: 45,
            beta: 0
        }
    },
    title: {
        text: 'Requirement Coverage'
    },
    plotOptions: {
        pie: {
            allowPointSelect: true,
            cursor: 'pointer',
            depth: 35,
            dataLabels: {
                enabled: true,
                format: '{point.name}: {point.y}'
            },        
            showInLegend: true
        }
    },
    series: [{
        type: 'pie',
        name: 'Requirements',
        colors: ['#8bbc21', '#910000'],
        data: [

#set($collectionReference = $transaction.context.contextCollection)

#set($query1 =              "SELECT wi.c_uri, wi.c_col_rev")
#set($query1 = "$query1        FROM col_workitem wi")
#set($query1 = "$query1    WHERE (wi.c_type = 'systemrequirement' OR wi.c_type = 'softwarerequirement')")
#set($query1 = "$query1        AND EXISTS (")
#set($query1 = "$query1            SELECT child.c_uri")
#set($query1 = "$query1                FROM col_workitem child,")
#set($query1 = "$query1                     col_struct_workitem_linkedworkitems link")
#set($query1 = "$query1                WHERE link.fk_uri_workitem = wi.c_uri AND link.c_role = 'verifies'")
#set($query1 = "$query1        )")

#set($verified = $transaction.objects.searchBySql($query1).collection($collectionReference).size)

#set($query2 =              "SELECT wi.c_uri, wi.c_col_rev")
#set($query2 = "$query2        FROM col_workitem wi")
#set($query2 = "$query2    WHERE (wi.c_type = 'systemrequirement' OR wi.c_type = 'softwarerequirement')")
#set($query2 = "$query2        AND NOT EXISTS (")
#set($query2 = "$query2            SELECT child.c_uri")
#set($query2 = "$query2                FROM col_workitem child,")
#set($query2 = "$query2                     col_struct_workitem_linkedworkitems link")
#set($query2 = "$query2                WHERE link.fk_uri_workitem = wi.c_uri AND link.c_role = 'verifies'")
#set($query2 = "$query2        )")

#set($unverified = $transaction.objects.searchBySql($query2).collection($collectionReference).size)

            {
                name: 'Verified',
                y: $verified,
                sliced: true,
                selected: true
            },
            {
                name: 'Unverified',
                y: $unverified,
                sliced: true,
                selected: true
            }
        ]
    }]
}

We’re not done yet though. Look for even more exciting improvements to come with Collections and reporting in our Polarion 2512 release!