Model-Based Systems Engineering and Requirements Definition

Dennis Hansen brings over six decades of systems engineering experience to this GOTO Book Club conversation — from Air Force airborne navigation technician to Chief Systems Engineer at L3Harris on programs including the complete rebuild of the GOES-R ground system for NOAA and NASA. His book argues that the fundamental failure mode in complex system development is the same every time: requirements are defined too loosely, too late, or across multiple model layers simultaneously. He structures the approach using an onion model — a layering framework he was taught by a Motorola engineer in 1961 — where each layer (mission, capabilities, activities, technical requirements, specifications) must be completed before the next is begun. Skipping layers or trying to do two at once invariably produces excess or faulty requirements that surface as expensive failures during system testing, or worse, after deployment.

The second half of the conversation focuses on why modeling tools are databases, not drawing programs — a distinction Dennis considers critical. Every element in the model carries its associated requirements and the reasoning behind design decisions, which means that when you return to work after a weekend, you don't lose hours reconstructing your thinking. More importantly, when change requests arrive — and they always do — a maintained model lets you trace the impact backwards through the system and understand exactly what has to be modified, rather than slapping on a fix that creates five new problems. Dennis's closing advice is the thread that runs through the entire book: collaborate at every stage, every discipline working together rather than in silos, and define things properly upfront. Everything else follows from that.