Requirements Management Lessons Learned: Ariane 5 Flight 501

The Ariane 5 Flight 501 disaster shows why we should always think twice before reusing as-is requirements, engineering designs, and tests from past projects. 

In hardware product development, it is common to reuse requirements, software routines, test cases, or design decisions from earlier projects. That can save time, but only if the conditions that made those choices valid still apply.

Ariane 5 Flight 501 was the first flight of Europe’s Ariane 5 rocket on June 4, 1996. The rocket reused part of the inertial reference software from Ariane 4, an earlier European rocket where the software had worked successfully. But Ariane 5 followed a different flight profile, one value exceeded the range the software expected, and the rocket was destroyed less than a minute after launch.

The lesson is simple, but easy to forget: before you reuse work from past projects, check whether the same assumptions and operating conditions still apply in the new project.

Key Takeaways

• Reusing proven requirements, software, tests, or design decisions saves time, but the old context needs to be reviewed.
• Review reused test cases before using them to prove the same requirement in another product.
• Reduce risk by keeping requirements, test procedures, evidence, and status connected.

What Happened in the Ariane 5 Launch

On June 4, 1996, Ariane 5 made its first flight from Kourou, French Guiana, carrying four Cluster research satellites for the European Space Agency. The mission lasted less than a minute. About thirty-seven seconds into the flight, the rocket moved away from its planned path and was destroyed.

The issue came from the inertial reference system, which sent attitude and velocity data to the rocket’s onboard computer. Ariane 5 reused software from Ariane 4, including an alignment routine that stayed active for about 40 seconds after launch. That routine had worked in Ariane 4, but Ariane 5 followed a different flight profile.

Because of that different profile, several things happened in rapid succession:

• A horizontal velocity value became larger than the software expected.
• The software tried to convert the value from a 64-bit floating-point number into a 16-bit signed integer, but it no longer fit.
• The conversion overflowed, and the inertial reference system treated this as an error and shut down.
• The backup system ran the same software and shut down for the same reason.
• Without valid flight data, the onboard computer used diagnostic data instead, gave the wrong flight commands, and the rocket was destroyed.

This is what makes the case useful for requirements management. The reused software had worked before, but it carried an assumption from the earlier rocket: that this value would stay within a safe range. Ariane 5 changed the context around that assumption, so it needed to be visible and checked again in the new system.

The illustration is a reminder that reused engineering work still needs one simple check: are the assumptions behind it still true in the new system?

What Hardware Teams Can Learn from the Ariane 5 Case

Most hardware teams are not building rockets, but they reuse proven work all the time. A PCB block from an earlier product may be copied into a new design. A firmware routine may move to a new hardware revision. A test procedure may stay in place after the power architecture changes. 

That is normal engineering work. Reuse helps teams move faster. The important step is making sure the requirement, assumption, and verification check still match the new system.

Review Reused Requirements

A requirement that worked in one product should not be treated as automatically valid in the next one. The same words may still look correct, but the operating conditions around them may have changed. For example, a current limit, thermal range, or interface constraint may be safe in one design and need review in another. Before reusing a requirement, the team should check whether the new product still operates inside the same assumptions.

Trace Assumptions to Verification Procedures

Some of the most important engineering assumptions are never written as formal requirements. They live in design notes, old test plans, or someone’s memory. This can become risky when work is reused. If an assumption affects a design decision, the team needs a way to connect it to a verification check. Otherwise, it is easy to reuse the decision without seeing the reason that made it safe in the first place.

Review Tests When Requirements Change

A test case that passed in the previous project does not always prove the same thing in the next one. If the requirement changes, or if the system around the requirement changes, the related test procedure may need to change too. This is especially important when teams reuse test cases, acceptance criteria, or compliance evidence.

How a Connected Requirements Workflow Helps

A better requirements workflow does not treat a requirement as a standalone line of text. It keeps the requirement connected to the reason behind it, the design work it affects, and the verification work that shows whether it is still valid. 

That’s what matters most when something changes. A reused requirement may still look correct, but the assumption behind it may no longer match the new product. A test may still exist, but it may no longer check the right condition.

In a connected workflow, teams can keep the important pieces close together: the requirement, the context behind it, the verification method, the procedure, the result, the evidence, and the current status. Instead of searching through old documents or test reports, engineers can see what is connected and what may need another review.

Altium Requirements Portal supports this kind of workflow by keeping requirements, traceability, ownership, and verification work in one shared environment. This helps teams reuse proven work with more confidence because the requirement and the checks around it stay connected.

Are the Old Assumptions in Your Project Still True?

Every hardware team reuses proven work. That is not a shortcut to avoid, but a practical way to build faster and carry good engineering decisions forward. 

The useful question is what changed around that reused work:

• Did the operating range change? 
• Does the test need to be revised? 
• Do the assumptions behind the original decision still apply?

When teams can answer those questions, reuse becomes easier to trust. The requirement does not stand alone. The reason behind it, the verification check, and the evidence stay close enough for the team to review when the product context changes. 

This is the lesson Ariane 5 still gives hardware teams today: reuse works best when the context behind it stays connected.

Make reuse decisions easier to check and trust with a requirements management tool your whole team can access.

Get started with Requirements Portal →

Frequently Asked Questions

Can Reusing Engineering Work Become Risky?

Reusing engineering work can become risky when the product context changes but the original assumptions, operating limits, or verification checks are not reviewed again. The work may still look correct, but the conditions that made it valid in the previous project may no longer apply.

What Should Engineers Check Before Reusing a Requirement, Test, or Design Decision?

Teams should check whether the new product uses the same operating conditions, interfaces, limits, and acceptance criteria as the original project. They should also confirm that the related verification method still proves the right thing in the new system.

How Does Traceability Help When Requirements Are Reused?

Traceability helps teams see how a requirement connects to design decisions, assumptions, test procedures, evidence, and status. When reused work moves into a new project, those links make it easier to see what is still valid and what may need review.