Limitations

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.

• All requirements can be seen in Jira, but users will only be able to see their contents (text, etc.) if they have a Confluence account and permissions on the space.

• The history is only visible to space administrators and owners of entities.

Formatting

• We don't render dynamic content, and we simplify the HTML to make it storable.

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

Requirement keys

• Requirement keys cannot contain slashes ( / \ ), and numbers in keys can only reach +9223372036854775807. If you need higher numbers, please add another character in the middle.

• The reason is that we carry requirement keys in the URLs, and dealing with UTF-8 in URLs is difficult. If you notice any issue with special characters in keys, please tell us!

• 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. If you use copy-paste or use the REST API to create duplicate requirements, they will appear in bright red with an error message to tell you to resolve it.

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

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.

Traceability matrix

• The traceability matrix is paginated and can easily display 600 rows per page, on dozens of thousands of results,

• However, we don't support retrieving "too much" data from Jira, and pages need to be shorter as the number of Jira columns grow,

• Customers face problems when they want to export their entire matrix to Excel, which means it takes more than 2 minutes to extract the data from Jira. Requirement Yogi is not designed to pull the entire status of a project from Jira through the little pipe of communication between the apps. Workaround: Please investigate using EazyBI in Jira and retrieve the details of the requirements using our REST API.

• Also, we don't support calculated fields on Data Center. It means we can't show the percentage of child requirements which match a given rule (for example, the % of requirements where the status is "OK", for the most usual usecase of tracking a project).

• As a conclusion, Requirement Yogi is designed to help structure the free text and track the requirements, but we are not a good project planning tool, and you would need an external BI engine for the project planning part.

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.

Images

• Since we only save the HTML of the requirement, and the HTML contains a URL to the image and not the image itself, someone could change the image at the end of the URL, for example by uploading a new version of this image in Confluence.

• Because of this, images in baselines are not guaranteed, since images can be swapped with other ones,

• Because of this, Jira will attempt to display the image, but may fail if the user is not conneted to Confluence, or if the applink between Confluence and Jira doesn't allow cross-domain images.

The 1-to-1000 issue

• We don't support links from 1 requirement to 1000 dependencies, or 1 Jira issue to 1000 requirements.

• We expect requirements to be linked to 3 to 20 dependencies.

• We expect requirements to have 10 to 50 properties.

• The problems you would meet would be:

  • The hard limit in Jira,

  • In the traceability matrix, the backend has to load all the dependencies despite only showing the first page (the size depends on your choice, let's say 600 rows).

  • The popup in Confluence will be long to load, and the contents of all requirements are preloaded when the page is loaded.

Diff

• The current diff is limited to 600 requirements (=5% of the global limit, which you can configure).

• This is not enough for large customers with 12k requirements in baselines,

• It is a difficult problem to solve, but not impossible; We are hoping to solve it one day.

Workflows and validation

• Requirements don't have a status.

• Customers manage the status by using a Status macro, and changing the text and colour manually.

• Customers also use EDM "Easy Dropdown Macro" to have a dropdown as a status.

• The drawback is, there is no validation of the permissions associated with the status change.

• The other drawback is, people do spelling mistakes, and they can type "Valiid". We are planning on introducing a rules engine in the medium term. As usualy, please don't count on it until it is done and published.

Branching

• We can't support editing several versions (the "1.x and 2.0 problem") of the requirements in parallel.

• For example, you may have version 1.x of the requirements, for which you are performing little changes/bugfixes for the current customer, and you may be working in parallel on version 2.0 of your product, in which you are making major changes. You may even expect to perform a change in 1.x and merge it into version 2.0. This is extremely difficult to support, and we are not doing it yet.

• Although the third-party plugin Scroll Versions is able to maintain several versions of the pages, we can't index those pages. We'll only ever index the currently-published version of those pages.

• The only workaround is to have two spaces, which act like two separate versions of the requirements, and copypasting the text manually across spaces.

Inheritance

• Some customers have 1 product, with 10 customizations for 10 customers.

• We don't support that, and customers who have tried to solve it another way haven’t been successful.

• The support is better on the Cloud, where customers can use the Variants.

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