Our customers are all different, from mechanical and automotive industry to banks. Their uses of project management tools are also different. We decided to interview a company specialized in the creation of satellites. They were not using Atlassian Confluence before and had not used the aerospace requirement management tool for long. We thought it was an interesting example to understand how they adapted to it and how aerospace engineers manage their requirements with Requirement Yogi.
Who uses Requirement Yogi and for what purpose?
In their case, the product owner and project manager write requirements in Confluence, they are also edited later by the team as the project evolves. Their main goal was to write a lot of technical requirements, with a lot of properties, on documents that can be shared with a lot of team members. When contacting us they needed to:
- Understand how to migrate requirements from IBM Doors to Requirement Yogi,
- Support thousands of requirements,
- Easily sort through complicated tables with a lot of properties,
- Manage versions and the history of requirements.
Migrating requirements to Confluence and Requirement Yogi
Migration is always a difficult part, but on the upside is you only need to do it once. Sooner or later, the requirement must be written in a Confluence page. Therefore, the first way to import requirements is to export a Word document from the old system and import it as pages. Confluence has a native tool to read Word documents and create as many pages as there are chapters, cutting at each heading. Then, in view mode, you can click on a requirement (or press Alt-Shift-R), a panel will appear letting you transform this key and all similar keys of the page. This method is incrementally better than transforming requirements one-by-one on a page.
We have to be honest and say migration in Data Center is not our best feature. Indeed, this is an example where we have succeeded much better when we’ve created the Cloud version. On the Cloud it is possible to save the transformation rules and reapply them repeatedly on several pages.
REST API and Excel Import
Alternatively, if there is a large corpus of documentation to import, one can use the Confluence REST API to create the pages. Pages are simple XHTML, so exports from another tool can often look good in the new document. As long as the Requirement Yogi macro is present, we will index it.
If your requirements were in an Excel document, you can import them in the Excel tab. Your Excel document and will have to be linked to a Confluence page. If you modify requirements in the excel doc, they will be updated. The drawback is that those requirements are not natively visible on Confluence pages, they are only visible in our Excel previewer.
The feedback we have from customers is that, after import, people want to keep modifying them in Confluence. In this situation, we recommend importing Excel tables as tables in Confluence pages. If you are confident you will not need to modify the Excel files, then the Excel import will be suitable. They will be visible like normal requirements in the Search and Traceability matrixes. And in the Estimates, you will be able to add new external properties. You can also create dependencies from Confluence pages to Excel requirements, but not the other way around. This is a good way to import your requirements but we do not support imports that go over 2000 requirements.
On the other hand, if you wish to export your requirements from Confluence, you can build a traceability matrix with the important properties, and export it as an Excel file. If the original formatting of pages is important, then an export of a whole space to PDF is the way to go. It is a native feature of Confluence.
Support thousands of requirements
Requirement Yogi easily supports thousands of requirements in a single space. We often test with 1 million requirements in a space, 400 requirements per page. This satellite manufacturer only had 1500 requirements, this is a breeze.
We recommend keeping pages under 150 requirements, and up to 400 requirements. Requirement Yogi doesn’t mind if documents are split and spread out on many pages.
The reason why these satellite engineers had so many requirements is that they use them like a spreadsheet. For each requirement, there are a couple of datapoints (width, height, weight, resistance, status…) and they collect those datapoints on another spreadsheet. Therefore, not only do they have many requirements, they also were questionning how tables would look with a lot of properties.
Sort through a lot of properties
We are not a certified tool for satellite engineering so they still need to manually add each property of a requirement. In the Requirements panel, you can view and track your requirements in the Traceability matrix. You can shape your matrixes by defining a search query and as many columns you want: inline properties, test results, dependancies, issue to issue links and more. In the Estimates panel, you can also add external properties to requirements. External properties are not visible in the original Confluence page where the requirement sits, so it may be a way to add properties on requirements without cluttering the initial table. However, this company prefers large tables, because the scrolling in Confluence Data Center is satisfying.
Manage versions and history of requirements
Most of the times, as tests are made, or if a new version of a product has to come out, requirements change as well. It was important for our satellite engineers to manage versions of the requirements to check their history. In the Requirements panel, you can create baselines, also referred as versions. A baseline is a snapshot of the requirements at the time it was made. Thanks to them, you can compare requirements using the Diff (green-and-red highlights of the texts which were added or removed), or directly in a page with the byline (small Requirement Yogi logo on top of a page). However, there is no trace of who made the changes. It is generally not a problem for space engineers, whereas it would be a problem worth solving in the medical area.
If you need, you can use the plug-in Scroll Documents to go further on versions management. This plug-in will allow you to maintain two different versions of a page at the same time with a system of branches. Scroll Documents has an approval workflow for each version, and it can help you keep track of history and approval. On the Data Center version, Requirement Yogi does not have a specific integration, except that it ensures it only indexes the working copy of the pages, not the parallel versions.
Read more about requirement approval and versioning here.
Are you in space engineering? We’d like to know more!
Request a demo, which will be an opportunity for us to understand your specific situation.
