| Excerpt | ||||
|---|---|---|---|---|
| ||||
We want to build open transparency, so here are the limitations of our product, and we are working on them. But please also discover the upsides of Requirement Yogi. |
| Panel | ||||||||
|---|---|---|---|---|---|---|---|---|
| ||||||||
Open transparency!Please also discover the upsides of Requirement Yogi. We are one of the rare vendors who communicate openly about the limitations, because we believe it helps managing expectations. Nevertheless, we are also better than the competitors on all the upsides |
so please make an accurate assessment of the product before looking at those limitations| Info |
|---|
Using the cloud?Those limitations don’t apply! Jump to the Limitations of the Cloud version. |
With time we've noticed that we had recurrent feedback, so we would like to set expectations by summarizing the limitations of Requirement Yogi.
...
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.
...