The Software and Systems Engineering Experts
US: +1 (610) 247-9595 / EU: +48 666 74 71 74
Home · Solutions · Space
Solutions · Space
Space missions with review‑ready traceability
ECSS-E-ST-40C evidence from one connected IBM Engineering Lifecycle Management toolchain, set up by consultants who work with safety- and mission-critical programs.
Space
The space sector
Spacecraft are defined in software
The sector covers space agencies, satellite and launcher primes, and the supply chain behind them: equipment and subsystem suppliers for platforms and payloads, ground segment and software companies. Missions take years from contract to launch, pass a fixed sequence of reviews and are bought by agencies such as ESA and NASA under ECSS or NASA standards.
More and more of what a spacecraft does is defined in on-board software, often updated in orbit. Every requirement has to be verified before launch, and the trace has to hold through every review from SRR to qualification and acceptance.
ShiftNew space and constellations
Commercial operators build satellites in series, with short schedules and lighter reviews, but still expect evidence for each requirement.
ShiftSoftware-defined payloads
Reconfigurable payloads and on-board processing move mission functions into software that changes after launch.
ShiftNew suppliers in European programs
National and ESA programs bring in suppliers that have to work to ECSS from their first contract.
ShiftModel-based engineering
Agencies and primes expect a digital thread from mission requirements through SysML models to verification.
Engineering challenges
What this means for software and systems engineering
Reviews across the life cycle
ECSS reviews from SRR through PDR, CDR and QR each need a consistent set of requirements, design and verification data.
Customer and supplier chain
Requirements flow from the agency to the prime and down to equipment suppliers in Requirements Interchange Format (ReqIF) or documents, and answers come back the same way.
Verification control
Each requirement needs a verification method, a close-out reference and a status in the verification control document.
Software criticality
Software is classified in criticality categories A to D, and the category sets the depth of the process and the evidence.
Product assurance
ECSS-Q-ST-80C asks for software product assurance alongside development: reviews, metrics, nonconformances and their closure.
Change in flight
Missions are operated for years. Every on-board software update needs the same trace and verification as the original release.
What reviewers expect
Where space teams lose time before a review
Requirements go to equipment suppliers as specifications, and compliance matrices come back as spreadsheets that nobody links to the specification tree.
The software requirements baseline is written by the software team from a copy of the system specification.
Before each review the team collects test reports, analyses and inspections and maps them to requirements in a spreadsheet.
RiskNon-compliances and deviations are found late, at the supplier's own reviews or at integration.
With Smarter ProcessSupplier requirements are exchanged through ReqIF, and compliance answers come back into the same trace, compared with the previous delivery.
RiskSystem changes after PDR never reach the software, and the gap appears at test.
With Smarter ProcessSystem and software requirements are linked in one IBM Engineering Lifecycle Management project, with suspect links when the system side changes.
RiskReview item discrepancies on verification close-out delay the review.
With Smarter ProcessVerification methods, close-out references and status live on each requirement, and the verification control document is a saved view.
Compliance map
ECSS-E-ST-40C, ECSS-Q-ST-80C and ECSS-E-ST-10C, mapped to the toolchain
Pick a standard to see what it asks for, and where it lives in your toolchain once we have set it up.
ECSS-E-ST-40C · Requirements baseline and technical specification
IBM Engineering Requirements Management DOORS Next
What it asks forSoftware requirements captured in the requirements baseline and technical specification, traced to system requirements
How we cover itRB and TS modules with links up to the system specification and down to design
IBM Engineering Requirements Management DOORS NextECSS-E-ST-40C · Verification and validation
IBM Engineering Test Management
What it asks forSoftware verified and validated against the technical specification and requirements baseline, with traceability
How we cover itTest cases and results linked to each TS and RB requirement; coverage per software release
IBM Engineering Test ManagementECSS-E-ST-40C · Reviews
IBM Engineering Lifecycle Management Global Configuration ManagementIBM Engineering Lifecycle Optimization – Publishing
What it asks forData packages for SRR, PDR, CDR, QR and AR with consistent content
How we cover itA global configuration per review; data package documents generated from the baseline
IBM Engineering Lifecycle Management Global Configuration Management
IBM Engineering Lifecycle Optimization – PublishingECSS-Q-ST-80C · Software criticality
IBM Engineering Requirements Management DOORS Next
What it asks forSoftware criticality category A to D assigned and used to tailor the process
How we cover itCriticality attribute on software products and requirements, driving reviews and test depth
IBM Engineering Requirements Management DOORS NextECSS-Q-ST-80C · Nonconformance and change control
IBM Engineering Workflow ManagementGitLab
What it asks forSoftware problems and nonconformances recorded, analysed and closed under configuration control
How we cover itNonconformance and change request work items linked to the requirements, code and tests they affect
IBM Engineering Workflow Management
GitLabECSS-E-ST-10C · Specification tree
IBM Engineering Requirements Management DOORS NextIBM Engineering Systems Design Rhapsody
What it asks forA specification tree from mission to equipment level, with requirements traced between levels
How we cover itSpecification modules per level with link rules and a tree view across customer and supplier levels
IBM Engineering Requirements Management DOORS Next
IBM Engineering Systems Design RhapsodyECSS-E-ST-10C · Verification control
IBM Engineering Requirements Management DOORS NextIBM Engineering Test Management
What it asks forA verification method for each requirement and control of verification close-out
How we cover itVerification method, close-out reference and status attributes; the verification control document as a saved view
IBM Engineering Requirements Management DOORS NextIBM Engineering Test ManagementNASA NPR 7150.2 · Bidirectional traceability
IBM Engineering Requirements Management DOORS NextGitLabIBM Engineering Test Management
What it asks forTraceability between system requirements, software requirements, design, code and tests in both directions
How we cover itLink types from system to software requirements, GitLab merge requests and test cases, with gap views
IBM Engineering Requirements Management DOORS NextGitLabIBM Engineering Test ManagementBook a 30-min compliance gap review
Compliance is achieved by your organization and confirmed by your customer and its review boards. Tools hold the evidence; we set them up so the evidence is complete and easy to show.
Capabilities
What your team can do on day one
Baselines for every review
Freeze a configuration for each SRR, PDR, CDR or QR and compare it with the next one, item by item. Review boards see exactly what changed and why.
- IBM Engineering Lifecycle Management Global Configuration Management
Verification control that stays current
Verification method, close-out and status sit on each requirement, so the verification control document is always up to date.
- IBM Engineering Requirements Management DOORS Next
- IBM Engineering Test Management
Customer and supplier exchange
Specifications go out and compliance answers come back through ReqIF, merged into the same specification tree and compared with the last delivery.
- IBM Engineering Requirements Management DOORS Next
MBSE linked to requirements
SysML models link to requirements, so a change in the architecture shows which requirements and tests to recheck.
- IBM Engineering Systems Design Rhapsody
Nonconformances closed with a trace
Software problems and nonconformances link to the requirements, code and tests they affect, so closure is visible at the next review.
- IBM Engineering Workflow Management
- GitLab
Review data packages from live data
Specifications, verification control documents and traceability reports are generated from the tools, in your own templates.
- IBM Engineering Lifecycle Optimization – Publishing
See every product we implement and support
IBM Engineering Lifecycle Management, HCL and GitLab: licences, set-up, training and support from one team.
All products →
Satellite integration clean roomHow we work
How we set up a space engineering toolchain
We start from your contract and the ECSS tailoring your customer applies, define the specification tree, artifact types, criticality attributes and link rules, and set up IBM Engineering Lifecycle Management on your own servers or hosted for you. Existing specifications are migrated and the team is trained on real project data.
Spec treefrom mission to equipment level
Reviewswith a baseline for each
ECSS tailoringmapped to the toolchain
FAQ
Questions space teams ask us
Do the tools need to be qualified under ECSS-Q-ST-80C?
ECSS-Q-ST-80C asks you to select, justify and control the methods and tools used to develop and verify software, and to show they are suitable for the criticality category. Requirements and test management tools do not generate flight code, and their output is checked in reviews, so a documented justification is usually enough. We describe each use case, the tool version and configuration, and the checks that cover tool errors in your software product assurance plan.
How do we exchange requirements with the agency, the prime and our suppliers?
Through ReqIF where the other side's tool supports it, and through structured documents where it does not. Each supplier gets only the specifications for its equipment. Compliance answers, deviations and comments come back into the same requirements, compared with the previous delivery, so you see what changed before the next review. Customer specifications keep their original identifiers, so references in review item discrepancies still point to the right requirement.
Several satellites or product lines share the same software. How do we manage that?
With components and streams in IBM Engineering Lifecycle Management Global Configuration Management. Common platform requirements and software live in shared components, and each spacecraft or product line is a configuration that reuses them. A fix is made once and delivered to the missions that need it, with a compare view before it is accepted. Each mission keeps its own baselines for its reviews, so qualification evidence for one satellite is not mixed with another.
Our specification tree is in IBM Engineering Requirements Management DOORS (9.x), with DXL scripts. How do we move?
Not all at once. Projects close to a review often stay on IBM Engineering Requirements Management DOORS (9.x) until the next baseline, while new work starts in IBM Engineering Requirements Management DOORS Next. When a project moves, modules, attributes and links move with their original IDs, and each review baseline is kept as a baseline in IBM Engineering Requirements Management DOORS Next, so earlier data packages stay reproducible. DXL scripts are inventoried first; most are replaced by configuration, views or attribute rules.
Our software teams work in Atlassian Jira and GitLab. Do they have to switch?
No. Software teams keep Atlassian Jira for their backlog and GitLab for code and pipelines. Jira issues and GitLab merge requests link to the software requirements they implement in IBM Engineering Requirements Management DOORS Next, through OSLC links or a synchronization we configure. Test results from the pipeline can be reported into IBM Engineering Test Management, so the verification status per requirement comes from the tools, not from a spreadsheet maintained before each review.
How do we handle security and export control on space programs?
Each partner gets only the modules and attributes it is allowed to see, through ReqIF exchange or controlled access to a separate project area. Export classification can be an attribute on every requirement, used in views and exports so controlled content does not leave by mistake. IBM Engineering Lifecycle Management runs on your own servers, including closed networks, with access control per program, and security requirements for the space and ground segment sit on the same links as the rest.
New · SmarterWidgets 2.0
Ready-made widgets for IBM DOORS Next
Add them to the ELM Mini Dashboard and hand repetitive requirements work over to them. Each one previews its changes first.
Browse all widgets- Content qualityClean text and glossary linksStyle Cleaner, Link Checker and more
- Links and traceabilityFix, move and inspect linksLink Remover, Module To Base Links and more
- Module structureBuild and repair module hierarchyModule Fill, Module Explorer 2.0 and more
- Configuration and governanceBaselines, data models and auditsBaseline Archiver, Compare Data Models and more
- Reporting and publishingCharts, maps and publishingPublishing URLs, Module Insights and more
- See all widgetsScreenshots and details for every widget
Watch and learn
Our Videos
Demos, tutorials and customer stories on requirements, traceability and test.
Talk to our consultants
Leave your details and we will get back to you, usually within one business day.
