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 »

Introduced in Requirement Yogi 1.6.

 

It all starts when you write the 2nd document...

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. So 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, Requirement Yogi now manages the last column as "dependencies". Let's see what needs it fulfills.

"Did I completely cover the customer's contract?"

This is the most straightforward question. You can use the coverage report, which tells you:

  • The technical requirements cover only 2 of your 3 functional requirements.
  • All of the 3 functional requirements cover a business 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:

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

 

 

Technical Notes

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 meet 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, restrict users from exporting the space to people you can inform about the server limits and the tips to prevent an memory overflow.
  • 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.

 

  • No labels