Spotlight on SpiraTeam 6.2 - New Requirements Management Views | Inflectra

Spotlight on SpiraTeam 6.2 - New Requirements Management Views

August 8th, 2019 by inflectra

As we get ready for the release of SpiraTest, SpiraTeam, and SpiraPlan 6.2 later this month, we'd like too introduce some of the new functionality that will be available in this release. In the first installment of this series, we're excited to announce the new requirements management views that have been added to SpiraTeam and SpiraPlan 6.2. They are designed to better serve the needs of the Business Analyst community who often need different views of requirements than the project teams and project managers.

Existing Requirements Management View

If you have used the requirements management features in SpiraTeam, you will be familiar with the hierarchical grid view that is displayed when you first click on the Planning > Requirements item in the navigation bar. This view lets you see all of the requirements in a hierarchical manner, from the most general business requirements, functional areas, decomposed down to the lower-level system requirements, use cases, user stories, and design elements. This view is a great way to expand and collapse the requirements to different levels, see the test coverage and the % complete, and view / filter on the various columns available.

However in our meetings with customers during the year, we realized that additional views for different situations and different groups using SpiraTeam, could be very helpful.

Requirements Document View

The first new view we have added is the document view. This view also offers a hierarchical organization of all the requirements in a product / project, but instead of being displayed in a grid form, they are displayed in a document format that is designed to be readable from top to bottom, like a traditional requirements document. The new view has a sidebar that lets you quickly jump to a section in the requirements document as well as simply scroll through all of the items.

For each requirement, SpiraTeam will display the ID, name, full text description, status, priority/importance, and type of the requirement. The full text will include any embedded tables, images, bullets, links, and lists. In addition, for requirements that have scenarios / steps defined, it will also show a process flow diagram.

Support for Use Case Process Flow Diagrams

In SpiraTeam you can write requirements that have a list of steps defined (called a scenario). Typically they are used for use cases, but you allow any requirement type to have steps. In this new view, SpiraTeam will display the list of steps as a process flow diagram rather than a simple list:

In addition to being available on the new requirements document view, inside each requirement that has steps, there is a new Diagram tab that displays the same process flow diagram:

You still write the scenario in the main Overview tab as a list of steps, however SpiraTeam will now render that in real time as a process flow diagram.

This new diagram feature uses the open source GraphViz graphing engine developed by MIT and rendered by the same D3 engine that we use for the other graphs and charts within SpiraTeam. However that is not the only diagram we have added...

Requirements 'Mind Map' View

Based on analyzing the requests from our users and their need to be able to better visualize requirements, both the primary hierarchy and the associations/links between requirements, we have introduced a new mind map view in SpiraTeam 6.2 as well:

This new view will display the requirements as a mind map diagram, with the root nodes displayed on the left hand side, with their successive children shown from left to right. it will display the name and ID of the requirement in each node, with a tooltip that shows the description and any comments. In addition, each node will be color coded by its priority / importance value.

Requirements Dependencies and Associations

As well as showing the primary hierarchy, there is an option to turn on the display of requirement associations as well. This will let you see all of the associations as dotted lines. For associations that denote dependencies there is an arrow and dotted line that shows the direction of the dependency. For simple relationship  (relates to) associations, there is a dotted line without an arrow. The system will display either the comment or type of association, depending what was entered when the association was created:

Requirements Sorted Grid View

The last of the new views is similar to views that we already have for tasks and defects - a sortable list view. This view lets you view the requirements in a flat, sortable list that does not show the requirements hierarchy.

You can still see the hierarchy of an item by hovering the mouse over its name to display the tooltip.

This view lets you sort on any of the fields and also filter by the type of requirement, including whether it is an Epic (package) or not.

One major benefit of this view is that when you filter by a field, you only get the items that are a direct match, unlike in the hierarchical grid view, where you also get its parents displayed. It can be useful when displaying a list of just the Epics and nothing else:

Requirements Agile Board View

The final view we have added is a dedicated requirements agile board view. It is similar to the existing Planning Board but only displays requirements, whereas the primary planning board will also include incidents / defects. This gives the requirements page consistency with the tasks and incidents pages that already have a Grid / Board view selector option.

 

How Do I Get The New Functionality?

For SpiraTeam and SpiraPlan customers, all you need to do is upgrade to v6.2 to get the new functionality. It will be available for cloud customers at the end of August and available for download customers around the same time.

If you have SpiraTest, you will need to upgrade to either SpiraTeam or SpiraPlan to get the new functionality.

spotlight roadmap spirateam spiraplan requirements management business analysis