During a tender effort for a high-power RF amplifier module, our team was managing more than 1,000 requirements and their test cases in Excel. Preparing for a Critical Design Review (CDR) or Test Readiness Review (TRR) meant filtering requirements, copying them into Word and assembling the traceability records manually.
Then a requirement would change, and the documents and matrices had to be reconciled again. It often took three or four rounds before a review. Mismatches between requirements and test cases could remain unnoticed until document review.
At LaserAegis Australia, our core work is RF and laser system engineering, and managing the requirements and evidence behind the hardware is part of that work. We built Requirements Traceability Manager, or RTM, to solve these coordination and change-control problems on our own defence RF and laser projects. It has been used across seven internal projects, it is maintained and supported by the engineers who use it, and it is now available to other engineering teams.
LaserAegis RTM brings requirements, supplier responses, controlled changes and verification evidence into one project record, so engineers can follow an obligation through the decisions and work needed to show it has been met.
When maintaining the connections becomes the work
Spreadsheets can serve a small, stable project well. The burden grows when several people must maintain the relationships between requirements, supplier commitments, design changes and supporting documents.
Take an RF output-power requirement. Its meaning depends on the frequency band, waveform, duty cycle and operating conditions. A row marked "compliant" tells you little if those conditions sit in an email, and a test marked "PASS" is hard to trust if its report supports an earlier version of the requirement.
In one incident, an engineer updated a requirement after a supplier discussion. A colleague, unaware of the change, took the new value for an error and restored the earlier wording. The conflict surfaced later as rework. Not knowing which values could be trusted was a key reason we built RTM. RTM addresses this coordination work by linking the records that engineers need to inspect together.
Why not a larger platform?
Established requirements platforms exist, and for large organisations running many programmes across several sites they can be the right answer. For a small or mid-sized engineering team, the trade-offs can look different.
Hosted options place project data on external infrastructure, which some tender or customer requirements restrict. Self-hosted platforms often need server and database setup, ongoing administration and IT support. Configurable platforms may also need attributes, link types and process rules defined before they fit the team’s workflow. For a smaller team, that investment in setup, training and maintenance can be hard to justify alongside the engineering work itself.
RTM starts from a narrower scope. Each computer runs it through a local browser interface, without a central or licence server, and it works in your controlled environment. Supplier response tracking, change control and verification reporting are already built in, and project fields can be adapted as the work develops. Project data stays in local storage or a documented shared folder chosen by the team, which suits projects that restrict external hosting. CSV and ReqIF exchange is available within documented mappings. Your IT team still approves the software in the usual way.
Give each requirement a source and a verification approach
The starting point is a clear statement of the obligation. RTM lets teams organise customer tender clauses and engineering requirements, assign identifiers and attributes, and link them with parent–child relationships and typed trace links. For a defence tender, that keeps the connection between an invitation to tender (ITT) clause and the engineering requirements written in response.
Verification should be considered while the requirement is written. Depending on the obligation, the method may be test, analysis, inspection or demonstration.
Built-in attribute templates provide a starting structure in RTM. Teams can adapt the fields to their project and record reviews and approvals as the requirements mature. Tender clauses can be imported by CSV, and the compliance matrix identifies clauses without mapped engineering requirements. Interpreting ambiguous tender language and writing a verifiable technical requirement remain the team's tasks.
Keep the conditions behind a supplier's answer
To show how this works, our airborne surveillance radar case follows a team translating customer requirements into subsystem commitments and verification records. One requirement sets a timing limit: the signal processor must deliver plots to the tracker within 100 ms of completing a radar dwell, the interval used to collect radar returns.
The supplier first offers 120 ms, then 110 ms after optimisation. A later response offers 100 ms with an additional GPU card, an eight-week lead time and added cost. On paper, the final answer meets the limit. In practice, accepting it also means accepting a hardware dependency, a cost and a delivery risk, and the people integrating and verifying the subsystem need to see those conditions.
RTM's supplier response workflow keeps each exchange round, clarification and deviation or waiver decision against the requirement it concerns. Suppliers reply with CSV files and do not need to run RTM themselves. The next engineer can find the accepted position and its conditions without reconstructing the discussion from separate files.
Get the free Radar Case Pack → to follow all three timing responses.
Follow a change beyond the edited requirement
In the same case, a transmitter supplier offers 8 kW against a 10 kW requirement. That shortfall affects a system-level range requirement, so the team has to look beyond the supplier's row.
Engineers record the impact assessment and approval in linked change requests, apply the approved changes and compare the resulting baselines. Affected trace links can be marked suspect, which points engineers to the dependencies that need review. Requirement versions and the audit history record who changed what and when, so the team keeps both the new statement and the reasoning behind it.
Check the evidence behind the status
By review time, a requirement should lead to its verification method, criterion, actual result and supporting evidence. RTM links requirements to test records and registered documents. It keeps passed, failed, blocked and unrun tests distinct, and shows missing or unapproved documents separately. This matters because test completion and document coverage describe different aspects of the project.
For registered evidence files, RTM records a file hash and flags a missing or changed file. If a report changes after the test it supports, the team has a specific reason to revisit that evidence. Built-in reports help teams prepare for reviews and explain open work. The Programme Pack exports eight connected project files covering requirements, compliance, verification, risks, suppliers, statement-of-work items, supplier requirements and milestones.
Explore the radar case, then try your own question
RTM is for engineering teams managing customer obligations, supplier interfaces and verification records, including subsystem suppliers, integration teams and engineering consultancies. A good starting point is one workflow that currently takes repeated effort: establishing a supplier's accepted position, reviewing a changed requirement or assembling the evidence for a review. Agree who maintains the records and who makes the decisions, then see how the tool fits.
Explore the full Radar Case Pack to follow the supplier's three timing responses, the transmitter change and the evidence gaps still open for review. The free pack includes a ten-page engineering case, a practical checklist and Excel/CSV requirements references.
Or book a guided RTM demonstration focused on a supplier response, a requirement change or a verification record, and we can discuss deployment and a pilot suited to your team's scope.