Data sheet Position on the V: Define Revised
Systems Engineering
Requirements development and allocation, system architecture and interface control, so the program converges through certification instead of discovering its architecture during flight test.
- Standards
- ARP4754B, ARP4761A; NASA SP-2016-6105 Rev 2 and NPR 7123.1 as the method reference
- Assurance
- Up to Design Assurance Level (DAL) A; the ARP4761A safety assessment sets each item's level
- When to call us
- Before the requirements baseline, or when integration keeps finding the seams
- Delivery
- Mostly remote, on-site as needed
Scope
Discipline engineers own the parts. We own the seams.
Good systems engineering is the difference between a program that converges smoothly through certification and one that discovers its architecture problems during flight test. We build and maintain requirements sets that are complete, verifiable and correctly allocated across hardware, software and operational procedures, with full traceability from stakeholder need down to test evidence.
The practice covers system and subsystem architecture definition, interface control documentation, trade studies and DOORS-based requirements management, informed by MBSE-adjacent modelling where it adds clarity without adding process overhead. It is grounded in real programs, turbine engine control, satellite payload software and safety-critical avionics, where a missed interface or an unallocated requirement carries real schedule and safety consequences.
Deliverables
The residue of decisions, kept so they survive turnover and audit.
| Document | What it is | NPR 7123.1 process |
|---|---|---|
| Expectations | Stakeholder expectations and concept of operations, baselined before the first requirement | 1 |
| Requirements | The technical requirements baseline, complete and verifiable as written | 2 |
| Allocation | Requirements decomposed and allocated to hardware, software and procedures, derived requirements identified | 3 |
| Architecture | The design solution at each level, with the make, buy or reuse decision per element | 4 |
| ICD | Interface control documents: the register of what crosses each boundary | 12 |
| Trade studies | Alternatives, criteria, data, recommendation and record, the answer to "why is it designed this way?" | 17 |
| Trace | Stakeholder need to requirement to test evidence, maintained in DOORS | 11 |
Four conversions, none skipped
Expectations are not requirements; requirements are not a design.
The design processes run top-down at every level of the system structure. Each conversion is where an error is caught cheaply, and each skipped conversion is where it survives until integration.
- 01 Stakeholder expectations Who the stakeholders are and what they actually need, as expectations and measures of effectiveness.
- 02 Technical requirements Expectations converted into complete, verifiable requirements: the contract everything downstream answers to.
- 03 Logical decomposition Which functions exist, how they relate and what flows between them, with derived requirements for the level below.
- 04 Design solution The design that satisfies the requirements, complete enough to build, buy or reuse, or to hand down a level.
What systems engineering is not
Four confusions that cost programs.
- Not project management Cost, schedule and staffing sit with project control; systems engineering owns the technical baseline.
- Not the sum of the disciplines Excellent software, structures and thermal teams can still fail at the seams; someone has to own the whole.
- Not documentation The artifacts are the residue of decisions; producing the residue without the decisions is the caricature.
- Not only for NASA-scale programs The processes scale down; what does not scale down is skipping them. Tailoring, not omission.
Field notes