Use Case Mapping with SpiraTeam and SpiraPlan

July 15th, 2021 by inflectra

A customer recently posed this question to us:

We are gathering requirements following a standard template for use cases. In that template we record main scenario and alternative flows like shown on the example below. What is the best way to map primary and alternate use case process flows to requirements inside Spira?

This is a relatively common question, so in this blog we outline some ways you can manage and map use cases inside Spira....

Use Case Example

In this example, consider the following typical use case template that you might create in Microsoft Word or Excel:

ID	UC0001_Approvals
Name or Goal	Submit a Purchase Requisition
Type	User Goal, Black box, Level 4
Scope	Procurement
Actor	Purchaser
Stakeholder(s)	Purchaser Business Approver
Trigger/ event	Desire to submit a new purchase requisition based on identified need. Received an email from the system identifying an action to submit a new purchase requisition
Preconditions	Purchaser is logged into the system Purchaser is authorized to make new purchase requests Business Approver is configured to receive purchase requests from submitter.
Success conditions	Log user's access within the authentication log
Post conditions (Success guarantees)	Log user's access within the authentication log
Main success scenario	1. Purchaser selects option to submit a new purchase requisition 2. Purchaser chooses a vendor from the approved list 3. Purchaser chooses items from the approved supply catalog 4. Purchaser enters the quantity for each item 5. Purchaser enters in the justification for the purchase 6. Purchaser submits the requisition
Alternative flows	A: The vendor is not on the approved list a1. Purchaser chooses the option to request a new vendor a2. Purchaser enters the justification for using a non-approved vendor B: The item being requested is not in the approved supply catalog b1. Purchaser chooses the option to request a new supply item b2. Purchaser enters the justification for using a non-approved item
Exception flows	C: Purchaser logs out End Use Case
Non-functional requirements	NFR001 To comply with applicable regulation in any geography including for example; Regulation (EU) 2016/679 (General Data Protection Regulation) NFR002 To comply with PCI-DSS 4.0 Standards NFR003 To comply with ISO 27001 NFR004 The time to interact should be on average less than 0.5 seconds, 100% of the time NFR005 To apply multi-factor authentication where required
Dependencies & cross references

You can create a customized requirement type in Spira to capture the key fields in this template. The ID, Name, Type, Scope (Component) and Description fields can be modeled using standard fields. For the other fields, you can use requirement custom properties:

Trigger/Event - Rich Text
Preconditions - Rich Text
Success conditions - Rich Text
Post conditions - Rich Text
Stakeholders - Rich Text

The sample use case would then look like the following:

For the Non-functional requirements and Dependencies and cross-references, you can use the requirement associations tab:

However, what are the different ways we can deal with the three kinds of use case flows:

main
alternative
exceptions?

Option 1: Use Primary and Alternate Flow Custom Properties

The simplest option would be to add three more Rich Text custom properties and then you would just use a single requirement that has all the fields populated and the process flows will be just numbered lists inside the field:

When you use the requirement document view in Spira, you will see:

The main advantage of this approach is that it is quick to setup, and you can easily paste in the flows into the text boxes from the original document.

The disadvantages of this approach are that all of the exception flows are buried in the same text field, and its hard to visualize the flows since they are just a list of numbered steps.

Option 2: Use Child Use Case Requirements

Another option would be to create new child requirements for each of the use cases, and indent them under the main requirement:

The child requirements are of type 'use case' and can use the built in Scenario feature of requirements to actually have the steps be discrete items that can be visualized as a diagram automatically by Spira:

When viewed in the requirements document view it will look like:

The advantage of this method is that you can have an easy to visualize hierarchy of requirements, with the use cases nested under each requirement, and the ability to easily display the use case diagrams. The main disadvantages are that it makes all the requirements Epics and limits how the statuses and workflows can be used because the child requirements drive the workflow of the parent. This method is more work to setup than Option 2, but easier than the next and final option...

Option 3: Use Associated Use Case Requirements

The most flexible and extensible option is to use a separate requirements tree for the main use case requirements and additional trees for the different types of use case flow (main, alternate and exception).

In this approach, the main requirement and its associated scenarios are linked together using the Associations tab rather than being parent... child:

This method is the most flexible, allowing you to associate different scenarios with different requirements and use cases (many to many), but is the most complex to setup.

use cases use case mapping business analysis requirements management

Use Case Mapping with SpiraTeam and SpiraPlan

Use Case Example

Option 1: Use Primary and Alternate Flow Custom Properties

Option 2: Use Child Use Case Requirements

Option 3: Use Associated Use Case Requirements

Spira Helps You Deliver Quality Software, Faster and with Lower Risk.

Resources

Knowledge Base & Forums

Documentation

Product Integrations

Add-Ons and Downloads

System Requirements

Videos & Presentations

Pricing