Requirement Types

New in Requirement Yogi 4.0!

In 4.0.0, Key Suggestions were replaced with Requirement Types. It’s key suggestions on steroids: Same features by default, and administrators can add the validations, templates, etc.

Why use Requirement Types?

Requirement types fulfil 3 needs:

Defining key patterns: As a project is gaining maturity, key patterns for requirements are established. Administrators can define which are the main keys, and even lock down the keys that can be inserted in spaces,
Validations: Administrators can define properties and dependencies which are required for a type of requirement.
Templates: When users insert such keys in an empty table, it will setup the table with all the properties, by default.

How to define key patterns?

Each time you create a new requirement, the key will be entered to the key suggestions list. If you want a key suggestion to become a requirement type, simply edit the suggestion and give it a name.

How to configure requirement types?

Only space administrators can configure requirement types. Users have access to this screen in read-only mode, the only action they can perform is reset the sequences.

How to edit requirement types?

Properties are described as a horizontal table, so it looks like the final page.
Tip: The only difference between a simple “key suggestion” and a requirement type is having a name. When you add a name, it gives you access to all of the options. (See docs for Key Suggestions)

How to validate requirements?

Validations are what will let you know if your requirements comply to their type or not, once you’ve configured it.

How to run the validations?

Validations can only be run in two ways:

When a page is reindexed (all validations will be run),
When a user clicks “Play” on a requirement type (only one validation will be run - requires EDIT permissions on the space),

Note that it is not possible to rerun all validations in a space.

How can I see the validations?

Required (red) fields are displayed in view mode,
Required (red) and optional fields (yellow) are displayed in edit mode,
The columns of required and optional properties are inserted in empty tables. They won’t be inserted once the tables have some amount of text.
“Quick fixes” can add more columns, and they are suggested next to red messages in the editor.

From the view mode	From the Confluence editor

From the view mode

From the Confluence editor

We only display invalid requirements from requirement properties, not optional properties.

We display a warning in the byline. When users click on it, invalid requirements appear as a red pill.

Bonus: When a table is incorrectly formatted, for example when the first row is made of gray cells but not headers, we will display it as a warning.
The “red pills” only appear if the user clicks on the validations, at the top of the editor.

Click on a requirement and click on “Quick Fix” will also update the table dynamically:

How to use templates with Requirement Types?

Inserting a requirement type as a template

When users insert a new requirement in a new page, which belongs to a Requirement Type, it creates the entire table:

Administration

Permissions

People who can view the space can list the key suggestions, requirement types and their properties.

People who can edit the space can run the validations of single requirement types, and of course edit pages and generate new keys based on suggestions. They can reset the sequences. If the keys are not locked down, then editing pages will automatically add new key suggestions.

Space-admins can create, update and delete requirement types, and lock down the keys.

Limitations

We have limits for the number of validation messages generated by page. Currently, the limit is 200 SQL requests per run, 1000 messages and 5 seconds, and the limit of requirement types that can apply to a single page is 20.