Requirements engineering sometimes gets treated as documentation.
It isn't.
A well-defined requirements baseline is one of the foundations of a successful space programme. It connects mission objectives, system architecture, subsystem design, interfaces, verification activities and ultimately mission acceptance.
When that baseline is weak, the consequences rarely remain inside the requirements database.
They appear later as design changes, interface conflicts, failed verification activities, supplier disagreements and programme delays.
The challenge is that many of these problems can remain hidden until significant engineering work has already been completed.
Here are seven warning signs that your requirements baseline may need attention.
1. Different Teams Understand the Same Requirement Differently
If two experienced engineers can read the same requirement and reach different conclusions about what must be delivered, the requirement probably needs work.
Requirements should be clear, unambiguous and sufficiently precise to support both implementation and verification.
Consider a requirement stating:
The spacecraft shall provide reliable communication with the ground segment.
What does reliable mean?
Does it refer to link availability, data integrity, maximum outage duration or communication performance under specific operating conditions?
Without measurable criteria, different teams may interpret the requirement differently.
Ambiguity introduced early can become expensive once hardware and software development begins.
2. Requirements Describe Solutions Instead of Needs
Requirements should define what the system must achieve and the constraints within which it must operate.
When requirements prematurely dictate implementation, they can restrict engineering freedom and create unnecessary limitations during architecture development.
For example, specifying a particular technical solution before completing the relevant trade-off analysis may prevent engineers from identifying a more efficient or robust alternative.
This does not mean implementation constraints should never appear in requirements.
Sometimes they are necessary because of compatibility, heritage, customer requirements or programme limitations.
The important distinction is that these constraints should be intentional, justified and traceable.
Good systems engineering ensures that requirements guide the design without unnecessarily determining every design decision.
3. Interfaces Live in PowerPoint Presentations
Interfaces are where complex systems meet — and where many programme problems begin.
A spacecraft programme typically involves multiple disciplines, organisations and suppliers, each responsible for different elements of the overall system.
Mechanical, electrical, thermal, software and data interfaces must all work together.
But what happens when interface information is distributed across:
- PowerPoint presentations
- Meeting minutes
- Supplier documentation
- Engineering spreadsheets
- Email conversations
- Different versions of interface control documents
Maintaining a consistent technical baseline becomes increasingly difficult.
A programme should always be able to answer one fundamental question:
What is the current, authoritative definition of this interface?
If the answer is unclear, there is a risk that different teams are designing against different assumptions.
Interface management is not simply document control. It is a critical part of system integration.
4. Verification Is Something the Team Will Define Later
Every technical requirement should have a clear path towards verification.
This does not mean detailed test procedures must be completed during early design.
However, engineers should understand how compliance will eventually be demonstrated.
Common verification methods include:
- Test: Measuring system performance against defined criteria.
- Analysis: Demonstrating compliance through calculations, modelling or simulation.
- Inspection: Confirming compliance through examination of hardware, software or documentation.
- Review of Design: Evaluating design evidence to establish compliance.
For ESA programmes, verification planning and evidence management must align with the applicable ECSS requirements and the project's agreed verification approach.
A requirement that cannot be verified may be poorly formulated, insufficiently defined or dependent on information that is not yet available.
Discovering this late in the programme can create major challenges.
Testing may need to be redesigned, additional equipment may be required, or compliance may become difficult to demonstrate.
Verification should influence requirements from the beginning — not become an activity added at the end.
5. Traceability Stops at the System Level
Requirements do not exist independently.
Mission objectives drive system requirements.
System requirements are allocated to subsystems.
Subsystem requirements influence architecture and detailed design.
Verification activities provide evidence that the implemented system meets its requirements.
These relationships form the engineering traceability chain.
When that chain is incomplete, teams lose the ability to understand how changes affect the wider system.
For example, if a payload requirement changes, the programme may need to understand its impact on:
- Electrical power budgets
- Thermal control
- Mechanical accommodation
- Data handling
- Operational scenarios
- Verification procedures
- Supplier responsibilities
Without traceability, this impact assessment becomes much more dependent on individual knowledge and manual investigation.
This is one of the reasons Model-Based Systems Engineering (MBSE) can offer significant value.
Tools can help maintain relationships between requirements, architecture elements, interfaces and verification evidence.
However, the engineering logic behind those relationships remains essential.
Traceability is not simply an ECSS compliance exercise. It is a tool for making informed engineering decisions.
6. Requirements Keep Changing Without Understanding the Impact
Change is inevitable in space programmes.
New technical information becomes available.
Customer needs evolve.
Suppliers identify limitations.
Trade-off studies lead to different design decisions.
The problem is not change itself.
The problem is uncontrolled change.
When a requirement changes, the programme needs to understand which other elements may be affected.
This includes the system architecture, interfaces, design documentation, verification activities, schedules and potentially contractual commitments.
A disciplined change-control process should provide:
- A clear description of the proposed change
- Technical justification
- Impact assessment
- Identification of affected requirements and interfaces
- Review and approval responsibilities
- Configuration control of the updated baseline
Without this process, relatively small changes can propagate through the programme without everyone understanding their consequences.
7. The Requirements Database Says Everything Is Fine — But Engineers Disagree
Requirements management tools are valuable.
They help organise technical information, establish traceability, manage changes and support verification planning.
But tools do not replace engineering judgement.
A requirements database may show that every requirement has an owner, a verification method and a completed review status.
That does not necessarily mean the requirements are technically sound.
If the engineering team still disagrees about system behaviour, interfaces or design assumptions, the baseline may not be as mature as its status indicators suggest.
This is particularly important when preparing for major technical reviews such as:
- System Requirements Review (SRR)
- Preliminary Design Review (PDR)
- Critical Design Review (CDR)
- Test Readiness Review (TRR)
The objective of these reviews is not simply to demonstrate that documentation exists.
It is to establish whether the technical baseline is sufficiently mature to proceed with an acceptable level of risk.
A well-maintained database supports good systems engineering. It does not create it.
What Does a Strong Requirements Baseline Look Like?
A mature requirements baseline should make engineering work easier rather than more bureaucratic.
Engineers should understand what they are responsible for delivering.
Suppliers should know what they must demonstrate.
Interfaces should be defined and controlled.
Verification activities should be planned.
Changes should be traceable.
Programme managers should be able to assess technical maturity using reliable information.
Most importantly, the requirements should reflect a shared understanding of the system being developed.
This requires more than a requirements management tool.
It requires experienced systems engineers who understand the relationships between mission objectives, architecture, technical disciplines and verification.
The Real Value of Getting Requirements Right Early
One of the most important principles in systems engineering is that problems generally become more difficult and expensive to resolve as development progresses.
A poorly defined requirement discovered during early design might be resolved through a technical discussion and a baseline update.
The same problem discovered during integration or qualification could require hardware modifications, software changes, additional testing or significant schedule adjustments.
This is why early investment in requirements quality, interface definition and verification planning can provide substantial programme value.
The objective is not to create more documentation.
It is to reduce uncertainty, improve engineering decisions and prevent avoidable problems later in the programme.
How Nord Space Can Help
At Nord Space, we support space and defence organisations with experienced systems engineering specialists who understand the practical challenges of complex technical programmes.
Our expertise includes:
- Requirements definition, analysis and management
- Systems architecture and technical coordination
- ECSS standards and compliance
- Interface definition and control
- Model-Based Systems Engineering (MBSE)
- Verification and validation planning
- Technical review preparation and support
- Configuration management and change control
Whether you need support establishing a new engineering baseline, preparing for a major review or resolving issues within an existing programme, Nord Space can help identify the right specialist expertise.
Is your engineering baseline ready for the next programme milestone?