Which requirements tool suits a small aerospace team?

For a small aerospace team, choose the requirements tool your people can keep accurate through a supplier change and the next customer handover. A controlled workbook can suit a stable, clearly owned list. A dedicated tool becomes useful when traceability, change review, verification and supplier exchanges become regular work. An effective inherited requirements management or application lifecycle management (ALM) estate can remain the best choice when contractual outputs, integrations and preserved history outweigh the effort of moving.

This guide is for a team maintaining supplier obligations and evidence across builds or programmes, including occasional reviewers and new contributors. Its question is how to sustain that work with the people available. The space-startup guide addresses a first programme with no inherited tool estate.

Which controls do we need before choosing?

Begin with the customer obligation and the package you must deliver. Name the owner of the requirement set, the person authorised to approve a change, the baseline released to a supplier and the authority for verification acceptance. A supplier comment, a proposed requirement and an accepted requirement need distinguishable states. These responsibilities still apply when one engineer covers several roles.

NASA's requirements-management guidance describes maintaining traceability and assessing changes to established baselines. Its configuration-management guidance connects product identification, documentation and controlled change. Use those principles to frame the exercise below, while taking the required formality, deliverables and approval authority from your own contract.

Which tools belong on our shortlist?

A controlled workbook — Excel is a reasonable candidate when the list changes infrequently and an owner can reconcile every released requirement, comment and evidence reference. Microsoft documents co-authoring with compatible Excel versions and OneDrive or SharePoint Online, together with file version history. It also explains that the last saved change generally wins when people edit the same content. Define stable IDs, released copies and a change log around the workbook. File collaboration alone does not establish an engineering approval process.

The decision to move should come from observed work. If preparing each supplier return requires joining copied sheets, repairing links or asking one person which revision applies, include a dedicated tool in the same exercise. Requirement count and headcount alone do not tell you whether the workbook remains maintainable.

A focused requirements workflow — ReqView documents structured requirements, links to risks and tests, traceability reports and version control through Git or SVN. It deserves a trial when document-oriented requirements work and an existing repository process suit the team. Check who will maintain repository access, release packages and review decisions, particularly when a supplier works outside that repository.

Arc is a candidate when the recurring job is to follow a supplier change through the engineering context. Its connected programme model links requirements with systems, interfaces, risks and verification. Engineers can propose changes on a branch and inspect record-level differences, while named reviews record attributable decisions. Verification records and configuration applicability provide the context for checking which build a result supports. The team must maintain those relationships and rules. Responsible engineers decide whether a change and its evidence are acceptable.

Jama Connect documents requirement and test items, structured reviews, relationship-based traceability and baselines that capture selected item versions and relationships. It deserves consideration when repeat stakeholder review is central to the job. Its documentation also describes administrator-controlled access and process tailoring. Test the supplied configuration with your occasional reviewer and supplier package, rather than assuming either its review breadth or the team's size settles the choice.

An established RM or ALM estate — If a customer or parent organisation already provides a working environment, assess keeping it before planning a migration. IBM distinguishes DOORS and DOORS Next: DOORS has structured specification modules and mature baseline and exchange capabilities. DOORS Next uses a web client and the Jazz platform within IBM Engineering Lifecycle Management. Identify the actual product, version, project conventions and required exchange route, since the two products are not interchangeable procurement labels.

Siemens Polarion ALM covers requirements, coding, testing and release, with configurable workflows and historical records. PTC Codebeamer brings requirements, risk and test management together with product-line configuration. That breadth can be useful to a small team inheriting trained users, configured integrations and shared lifecycle work. Compare the cost of maintaining that environment with the actual migration, archive and integration work needed elsewhere.

These are representative choices for different constraints. They are editorial recommendations based on documented scope, with no numerical vendor ranking. Each candidate still needs to meet the same written requirements in its proposed edition and deployment.

Try a supplier change that leaves evidence behind

This fictional selection exercise concerns a UAV power-distribution unit. All identifiers, configurations, measurements and decisions below are invented inputs and expected outcomes. No product trial or hardware test was executed. Assign systems, hardware and verification responsibilities, then include a supplier return and a reviewer who joins late. One person may cover several roles where the programme permits it.

Seed each candidate with the same approved records. The systems owner controls the obligation and its flow-down, the hardware owner controls the unit design and interface, and the verification owner records the test and its applicability.

