Systems engineers and architects
Turn stakeholder needs into coherent system behaviour, deliberate boundaries and evidence-ready decisions across hardware, firmware and software.
After this module, you should be able to:
- Frame the product as a complete operating system
- Allocate responsibilities and budgets across disciplines
- Control interfaces, assumptions and architectural decisions
- Connect risk, requirements and verification evidence
Study guide · Updated · About 8 minutes reading + 20–30 minutes practice
Before you start: Start with TEA-101. Use TEA-105 and TEA-106 when timing or fault-response allocation is unfamiliar.
Own coherence rather than every technical detail.
The systems role keeps product intent, physical behaviour and implementation aligned. It defines the boundary, identifies external actors and operating conditions, and makes cross-disciplinary qualities—safety, timing, security, power, accuracy and maintainability—visible early enough to shape the design.
Make the cross-boundary work explicit.
| Responsibility | Key question | Useful evidence |
|---|---|---|
| Context and scope | What is inside, outside, controlled or assumed? | Context diagram and assumptions log |
| Behaviour | What must happen in every mode, transition and fault? | Scenarios, state models and requirements |
| Allocation | Where should sensing, decisions, actuation and monitoring live? | Function allocation and rationale |
| Interfaces | What crosses each boundary, with what timing and validity? | Interface control records |
| Assurance | How will critical claims be demonstrated? | Verification strategy and traceability |
Interfaces are shared products
Define ownership, units, ranges, rates, latency, start-up behaviour, invalid values, timeouts, versioning and recovery. A named owner may maintain the contract, but both sides must review and verify it.
Lead with scenarios and budgets.
- Walk the lifecycle. Include manufacture, installation, start-up, normal use, service, update and disposal.
- Trace critical scenarios. Follow energy, data and control through every participating element.
- Allocate budgets. Divide timing, accuracy, power, memory and diagnostic-response targets.
- Record trade-offs. Capture alternatives, assumptions, rationale and consequences.
- Plan integration. Define staged builds, simulators, instrumentation and entry criteria.
- Challenge the architecture. Review common causes, latent faults, misuse and security threats.
Worked hand-off: loss of position feedback
The architect defines detection latency, the permitted residual motion and the safe response. Hardware explains signal diagnostics and energy isolation; firmware owns plausibility and state transition; test engineering injects open, short, frozen and noisy signals. The safety engineer checks that the combined response supports the risk control.
Leave an auditable line of reasoning.
Clear, feasible and testable system requirements with traceability.
Context, behaviour, structure, deployment and fault containment.
Alternatives, rationale, constraints and affected requirements.
Controlled contracts with agreed owners and versions.
Allocated and reconciled resource and performance margins.
Claims connected to analysis, reviews and verification results.
Common traps
Blocks are named, but modes, timing and failure responses remain implicit.
Responsibilities follow team boundaries rather than technical need.
Critical premises are neither validated nor monitored.
The build sequence and observability arrive after implementation.
Turn stakeholder language into observable system claims
A stakeholder may ask for reliable operation, fast response or seamless recovery. The systems engineer helps turn those intentions into conditions and observable outcomes without silently inventing product policy. Who uses the system, in which environment, for which operation, and what must happen if the operation is interrupted?
Separate requirements from design choices and assumptions. “Use two sensors” is an allocation choice unless it is an externally imposed constraint. The underlying need may be to detect a hazardous measurement error. Recording that distinction keeps alternative architectures available while preserving the safety intent.
Use scenarios to expose missing decisions. Walk power-on, a delayed command, a service action and a power interruption with the relevant disciplines. Capture each unresolved question with an owner and a date needed by downstream work. A diagram with unowned assumptions is not a closed architecture.
Lead interface decisions with budgets and authority
An interface owner maintains the agreement, but both endpoints must accept it. A hardware engineer may define electrical timing while a firmware engineer defines data validity and the application engineer defines user-visible completion. Bring these together into one contract for the physical behaviour.
Keep shared budgets for response time, accuracy, energy and storage. Name who can approve a change and what evidence is required. If a sensor adds 20 ms latency, the systems decision is whether the whole response still meets its limit; it cannot be settled solely by the sensor team accepting its own test.
Define how disagreement is resolved. A trade study should compare feasible alternatives against the important constraints and retain the reason for the choice. Escalate decisions that change intended use, risk or external commitments to the appropriate authority.
| From a discipline | Systems responsibility | Return to the team |
|---|---|---|
| Hardware timing data | Reconcile the complete response budget. | Accepted allocation and margin. |
| Firmware fault model | Check physical response and common causes. | Agreed containment and recovery requirements. |
| Verification results | Compare claims, configurations and gaps. | Closure decision or targeted next evidence. |
Review integration readiness rather than document volume
A useful integration gate asks whether interfaces, versions, observation points and failure responses are ready for the next experiment. A complete-looking specification can still omit the state after reset. Seek a coherent explanation of the behaviour being integrated and the evidence that would falsify it.
Maintain traceability through changes. When an assumption becomes false, find the requirements, architecture decisions, tests and support instructions that depend on it. The systems role closes the loop across these records; it does not need to perform every specialist calculation.
Practical exercise
An illustrative engineering exercise; values are assumptions for this lesson.
Resolve a late sensor substitution
A supplier proposes a more available sensor with the same measurement range but 25 ms more internal filtering delay. Hardware approves its electrical fit; firmware can read it without changes.
- Identify the system claims affected beyond electrical compatibility.
- List the evidence required from hardware, firmware and verification.
- Define an acceptance decision and a trigger for redesign.
Show the worked answer
Revisit control stability, alarm timing, sample freshness, diagnostic behaviour and calibration. The unchanged register interface does not establish behavioural compatibility. Request the sensor’s timing and accuracy evidence, the firmware’s acquisition and timeout assumptions, and a revised end-to-end response budget.
Accept the substitution only if the relevant claims remain supported with appropriate margin and representative testing. If the added delay violates a protective limit, investigate a different configuration, sensor or protection allocation. Record the decision and update the compatibility baseline. A procurement benefit is relevant to the trade, but it does not replace the technical acceptance criteria.
Review criteria
- The assessment follows physical behaviour across disciplines.
- Evidence requests are specific and assigned.
- The decision includes a clear condition that would prevent acceptance.
Check your understanding
Must systems engineers own every detailed design?
No. They own coherence, allocation and cross-boundary decisions while specialists retain responsibility for their detailed work.
When is an assumption ready to close?
When its evidence and applicable conditions are recorded and the consequences of violating it are understood.
Further learning
- NASA Systems Engineering HandbookTechnical processes, lifecycle integration and technical management.
- TEA-101 · Embedded systems architectureArchitecture fundamentals for embedded products.
Protect the integrity of the whole system.
Make behaviour, boundaries, assumptions, ownership and evidence explicit enough that every discipline can make compatible decisions.