Effective requirement management and tracking with Requirements Yogi

Requirements Yogi  (opens in a new tab) 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!

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.

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 2. Detail view of a requirement, where related information is divided into sections.

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 3. Table of requirements.

In this Configuration macro, 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.

Figure 4. RY configuration macro.

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".

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'

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.

Figure 5. Requirements Yogi's requirements search engine.

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.