NewSpace is moving insanely fast. We’re building rockets that land themselves, creating software-defined satellites, and experimenting with completely new methods to get payloads into space. This isn't just NewSpace; it’s NewAero, NewFusion, and so many more areas.

At the core of this movement - are engineers. The burden on NewSpace engineers exceeds that of those in more traditional aerospace companies. Things change incredibly quickly; digital design and testing are faster and cheaper, making them critical tools, and engineers are expected to really own things.

In and among all of this - we’ve seen one clear pattern that differentiates the best NewSpace teams - how they deal with requirements differently.

What goes wrong with a traditional Requirements Management process?

The old-school approach to requirements is simple. They act as an external contract between a company and its customers. Customer contracts don’t change all that much, so it's fair to write it up, agree to it, painfully write it in IBM DOORS, Jama or the other clunky enterprise tools, send it to a customer, and then put it in a locked box until the end of the project.

At the end of the project, traditional space teams typically look at their design now it’s integrated, and in a moment of shock and horror, realise that their design doesn’t match the requirements that were given to them and realise they need a few more months and hundreds of millions to course correct.

What changed? System Complexity.

New space engineers are working on designing products they don’t know will even be possible. It requires us to make some early assumptions around the product, quickly test those assumptions through analysis models or physical build/test cycles, and refine them.

I may realise that my assumptions around cooling mass flow rates for my single-stage to-orbit engine are too optimistic, and I need a higher feed rate to get the required heat flux. If so, that changes my requirements on the inlet flow rate, which may be owned by someone else. That change will cause secondary and tertiary changes in other parts of the system owned by other engineers.

Things are so new and complex that we must make assumptions to start and then iteratively and quickly update and refine these assumptions until we know we have something that obeys both the laws of physics and (unfortunately) the laws of economics.

"Agile Requirements" is a term we have started using to describe the process that the best new-space teams are already using for requirements.

How are "Agile Requirements" different?

The core difference to a traditional requirements process is that rather than requirements being a purely external contract, they are also internal contracts between engineers. Requirements have effectively become the schema of agreements inside the engineering team.

This makes a huge difference because requirements have now become the method by which the best teams collaborate throughout the design stage.

So what are some concrete differences between the traditional and new processes?

1. Requirements are now owned by the people implementing them

For a team to be able to move fast - every requirement must have one person who “owns it”. This person is responsible for implementing the requirement, can tell the team if it needs to change, and is the person you go to to ask questions about it.

The engineers implementing them are the people on the ground and closest to the design. They are the people with the most context - so we need to give them ownership.

Whereas before, all requirements would be owned by a systems engineer or the chief engineer, with "Agile Requirements", we empower engineers to own and manage the requirements they are working on.

2. Parent, Child, Cousin (Cross-links)

Everyone knows parent-child relationships. Cousins are newer, and these cross-links are now essential.

This highlights a key insight into what is really going on - requirements are no longer a simple tree - but a complex web of interconnected dependencies.

3. Change happens quickly and does not wait for design reviews

Change happens quickly and continuously. We can’t afford to wait for major design reviews to share changes. Requirement tools must be a core part of this information dissemination.

4. Verification happens continuously, not just at major stage gates

It’s not good enough to just communicate requirements changes in bulk documents - we need to close the loop continuously.

We need to understand whether these changes are good for us or not - as they happen.

IBM DOORS and its discount competitors are no longer fit for purpose

*Definitely not DOORS

DOORS and its 100 cheaper clones are built for simpler times. Times when the need for collaboration wasn’t what it is today, when teams moved slower, and we could afford three weeks of training to teach someone the basics of a tool.

The simple fact of the matter - is that new requirement tools need to look and feel closer to a social network than a database with a bad UI.

This is exactly why you’re seeing so many engineering leads hack software tools like Jira, Airtable, Smartsheets and other cloud-based databases for their requirements.

We’ve built Flow, so you don’t have to. If this resonates - have a conversation with us.

If you want to learn more, please join our mailing list below, message me on Linkedin, or email me directly.