What Rocket Science Taught Me About Requirements Gathering

The Launch Window Problem

At Yuzhnoye Design Bureau, we had a saying: "The rocket does not care about your assumptions." Every trajectory calculation began not with the destination, but with a ruthless examination of constraints — atmospheric density, gravitational perturbations, fuel mass ratios, and the thousand variables that stand between intent and orbit.

Business analysis, I have discovered, operates on the same principle.

Requirements Are Trajectories

When a stakeholder says "we need a dashboard," they are describing a destination without specifying the orbital mechanics to get there. The aerospace approach is to work backward from the desired orbit:

• •What altitude? (What decisions will this dashboard support?)
• •What inclination? (Who are the users and what are their viewing angles?)
• •What payload? (What data sources feed this, and at what refresh rate?)
• •What launch window? (When must this be operational, and what are the hard constraints?)

Every question narrows the solution space. Every answered question eliminates a category of failure.

The Three-Body Problem of Stakeholders

In orbital mechanics, the three-body problem has no general analytical solution — three gravitational bodies create chaotic, unpredictable interactions. Stakeholder management has the same property.

Product wants velocity. Engineering wants stability. Finance wants efficiency. No elegant formula resolves all three simultaneously. But aerospace taught me that you do not solve the three-body problem — you approximate it through iterative numerical methods.

Translated to business analysis: you run short discovery cycles, validate assumptions with real data, and adjust the trajectory continuously.

Failure Mode Analysis

Before any rocket launches, engineers conduct exhaustive failure mode analysis — what happens if valve 37B sticks open? What if the second stage ignites 0.3 seconds late?

I apply the same discipline to requirements. For every feature, I ask:

• What happens when the data source is unavailable?
• What happens when a user has no historical data?
• What happens at 10x expected load?
• What happens when the requirement itself changes mid-sprint?

The answers to these questions are not edge cases. They are the architecture.

Precision Language

In aerospace, ambiguity kills. "Approximately 3000 meters" is not a specification — it is a disaster waiting to happen. I have carried this intolerance for ambiguity into every requirements document I write.

"The system should be fast" becomes "The dashboard renders initial data within 1.2 seconds on a standard 4G connection with a p95 target of 2.0 seconds."

"Users need notifications" becomes "Active users receive push notifications within 30 seconds of a portfolio value change exceeding 2%, with a daily digest email at 06:00 UTC for changes below the push threshold."

Precision in language is not pedantry. It is the difference between a requirements document that guides implementation and one that generates arguments.

The Orbit Check

Every trajectory has periodic orbit checks — moments where ground control verifies the spacecraft is where it should be. In business analysis, these are review checkpoints:

1. Discovery orbit check: Do stakeholders agree on the problem statement?
2. Design orbit check: Does the proposed solution address the validated problem?
3. Implementation orbit check: Does the built feature match the specification?
4. Launch orbit check: Does the deployed feature achieve the intended business outcome?

Skipping an orbit check does not save time. It guarantees a more expensive correction later.

From Dnipro to Data

The skills I developed calculating rocket trajectories in Dnipro — systematic decomposition, failure mode thinking, precision language, iterative validation — turned out to be the most transferable skills in my career. Whether the trajectory leads to orbit or to a product launch, the physics of getting there are remarkably similar.

The rocket does not care about your assumptions. Neither does the market.