...
| Excerpt | ||||
|---|---|---|---|---|
| ||||
Read this documentation page to learn how to use the requirement configuration macro and change the way your requirements are indexed. |
It is absolutely not mandatory to use a Configuration macro, but it will help you customize your requirement detail with property and dependency names.
Follow this tutorial to know how to add properties to requirements, and dependencies. And how to customize their names to simplify your requirement detail: https://youtu.be/891Q3OpCiLA?si=iaWgX2gN_TQj5L0Q |
To add a configuration macro, in the page edit mode, type |
...
 |
After adding a macro to the page, you can edit it simply by clicking on the macro: |
 |
It is also possible to add a Configuration macro from the view mode, with the Transformation wizard.
Table Configuration
If your requirements are in tables, it is absolutely not mandatory. The Requirement Yogi configuration macro is useful to change the way your requirements are indexed and override column titles, or choose to put the 3rd column as the description instead of the 2nd.
When you define requirements in table, by default, the requirement key
...
will be in the first column, with a description in the second column, and properties and dependencies in the following columns.
It also works for vertical tables: rows will be identified as columns. (Ex: 1st row in your vertical table will be mapped as the 1st column in the Configuration macro, 2nd row to the 2nd column, and so on.).
This table: |
|---|
...
Gets indexed as: |
|---|
...
 |  |
Here is the default configuration for requirements in tables: |
...
With the configuration macro, you can:
|  |
|
...
|
...
|
...
|
...
|
...
|
...
|
...
|
...
|
...
 |
After inserting the macro and publishing the edited Confluence page, my requirement is now indexed with the changed properties as: |
 |
You can quickly "unindex" the requirements in a page by adding a configuration macro at the top of the document and uncheck the requirements column. It can be useful when you have duplicated requirement definitions.
In paragraphs and headings
| Info |
|---|
New feature |
Paragraph Configuration
When you define requirements in paragraph or headings, by default, the description of the requirement is the following text. |
...
Requirement keys in paragraphs: |
...
 |
Here are my requirements: |
...
 |
...
 |
...
 |
With the configuration macro, you can:
|
...
 |
After inserting the macro and publishing the document, here is my requirement again: |
 |
When requirements are in headings
You can ignore the numbered headings by passing a regular expression specifying the numbering format. My headings: |
...
 |
will get saved as: |
...
 |
...
Here are a few common ways to number headings and their regexes:
Numbering | Example | Regex |
|---|---|---|
Decimal | 1.2. | ^(\d+\.)+\s* |
ISO-2145 | 1.2 | ^(\d+\.?)+\s* |
Lower-latin | a.b. | ^([a-z]+\.?)+\s* |
Upper-latin | A.B. | ^([A-Z]+\.?)+\s* |
Upper-roman | I.II.III. | ^([IVXLC]+\.?)+\s* |
Document Configuration
| Info |
|---|
New Feature 🚀 |
This is the evolution of the paragraph configuration. We call this feature Linear Documents. It is best suited when requirements are written outside of tables, when you reuse public standards or your customer’s requirements.
Instead of only having the following line in the description, each heading of your paragraph will be indexed as a requirement, with its whole body as a description, dependencies to higher and lower level titles.
Read the documentation, or watch the tutorial.
What your document looks like: | What we index: |
  |  |