Requirements Management Lessons Learned: The S-80 Submarine Program

The S-80 submarine program shows us why requirements, constraints, design changes, and verification checks need to stay connected in hardware product development projects.

In hardware product development, a design change can solve the immediate issue while raising new questions elsewhere in the system. That is why requirements management is not only about capturing what the product should do, but also about keeping related constraints, design decisions, and verification checks visible as the design evolves.

Spain’s S-80 submarine program shows this pattern clearly. During development, the program faced a major weight and buoyancy challenge. The redesign helped address that issue, but the updated vessel dimensions introduced a new practical problem: the submarine was now too long for the harbor it was meant to use.

Here’s a transferable lesson for all teams developing hardware products - whether you’re building a submarine or an electronic gadget: when requirements, constraints, design changes, and verification checks are disconnected, teams have a hard time seeing what else a change may affect.

Key Takeaways

• Requirements conflicts often surface when critical constraints sit outside the workflow used to review design changes.
• Teams can reduce this risk by linking requirements to the constraints, design decisions, and verification checks they affect.
• A connected requirements workflow makes it easier to see what changed, what it affects, and what needs review before rework becomes costly.

What Happened in the S-80 Program

Spain launched the S-80 program to develop a new class of submarines. During development, the program faced a serious weight and buoyancy issue. The vessel had become heavier than planned, raising concerns about whether it would have enough buoyancy margin to surface reliably after diving.

The design was revised to address the issue. One of the key changes was a longer hull, which helped restore the needed buoyancy margin. That revision also changed the vessel’s physical dimensions. The updated submarine then had to be reviewed against the infrastructure where it would operate, and that review revealed a practical problem: it would no longer fit the harbor.

The infrastructure issue added another layer of work to a program that had already required a major redesign. The program ultimately became more complex, took longer, and became more expensive than originally expected.

The illustration offers a reminder that every redesign still has one more question to answer: What else now needs to be checked?

What Hardware Teams Can Learn from the S-80 Case

Most hardware teams work at a smaller scale than a submarine program, but the same pattern can appear in everyday product development: a design change may affect size, compliance requirements, or interface constraints beyond the issue the team is currently trying to solve.

Knowing those constraints is not enough. This is where requirements management matters: it helps teams keep them visible, connected, and reviewable as the design evolves. For hardware teams, that comes down to three practical habits:

Keep Critical Constraints Visible

Critical constraints should not live only in meeting notes, spreadsheets, or someone’s memory. They should be captured clearly and, where possible, written in measurable terms so teams can check them as the design changes.

Connect Requirements to Design Decisions

A requirement is more useful when it is linked to the system area, block, design object, or engineering activity it affects. That connection helps engineers see why a design decision matters, which requirements it supports, and what else may be affected when the design changes.

Use Traceability to Review Change Impact

Traceability helps teams answer a practical question: What else does this change affect? When requirements stay linked to design decisions, constraints, verification checks, and evidence, teams can see what changed, what is still covered, and what needs review before rework becomes costly.

How a Connected Requirements Workflow Helps

Hardware teams need more than a place to store requirement text. Documents and spreadsheets can capture requirements, but they become harder to manage as project complexity increases and each requirement needs to stay connected across the engineering chain.

Altium Requirements Portal is designed to support that workflow by managing requirements, traceability, ownership, and verification in one shared environment. Instead of treating requirements as isolated text, teams can see what changed, what it affects, who owns the next step, and how the requirement will be checked.

What's the "Submarine" in Your Project?

Every hardware development project has constraints that are easy to miss when the design is moving quickly. They may be mechanical, electrical, regulatory, operational, or process-related. The risk is not that teams lack knowledge, but that important knowledge is not always captured, connected, and reviewed when the design changes.

That is what makes the S-80 case useful beyond its scale. The same pattern can appear in everyday product development when engineering intent, design decisions, and evidence are not kept connected over time.

Make change impact easier to trace with a requirements management tool your whole team can access.

Get started with Requirements Portal →

Common Questions

What Causes Requirements Management Problems in Hardware Projects?

Requirements management problems often appear when requirements are not connected to the design work, constraints, and verification checks they affect. A requirement may exist, but if the team cannot see what it connects to, important impacts can be missed when the design changes.

Why Do Spreadsheets Become Difficult for Requirements Management?

Spreadsheets can capture requirement text, but they become harder to manage as project complexity increases. Teams need a way to keep requirements connected to design work, change history, verification status, and evidence across the engineering chain.

How Does Traceability Help Reduce Late-Stage Rework?

Traceability helps teams answer a practical question: What else does this change affect? By linking requirements to design decisions, constraints, verification checks, and evidence, teams can see what needs review before rework becomes costly.