Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

With time we've noticed that we had recurrent feedback, so we would like to set expectations by summarizing the limitations of Requirement Yogi.

Permissions

  • Requirements belong to a space. You can view them if you can view the space; You can edit them if you can edit pages on the space.
  • Tagging the row of a table as a requirement "exports" its text to the space. That means ANYONE with view permissions on a space will be able to see the requirement. In other words, we don't take into account page-level restrictions.
  • Requirements can be seen in Jira. If a user is able to create a link from Jira (they require OAuth permissions to view the requirement for that), then the text of the requirement will be brought to Jira.

Formatting

  • We simplify the HTML of the requirement. The goal is to avoid having "block" elements (paragraphs, lists, tables) so that it doesn't disturb the layout when displaying the title of a requirement in search results or other places. We also remove a lot of CSS formatting since it can't be displayed the same way in Jira.
  • We don't render dynamic content.
  • Images aren't copied in a binary way to the requirement. We only keep a URL of the images:
    • If you swap the image at the end of the URL, the image will be swapped in the requirement. This is particularly relevant when a requirement is baselined, since you don't always expect the image to change.
    • If you display the requirement in Jira, the image will be a URL to Confluence. It will appear broken, unless you are logged in to Confluence and have the permissions to view the image.
    • Therefore we don't recommend images in requirements.
    • If you use Requirement Yogi for, say, an architecture document or a technical drawing with lots of images, the best way is to use our API to create an extension, so that you can manage requirements inside of your specialized software.
  • Since space administrators can delete page versions, baselined requirements may not always have a page version to link to. In such cases, we link to the closest page version. Note that administrators can also delete baselines and all their requirements anyway.
  • We don't have a validation engine for requirements. The upside of the software is that users are very free to enter the text they want; The downside is that it is still difficult to ensure they are all formatting their requirements the same way.

Requirement keys

  • We only accept a-z A-Z 0-9 and the three characters: . - _
  • The reason is that we carry requirement keys in the URLs, and dealing with UTF-8 in URLs is difficult,
  • Please avoid lone words for keys. Some customers use RY as a glossary, translating acronyms... That is not the intended purpose of Requirement Yogi.
  • Unicity is guaranteed when inserting manually. There are corner cases where you may create duplicate requirements in a space (if you use an external plugin to create pages, for example); Requirements will appear in bright red with an error message to tell you to choose which one is the definition.
  • Keys are unique per space.
  • You can always create links across spaces by pasting the canonical URL of a requirement. You can only create links across spaces manually by searching in the Requirement macro, if you haven't ticked the option "Isolate spaces".

Traceability matrix

  • To display Jira fields in the traceability matrix, tick the checkbox "Get data from Jira" at the top of the screen.
  • Cells are limited and paginated, see the global limit in the Requirement Yogi administration.
  • We have great renderers in the traceability matrix; However we don't have calculated fields. It means it is still difficult to track the % progress of a project for now.

Administration

  • There is a queue of messages in Confluence and in Jira, that are transmitted to each other. This is designed to ensure that a user who doesn't have permissions in Jira can modify requirements in Confluence and have Jira updated.
  • When installing the product, you must enter a username in both products for this queue.

What to write in requirements

  • This is more of a functional question, but often asked.
  • Please design your workflow so that the developers click on the requirements and view them "in context". They will always be better formatted, with more contextual information. There is some loss in the textual content, the great value of RY is to link back to the correct section in the Confluence page.
  • Please keep dynamic information in Jira (Stories, bugs, change requests, etc.) and static information in Confluence (specifications, how the designed system should behave etc.). It is not an excellent practice to write requirements which are actually "Stories" in Confluence, and trying to copy them over to Jira.


Hoping this clarifies any question about the limitations of the product, we will update this list if other recurrent questions come up.

  • No labels