How to think about a whole system, not only its parts: feedback, the V-model, and finding failures before they happen. Press play on any sketch to watch it happen.
1 Systems thinking
A system is more than its parts, and it can do things none of the parts can do alone. Systems engineering looks at the interactions between parts, which is where most surprises come from.
Boundary: decide what is inside the system and what is outside it.
Interfaces: where parts meet, and where integration problems appear.
Feedback: a system senses its own output and adjusts itself.
Emergence: behaviour that only appears when parts work together.
Control loop diagram
1/4 The target is 22 °C. The sensor reports the room is at 18 °C.
Rule of thumb: When a system misbehaves, look at the connections before you blame a part.
2 The V-model
The V-model pairs each design stage with the test that checks it. You go down the left side, breaking the system into pieces, then up the right side, proving each level works.
Left side: requirements, system design, detailed design.
Bottom: implementation.
Right side: unit, integration and acceptance testing.
Verification: did we build it right? Validation asks: did we build the right thing?
V-model diagram
1/6 Go down the left: define what the system must do.
Rule of thumb: Write the acceptance test when you write the requirement. If you cannot, the requirement is too vague.
3 Risk and failure analysis
FMEA, or Failure Mode and Effects Analysis, finds ways a system could fail before it does. Each risk gets a score, so effort goes to the worst problems first.
Severity: how bad is it if this happens? Rate it 1 to 10.
Occurrence: how likely is it? Rate it 1 to 10.
Detection: how hard is it to spot before it does harm? Rate it 1 to 10.