Now return supplier notice SUP-PCN-009 rev 1 against SP-042 rev 1. The proposed replacement regulator supports only 2.5 A at 28 V nominal. The supplier suggests changing PDU-REQ-014 to 2.5 A. Have the systems owner open CR-017 and reject that proposal in decision DR-017-A, because CUS-PWR-006 still requires 3.0 A. The expected result is a preserved proposal and rejection, with the approved requirement unchanged. Receiving a file or comment must not authorise a weaker obligation.

For the revised proposal, select an alternative regulator that retains the 3.0 A requirement. The hardware owner prepares drawing PDU-210 rev C and interface PDU-IF-003 rev C. The verification owner prepares TP-PWR-007 rev 3 under TC-PWR-007 and enters fictional run VR-PWR-007-02: 3.05 A at 28 V nominal on unit SN013, drawing rev C and firmware 1.5. This sample result must point to that configuration and PDU-REQ-014 rev 2. These headline readings alone do not demonstrate continuous capability or full verification. The fictional package assumes a separately specified operating envelope, duty duration, tolerances, approved acceptance criteria, complete test data and responsible review. The tool must preserve those records and their applicability, without accepting the obligation from one measurement. NASA's product-verification guidance supports recording the requirement set, product version, procedure, results and discrepancies as part of the evidence record.

Require authorised review decision DR-017-B and acceptance APP-017-B before releasing UAV-A / BL-07 and supplier package SP-042 rev 2. Record who decided, when, which requirement and evidence were reviewed, and the released configuration. Preserve VR-PWR-007-01 and APP-006 for BL-06. Keep a second programme, UAV-B / BL-03 using drawing rev B and firmware 1.4, outside the approved change unless its owner separately assesses applicability.

Finally, give a late reviewer the resulting records and exported package. Without a verbal reconstruction, they should find the rejected 2.5 A proposal, the unchanged customer obligation, the revised design, both test configurations and the authority for BL-07. Ask the supplier to return one clarification referencing the released IDs and package revision. Repeat this handover without vendor assistance and with the usual administrator unavailable.

What must a candidate prove before purchase?

Write mandatory gates before demonstrations and apply them equally to the workbook, focused tools and inherited estate. For this exercise, a passing candidate must let the team:

• Keep CUS-PWR-006 and PDU-REQ-014 authoritative while preserving the supplier proposal, rejection and revised approval as separate records.
• Exchange SP-042 with stable IDs, revisions, relationship meanings and evidence references, then attach a returned clarification to the right release.
• Recover BL-06, BL-07 and their acceptance records, with each result attached to its as-tested configuration and UAV-B's applicability unchanged.
• Let the late reviewer reconstruct the decision from accessible records and an export, using the access the contract permits.
• Meet the required processing boundary, approval standard and retention obligations in the offered configuration, with a named owner and workable cover for routine administration.

A missing document is an unresolved gate, rather than proof that the product lacks a capability. Obtain the evidence and test it before committing. For candidates that meet the gates, use the existing buyer-guide evaluation rubric to record observations. This article supplies the work package and expected outcomes, without assigning product scores.

Who will maintain the workflow as people change?

Name a process owner and a deputy. Ask them to maintain fields, permissions, supplier mappings, release packages and evidence links during the repeat exercise. Record actual contributor time, administrator assistance, manual copies and training needed by the late reviewer. Agree acceptable effort against the team's available capacity before testing. A successful prepared demonstration leaves that ongoing cost unknown.

Compare the same three-year scope using dated written quotes for the roles you actually need: daily contributors, occasional reviewers and external collaborators. Include implementation, migration and historical archives, integrations, deployment, support, training, recurring administration and exit exports. Record the quote date, edition, exclusions and renewal assumptions. No customer-specific quotations were obtained for this article, so it makes no price or saving claim.

Deployment can decide the shortlist before usability does. Check what the contract permits for supplier and customer data, including any external AI route. Standard Arc is hosted on AWS in London, and external AI providers may process elsewhere. Arc’s owner confirmed customer-owned AWS or Azure infrastructure, GovCloud and private inference under agreed setups on 22 October 2026; supported AI features can use customer AI-provider keys. That confirmation is separate from the 18 October hosted-service review. Agree the architecture, processing boundary, support and responsibilities for the offered deployment before relying on it. Customer-owned databases, on-premises or air-gapped operation and disconnected inference still require confirmed technical support and separate terms. An AI-provider key does not establish customer-managed storage encryption, and no blanket zero-retention or certification claim follows.

Frequently asked questions