Use case
Customers want to manage more than requirements. They also want to manage dictionaries, for example:
- An index of all error messages in the application,
- A list of part numbers.
We've arbitrarily defined that the property named "Type" would be a special case, it will contain the type of requirement. This is a standard property, as defined in Properties and RY Reports.
If you are already using "Type" for another purpose
If your documentation already uses the "Type" for another purpose, it is not a problem. The only drawback is that the inline creation pop-up will contain a lot of entries in the drop-down. Given the pop-up is only used to create types, the UX impact will be limited.
Specification
Types rely on features which are already available in Requirement Yogi:
| Property | Value | Effect |
|---|---|---|
Type | Any string |
|
_formatting | #color; bold; italic; underlined; | All requirements with this formatting will be formatted accordingly. Elements must be in the same order, followed by a semi-colon and an optional space. The first item is a color, in hex/css format, such as " #ff0000" for red. Note that this property is not searchable, since it contains "_". |
Demonstration
On a page, select a candidate for a requirement key. In the inline pop-up, click "Define as a requirement":
The list of types appear:
- The requirement will be appended to the table inside of the page "ODIS Index 2".
- You can apply the same transformation to all requirements on the current page.
- You will convert any reference to this requirement in the same page; You can opt to do the same on the whole space.
Situation: Creating a new type
- If you haven't defined any type yet, the form suggests to.
- It will use a blueprint to create the type.
- It's awesome to create types which match the requirement name. For example "MESSAGE_888" can have a type "MESSAGE", so Requirement Yogi will suggest to transform similar requirements.