Systems Engineering and System Integration
This domain tests whether you can take a stakeholder need, decompose it into verifiable requirements, manage the interfaces between the resulting elements, and prove the integrated system does what was asked. It rewards precise language and traceability.
Life cycle and the V model
- ISO/IEC 15288 frames the life cycle: stakeholder needs, requirements, architecture, design, implementation, integration, verification, transition, validation, operation, maintenance, disposal.
- The V model pairs each decomposition level on the left with an integration and verification level on the right. The test definition is written when the requirement is written, not when hardware arrives.
Requirements discipline
- ISO/IEC 29148 characteristics: necessary, unambiguous, complete, singular, feasible, verifiable, traceable.
- "Shall" is mandatory, "should" recommended, "may" optional. One requirement, one thought, one verification method.
- Maintain a bidirectional traceability matrix from stakeholder need to requirement to design element to test.
Verification, validation and interfaces
- Verification asks "was the system built right" and uses inspection, analysis, demonstration and test (IADT). Validation asks "was the right system built" against the stakeholder need, usually in the operational environment.
- Interface control documents define physical, functional, electrical and data interfaces, with one nominated owner per interface. An N² diagram exposes the coupling.
- Configuration management keeps functional, allocated and product baselines under change control board authority.
Worked example
A cell must "place parts within ±0.10 mm at 600 parts/h". Flow-down: robot repeatability per ISO 9283 ≤ 0.03 mm, vision accuracy ≤ 0.04 mm, fixture location ≤ 0.02 mm. Root-sum-square = √(0.03² + 0.04² + 0.02²) = 0.054 mm, leaving margin against 0.10 mm. Verification is a 50-part capability trial requiring Cpk ≥ 1.33 on position; validation is an eight-hour run at 600 parts/h on the customer's line. Two different tests, two different questions.
Traps that cost marks
- Calling a factory acceptance test validation.
- Writing a "shall" statement with no stated verification method or tolerance.
- Leaving an interface unowned, so both parties assume the other is responsible.
- Treating a design review as verification evidence.