July 15th, 2021 by Adam Sandman
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. |
|
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.