| Infoexcerpt | ||||
|---|---|---|---|---|
| ||||
When you want to refine your requirements, you create dependencies. Learn all about it on the documentation page. |
| Panel | ||||||||
|---|---|---|---|---|---|---|---|---|
| ||||||||
Introduced in Requirement Yogi 1.6In 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.
"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:
| Panel | ||
|---|---|---|
| ||
PermissionsThe 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.
Other Screenshots
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. "TO@implements" or "FROM@refines").
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.