Dependencies, Dependency Matrix and Coverage
Introduced in Requirement Yogi 1.6
In this article we explain how to use Requirement Yogi to refine specifications from high-level business requirements to low-level technical specifications.
It all starts when you refine the high-level requirements...
You've already imported the customer's contract and transformed all keys into high-level requirements. Then you proceed to write the second document, which refines the first one. You write functional requirements matching the business requirements:
Obviously you'll want to refine those functional requirements:
Our structure is Business Requirements -> Functional Requirements -> Technical Specification. As you've guessed, in this example, Requirement Yogi now manages the last column as "dependencies". More generally, all columns can be used for dependencies and properties. Let's see what needs it fulfils.
How do I reference or link to a requirement?
First concept, the links or “references”. You can create a reference to a requirement from any page. References can be noticed because they have the little arrow before the requirement key, as opposed to requirement definitions. Clicking on a reference will lead you to the original page, scroll to the correct position in the page and highlight the requirement in blue. When you create a reference to a requirement, the popup lists all pages with references to this requirement.
To create a link, just reuse the same macro, Alt Shift R, but type the key of an existing requirement, and press Enter, or select the link in the list. You can confirm that you have created a link by checking that the macro contains the keyword “Link” in the editor, or that it has the little arrow in view mode.
How do I create child and parent requirements?
Second concept, when you put those links in a column, it becomes a dependency. In this example, we say that the child “FN-1” depends on the parent requirement “BR-1”, with the relationship “relates”. Dependencies are necessary to create the traceability matrix. There are often many types of dependencies, which is why we use the title of the column as the name of the relationship. In Requirement Yogi, every relationship, even with Jira or with properties, has a relationship name, which can be useful to filter dependencies later on. As well, we’ve learnt that every customer has different workflows, so we don't mandate any specific wording or organization of req
uirements, and users are free to choose relationship names.
"Did I completely cover the customer's contract?"
This is the most straightforward question. You can use the coverage report, which tells you:
The functional requirements is a parent of 6 of your 23 requirements.
11 of all the requirements are refined by an other requirement.
You can obviously click and see the items for each list.
Since you want to complete the coverage, you can list all requirements which are missing a link.
For navigation purpose, we display the dependencies in the inline popup:
The dependency matrix
The software is able to display the dependency matrix or export it to Excel:
The Coverage and Dependencies tabs are only displayed to users with the "Export Space" permission. It is due to the important memory consumption of such reports. The explanations are at the bottom of this page.
Much better Excel export
Taking the opportunity of exporting the Dependency Matrix to Excel, we've also greatly extended the Excel export. It now exports in the native .xlsx format, so we use 2 sheets, frozen panes and hyperlinks.
We add some new keywords for the search: "TO" and "FROM". Like the "JIRA" keyword, it allows you to search all requirements linked to and from another requirement, and you can specify the property name (i.e. "[email protected]" or "[email protected]").
In the following screenshots, we show how dependencies appear in the search, how the coverage looks when there are several relationships, and how to configure an RY Property macro for a column that contains dependencies.
Technical Notes - Out of Memory Errors
Building the coverage and dependency matrix use a lot of resources. It's not so much the calculations and the database I/O, it's building an HTML page with a few thousand cells and sending it to the user.
We've limited the web pages to 40k cells (200 x 200 requirements).
The Excel export is unlimited. According to our tests, it is not prone to running out of memory, even with 5000 x 5000 cells.
If your server meets problems like "OutOfMemoryException", "Java Heap Space" or "SiteMesh" exceptions, it could be related to the dependency calculations. One important thing to note is that the Requirement Yogi add-on may not be mentioned in those exceptions. If you are in this situation:
Don't run the coverage and dependency with empty queries. Use queries that return fewer requirements.
The dependency matrix and the coverage report can only be built by users who can export the space.
Therefore, inform a subset of your users about the server limits and the tips to prevent a memory overflow; and restrict the export permissions to this group only.
As a last resort, don't use the coverage and dependency matrixes. You can always explore Confluence's database schema and run the queries using an SQL tool. Tables related to Requirement Yogi start with "AO_32F7CE_AOREQUIREMENT".
We know that memory, processing power and database throughput are limited on your servers and we're very conscious of the cost of investigating out-of-memory errors. We've already made some efforts to measure, optimize and contain problems. We've also met boundaries because of the ActiveObjects API (the storage in AO_32F7CE tables), the SiteMesh decoration (which Confluence uses to add the top bar and footer in the HTML pages), and the Excel API. We believe we've done our best and we believe memory consumption will be the most reasonable in the most number of cases. If you meet problems and have further suggestions on how to optimize, we're available.