Versions Compared

Old Version 1

changes.mady.by.user Adrien Ragot

Saved on

compared with

New Version Current

changes.mady.by.user Mileva Briand

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

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.

Tip
titleIf 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:

...

Excerpt
hiddentrue
nameKeyword Dictionaries and blueprints

Documentation page on the keyword dictionaries and the blueprints of Requirement Yogi.

Panel
panelIconId1f4cc
panelIcon:pushpin:
panelIconText📌
bgColor#DEEBFF

Release 1.4

Those features were published in version 1.4 in March 2016.

Annotate keywords, error messages and part numbers

We're introducing the dictionary blueprint in Requirement Yogi. It starts with a template where people can enter any kind of key/description entry:

Image Added

The user can assign a color to distinguish, for example, error messages from normal messages:

Image Added

Specifications of the feature

This part will explain how this feature works. It leverages the Properties feature, so users could reach the same results without using the template. It defines the special properties named "Type" and "_formatting". Here are more details:

Property

Value

Notes

Type

Any string

  • The type will be

suggested in the inline creation pop-up

  • displayed in the requirement properties,

  • When using the inline creation popup, types are suggested,

  • There is the inconvenience that people who already use "Type" for another purpose will populate the inline dialog unnecessarily. We think this is a minor inconvenience because the inline dialog isn't used often.

_formatting

#color; bold; italic; underlined;

Image Added

  • All requirements with this

formatting

  • property will be formatted accordingly.

  • Elements must be in the

same

  • specific order, followed by a semi-colon and an optional space.

  • The first item is a CSS color

,

  • in hex/css format, such as " #ff0000" for red.

  • Note that this property is not searchable or visible in the details, since it contains "_"

.

 

Demonstration

...

  • .

...

Image Removed

 

The list of types appear:

Image Removed

  • 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

Image Removed

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

 

 

 

 

 

...