Spira 6.13 - SAFe Support for Requirement Types

November 4th, 2021 by inflectra

spotlight roadmap scaled agile safe epic

The upcoming release of our Spira platform includes a major change in how requirement types work, specifically when you have multiple levels of parent requirements and you want/need control over what the type is for those requirements. Previously, parent requirements were forced to be either Package (Spira versions 5.4 and earlier) or Epic (Spira versions 6.0 and later). Recognizing that we need more flexibility for different methodologies such as Scaled Agile (SAFe), Waterfall and Agile/Scrum/Kanban, we have completely revamped how this feature works.

Requirements Hierarchies in Scaled Agile (SAFe)

When you are implementing Essential SAFe in a project / team environment, you will usually want to structure your requirement items in the following hierarchy:

Where the Feature and User Story requirement items are considered team artifacts and the Epic requirement items are release train (aka Spira Product) artifacts.

Requirements Hierarchies in Waterfall

Conversely when you are working on traditional waterfall (or other non-agile methods such as V-Model), you will usually want a more structured hierarchy based on the type of requirements:

For example, you might have:

Business Requirements
- Module 1
  - Requirement 1.1
  - Requirement 1.2
- Module 2
  - Requirement 2.1
  - Requirement 2.2
- Module 3
System Requirements
- Module 1
  - Requirement 1.1
  - Requirement 1.2
- Module 2
  - Requirement 2.1
  - Requirement 2.2
- Module 3
Use Cases
- Use Case UC1
- Use Case UC2
System Qualities
- Scalability
  - Scalability Requirement 1
  - Scalability Requirement 2
- Usability
  - Usability Requirement 1
  - Usability Requirement 2

Requirements Hierarchies in Agile/Scrum/Kanban

Finally, for classic Agile projects (e.g. Scrum, Extreme Programming, or Kanban) that don't use Scaled Agile concepts, you might have a simple two-level hierarchy of Epic and User Story requirements, with the stories having Tasks underneath the user stories:

Changes to Requirements Type in 6.13

So to make it easier for customers to use Spira for these different types of project, we have made a major change in Spira 6.13.

In previous versions, when you had a requirement that contained children, it would automatically have its type set to either Package (v5.x) or Epic (v6.x). This was regardless of its original type before it became a parent.

Now with version 6.13, we have changed the way requirements work to allow you to make a requirement a "summary" type (with children) and keep its original type. This lets you have a more flexible hierarchy of requirements with different types. In addition, it will make synchronization of requirements with tools such as Atlassian Jira and Microsoft Azure DevOps (ADO) easier because you can now map the specific types.

To simplify the process for new product templates, when you create a new product template in Spira, it will come with an additional requirement type called Epic: