Use Case Mapping with SpiraTeam and SpiraPlan

July 15th, 2021 by inflectra

use cases business analysis requirements management

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.

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

Get Started with Spira for Free

And if you have any questions, please email or call us at +1 (202) 558-6885

Free Trial