Tracking Requirements With Voyager
Whether you’re designing a crewed autonomous VTOL vehicle, a CubeSat, or any other complex hardware, you and your team will have to manage competing analyses, tests, mission requirements, and more. It’s even harder if you’re still using spreadsheets to track hundreds of requirements and test results.
As great spreadsheets can be, they come with several inherent limitations. First, they’re set up for one person to use. If you’re trying to use it in a team setting, you may end up sending the document back and forth between team members with updates, or putting it on a server and hoping the rest of your team notices any changes you’ve made. And while they’re great for managing numbers and formulas, qualitative requirements (such as a test method or cleaning specifications) don’t always work well. For example, If there are any changes made to text requirements in one location, these changes don’t propagate to other locations in the spreadsheet or in other analysis software.
It’s usually the responsibility of system engineers to keep their team updated about any changes to requirements. But when big contracts have hundreds of them and it’s easy to let anyone slip, this can mean the engineering team and the system engineers are working to two different sets of requirements. This isn’t just annoying for everyone involved — it often leads to costly errors and lost follow-on business.
Personally, when we previously worked on a satellite design for a NASA competition, we noticed that we had to deal with checklists and requirement documents a mile long, and we found this process of managing these lists incredibly frustrating too. We wanted our small satellite team to be an agile group where members were empowered to make decisions quickly. (The other option was to wait around for vendors and other teams to get back to us with information we needed.) With this rapid decision-making, however, came another problem — communication.
During the month we were trying to finalize the satellite’s design, the propulsion team ran some analysis and found that the satellite needed more propellant than previously thought. Because so much was happening, this change didn’t get communicated to the other teams. As a result, the propulsion team spent a month designing for more propellant space, the other teams kept designing to older assumptions.
Later, when both teams realized the inconsistency, you can imagine what the meeting was like: “What do you mean I have half the volume you said I had last month?! I barely have any space at all and I spent all month trying to find a part that would fit in such a small space!”
Frustrating, to say the least. Ultimately, the project ground to a halt as the propulsion team realized their ideal tanks were too big to fit the current satellite design, and the other teams realized their month of work would need to be completely redone.
In our ideal world, teams wouldn’t have to wait for others to communicate the results of their analyses, and our satellite team wouldn’t have burned a month of work on two virtually different systems. When we talked to other teams in the industry, we found these same problems happening again and again.
With this experience, our team at Voyager designed a robust requirements tracker specifically to enable engineers to more efficiently track every requirement and analysis in one location. Voyager’s requirements tracking interfaces with your engineering data to provide a streamlined, real-time view of the project, as well as updates on other teams’ work that affects yours.
What does this mean for your project? In this article, we’ll walk you through a sample mission that utilizes Voyager’s requirement tracker.
Step One — Identify and input your requirements.
Congratulations, you’ve won a big contract with the Forest Service! For this mission, you’ll design a satellite that will let rangers and other personnel detect and monitor forest fires across the United States in real time. Let’s call your design FireSat (familiar, we’re sure, to anyone who has read SMAD).
In order to view and distinguish fires successfully, FireSat’s camera must have range, visibility, and accuracy. We’ll call this a parent requirement:
- Camera must have range, visibility, and accuracy to monitor fires.
You can add this by clicking the Edit button at the top right-hand corner of the page, then selecting “Add Requirement” to the left of it.
In order to meet this parent requirement, we will need to come up with more detailed requirements for our design. In Voyager, these are called child requirements. We’ll add the following into the tracker:
- Visibility: FireSat’s camera must work through light clouds.
- Accuracy: FireSat’s camera must have an accuracy of 1 km with a margin of +/- 5%.
- Resolution: FireSat’s camera must have a resolution of 50 m with a margin of +/- 5%.
You can enter these requirements into Voyager’s tracker by clicking “Add Child Requirement”.
Keep in mind: if you’re using parent and child requirements, each child requirement must be passing successfully in order for the parent requirements to pass. In order for this parent requirement about FireSat’s camera to pass, each child requirement for resolution, visibility, and accuracy must individually pass.
This is where you can choose a verification method. If your requirement is qualitative (e.g. MLI insulation must be applied to the spacecraft), you may want a written document or a photo as verification. If your requirement is quantitative (e.g. the satellite must weigh no more than 2,000 kg), you may connect a script or a spreadsheet calculation run in the platform as proof of completion.
In the case of FireSat’s resolution requirement above, you’ll need to run some analysis to ensure that the camera has a required resolution of 50 m with a margin of +/-5%.
Step Two — Upload files to verify requirement completion.
You’ve just finished running some initial analysis for FireSat’s camera design and it now meets the visibility requirement. To make sure everyone else on your team is on the same page, go ahead and set the tracker’s status to “Passed”. Once you verify this requirement, Voyager will tag it with your name and a timestamp so your team can see who verified the requirement and when.
It’s also a good idea to upload the data from this analysis to the requirement you met for verification. Click “Upload” to choose this file (“Visibility Verification Data”)…
…and then submit your changes to the version control system. This way, everyone can see that this requirement is complete and can look through all the great work you did to get there. And when somebody has questions about it two weeks from now, you won’t have to scramble for those files and email them out — everyone already has immediate access.
Step Three — Derive requirements from a completed analysis.
Now that the FireSat camera requirements are complete, let’s move on to some other requirements. You wanted to be able to monitor changes in forest temperature, so you ran a script that allowed you to see temperature changes through thermal imaging.
When you return to your requirements tracker, you can select any output from an analysis block and make it a requirement. In the example below, the value derived from this script was a variable for average temperature change. You can now add it as a requirement. In this example, we’ll select “Add Child Requirement”, choose this derived variable directly from the menu, and input it as a requirement. You can also set a margin, which we’ll set at +/- 2%.
In this specific example, the requirements derived from the script were input as child requirements. However, Voyager allows derived requirements to be input as either parent or child requirements.
Step Four — Link your analyses and requirements.
“Does FireSat really have a camera accuracy of 1 km with a margin of +/- 5%?” You’ve completed all the tests and analysis for the design, and now your project manager wants to double check. Last week, you would be digging through all your spreadsheets, hoping you’ll be able to find the right one, or trying to find the documentation you handed off a couple weeks ago. Now, all your information is already on the platform.
Once you’ve linked your analyses, tests, or data to a requirement, Voyager does the verification work for you, automatically passing or failing each requirement based on the parameters you’ve set, while taking into account any changes made.
“What if we used a different lens for FireSat’s camera?” your project manager asks now, so you re-run an integrated Python script with the new lens data. Re-running this script with changed variables will update the output values, which will refresh lens data and will check against the requirements to make sure they still pass.
This also holds true if you need to change a requirement. Any linked analyses or tests will check against the new requirement and tell you whether or not it passes.
Sounds great! What now?
Tracking your requirements is only the beginning. From here, you can use Voyager to collaborate with your teammates on your preferred software, see the full scope of your design and analyses on the dashboard, and see how changes affect your entire system:
If this sounds like something your team could use, we’d love to get in touch. You can sign up for Voyager’s beta program, or drop us a line through our website.
