Effective requirement management and tracking with Requirements Yogi
NB! Please note that the product features listed in the article may change over time.
Requirements Yogi is an application for Confluence and Jira that allows you to describe and track requirements efficiently.
The following post will provide an overview and give examples of Requirements Yogi plugin on the Confluence Cloud platform.
In addition, Vesta Laansoo, the team leader of support information systems at the Centre of Registers and Information Systems (RIK for short), reveals the reason for implementing Requirements Yogi and describes the situations where it facilitates requirements management.
It is also possible to describe requirements in a standard Confluence table - what is the efficiency of Requirements Yogi?
Requirements Yogi contains three macros and a dedicated search engine for requirements. In short, the application is helpful for managing requirements systematically thanks to the following options:
- give an individual key to each requirement
- display all information related to the requirement in its detail view
- refer to the requirements in a standardized way
- create links between requirements
- create different versions of requirements and compare them
- query requirements from Requirements Yogi search engine.
But still – why do we need the macros, and what does it all look like? Let's explain more and see some examples!
When describing requirements, it would be best to start by granting it a key (with Requirement Yogi macro).
Figure 1. Requirements Yogi 3 macros.Type /req on the keyboard to add them quickly and conveniently.
The requirement key is a unique identifier of the requirement, which consists of the desired letters and/or numbers. Clicking on the key opens a detail view of the requirement.
Thanks to the key, it is possible to link requirements (with Requirement Yogi Link macro) and reference to requirements in a standard form across documentation.
Figure 2. Detail view of a requirement, where related information is divided into sections.
The plugin vendor recommends describing requirements in a table to get the most out of the application and create a concise overview of the requirements.
Figure 3. Table of requirements.
The Requirement Yogi Configuration macro enables us to configure requirement properties and column types to change how the requirements are indexed.
The column type also determines how and where the information entered in the table corresponds to the data displayed in the detail view of the requirement.
Figure 4. RY configuration macro.
In the Configuration macro above, we can see that types of the "Seotud" and "Blokeerib" columns are marked as "Dependency".
According to this kind of configuration, any requirement added to these columns creates links between the requirements.
In the detail view of the requirement, the links are displayed in the Dependencies section (see figure 1), where both outgoing (<) and incoming (>) relationships are shown.
As for the Configuration macro, it is impossible to override some properties' names, which is unintuitive in the macro configuration view.
Let's look at the configuration table view (see figure 4). We can notice that Column 3 is marked as a Description type column. Additionally, for Column 3, there is a value "Kirjeldus" on the "Override name" field; however, this name is still not changed in the detail view (see Figure 2) of the requirement.
The same is true for the Requirement column in the Column 1 row, where the Override name field has the value "Nõue", but the detail view displays it as "Key".
More and more requirements are created during the process - how to track and search for them effectively?
Describing requirements with Requirements Yogi macros is also cool because we can retrieve them from a special search engine based on different criteria.
For example, you can query the requirements:
- through the Confluence page - page ~ 'Confluence page'
- via link type - to@Blocks = 'REQ-004' for requirements that block requirement REQ-004
- via Confluence space – space = ’CONFLUENCE’
- via linked Jira issue - jira = 'key-1'
- via any property value (for example author or priority) - @Priority = 'High' or @Author = 'Trinidad Atlassian'
- via text - text ~ '% something'
Figure 5. Requirements Yogi's requirements search engine.
Quite recently, a new feature, Variants, was released on Requirement Yogi Cloud.
Variants allow us to create multiple versions of a single requirement. To track different versions of a requirement, we can use the Modification Matrix.
With Modification Matrix, it is also possible to filter version changes by various criteria - for example, to display changes made only in the Description field.
Figure 6. Requirements Yogi Modification Matrix.
Centre of Registers and Information Systems user experience with the Requirements Yogi plugin
The Centre of Registers and Information Systems uses the Requirements Yogi plugin to describe requirements in Confluence.
The application is implemented on an on-premise platform, but the product's core features are similar (except for variant functionality).
We asked Vesta Laansoo, team lead of RIK information support systems, about the need for Requirement Yogi and how it creates additional value.
How did you come up with a decision that you needed the Requirements Yogi plugin?
"There were some downsides to the options we had in the past, and Confluence didn't have another referral solution for us," Vesta said.
What is the primary value of Requirement Yogi for your team?
"Requirements Yogi allows you to use referencing for similar requirements instead of copy-paste. It also helps to keep the requirements up to date with less effort - by describing the component used in different requirements as a separate requirement," she explains.
"Thus, through the reuse of requirements, it is easy to show connections and display the whole to form correct and traceable documentation," the team leader summarizes.
