A phone in your pocket does several things at once. The radio talks to a tower, the screen glows, the processor thinks, the battery pushes current through all of it, and the whole slab has to stay cool enough to hold. Every one of those parts was designed by a different team. Yet when you press a button, they agree.
Now imagine one of them quietly disagrees. One team counts in one unit, another in a different one. Nothing is wrong with any single part. Everything is wrong with the product. This subject is about that gap: not how to design a part, but how to make a hundred parts mean the same thing.
Engineers who have taken it carry a habit for life. When someone proudly shows a clever component, they ask three questions before admiring it: what does it plug into, what does it assume about its neighbours, and what happens when it is wrong?
Who takes it: final-year mechanical and aerospace engineers, usually as a capstone (a year-long team project), and in many universities every engineering major has a version of it.
What it is for: turning a pile of well-designed parts into one product that meets what someone actually needed, on a budget and a schedule.
Comes after: Machine Design (34/19), Control Systems (34/20) and Software Engineering (34/31), which is also a Computer Science subject.
Leads to: nothing on the map; it is the last stop of the Mechanical & Aerospace path. What it leads to is the job, where most of the work is this.
What this piece gives you, and what it doesn't: you won't be able to run a real programme or write a requirements document an auditor would accept. You will see why a spacecraft is weighed more often than it is admired, and why the famous failures were almost all about neighbours disagreeing.
A product is many subsystems agreeing
A system is a set of parts whose combined behaviour is something none of them can do alone. A car is not an engine plus wheels. It is an engine that must fit in the space the body left, make heat the radiator can reject, and shake at frequencies the mounts can absorb. Each sentence in that list is an agreement between two subsystems.
Systems engineers write those agreements down in two forms. A requirement says what the whole thing, or one part, must do, in a sentence a test can settle: "The device shall have a mass of no more than 12 kg." A good requirement can be checked by measuring; "lightweight" cannot. An interface says exactly what passes between two parts: the bolt pattern, the voltage and connector, the message format, the units. A document that holds these agreements is called an interface control document, and it is the most boring and most valuable thing in the project.
Most of a system's trouble is not inside the parts. It is on the lines between them.
The craft is a loop: break the whole into subsystems, give each a budget and an interface, let teams work, then bring the results back and see whether the whole still works.
The V: build down, prove up
The classic picture is a letter V. Down the left side you go from need to detail: what the customer wants, then system requirements, then the design of each subsystem, then the parts. At the bottom you build. Up the right side you test, and the key idea is that each level of testing answers to the level on the left at the same height. You test the part against the part's design, the assembled subsystem against its requirements, the whole product against the system requirements, and finally the product in real use against the original need.
That gives the two words every systems engineer uses precisely. Verification asks whether you built it right: does it meet the requirements as written? Validation asks whether you built the right thing: does it actually solve the problem the person had? A product can pass every verification and still fail validation, if the requirements were wrong. The V-model has several roots: it appeared in the late 1980s in Germany (for defence procurement) and in the United States, and it is a teaching picture, not a law. Real projects loop back and forth across it, and agile software teams (see Software Engineering, 34/31) spiral through small versions of it.
Worked example: a requirement says the part "shall have a mass of no more than 12 kg". You put it on a scale and read 11.6 kg. That is verification, and the requirement is met with 0.4 kg (about 3%) to spare. Whether anyone can lift a 12 kg part into place is a validation question, and the scale cannot answer it.
Trade studies: choosing without a perfect answer
Early in a project there are always several ways to do a job, and none is best at everything. A trade study scores each option against the criteria that matter, weights the criteria by how much they matter, and adds it up. The sum is not the point. The point is that the weights make the argument visible: two people who disagree about the answer are usually disagreeing about the weights, and now they can say so.
A small delivery robot. The scores (1 = poor, 10 = excellent) are invented for the exercise; the point is what the weights do. Drag a weight and watch the winner change.
Try it: with the starting weights, plain wheels win comfortably. Put nearly all the weight on performance over rough ground and legs edge ahead. Nobody's arithmetic changed, only what they cared about. A mature team also checks sensitivity: how far can a weight move before the winner flips? If a tiny change flips it, the study has not decided anything yet.
Budgets and margins: mass, power and heat
Hardware obeys sums. A spacecraft has a mass budget (everything added up against what the rocket can lift), a power budget (everything it draws against what the panels and battery supply) and a thermal budget (everything it dissipates against what it can radiate away). Each subsystem gets an allowance. The system engineer's job is to add them up, often, and to be suspicious of the total.
The suspicion is earned. Designs get heavier. NASA's systems engineering handbook, in an example, says spacecraft dry mass can grow by as much as 25 to 30 percent between detailed design and launch. So teams hold a margin: they add a deliberate percentage to the current best estimate, larger when the design is young and shrinking as parts are actually built and weighed. A margin is not padding. It is an honest admission of what you don't know yet.
An invented small satellite with a 500 kg launch limit. Its best estimate is the sum of the parts below. Choose how much margin you hold, then how much the design really grows.
The best estimate here is 415 kg. With 20% margin the budget reads 498 kg, comfortably under 500. Then the design grows by 25%: 415 × 1.25 = 518.75 kg, and the satellite no longer fits. The margin was not too generous; the growth was bigger than the margin. That is how real programmes learn their margins were thin, usually late.
The budgets are coupled, which is the deeper lesson. Take mass in a rocket. The rocket equation says that the ratio of liftoff mass to final mass is e raised to (Δv divided by exhaust speed). One extra kilogram of dead weight at the end therefore costs several kilograms of propellant at the start.
A stage with 1,000 kg of structure and payload that must change its speed by 4,000 m/s. The engine's specific impulse is 320 s (a good chemical engine). Add dead weight and see what it costs at the start.
At 4,000 m/s the ratio is 3.58, so each extra kilogram at the end costs 2.58 kg more propellant, and 3.58 kg of extra liftoff mass in all. Ten kilograms of "just a bracket" becomes about 36 kg on the pad. This simple model ignores that the bigger tanks weigh more too, so reality is worse. This is why aerospace engineers fight for grams.
Heat has a vacuum-sized version of the same coupling. In space a spacecraft can only get rid of heat by radiating it. The hotter and larger its radiating surface, the more it sheds, following the fourth power of temperature:
Every watt the electronics use comes out as heat. With a radiator at 300 K (27 °C), emissivity 0.85, and ignoring sunlight, how much area must it have?
At 300 K, 100 W needs about 0.26 m² of radiator. So a power decision, a few more watts for a faster computer, becomes a thermal decision (more area or a hotter radiator) and a mass decision (more structure to carry it). One number changed and three subsystems moved. That chain is what "system" means.
Interfaces are where the failures live
Two famous losses show this better than any lecture, and both are now textbook cases.
On 23 September 1999, NASA's Mars Climate Orbiter lost contact during its orbit-insertion burn. The investigation found the root cause was a failure to use metric units in a piece of ground software. A ground file that described the effect of the spacecraft's small thruster firings reported it in pound-force seconds. The navigation software that used them expected newton-seconds, as the specification said. One pound-force is 4.448 newtons, so every number was read about 4.45 times too small. The board noted that the project's own checks did not catch it: it cited a lack of complete end-to-end verification of the navigation software and models. It was meant to pass Mars at about 226 km. Calculations afterwards put it as low as about 57 km, below the roughly 80 km thought survivable.
On 4 June 1996, the first Ariane 5 rocket, flight 501, veered and broke up about 37 seconds after the launch sequence began, roughly 30 seconds after liftoff. The inquiry, chaired by Jacques-Louis Lions, traced it to the inertial reference system, which had reused software from Ariane 4. A number describing horizontal motion, held as a 64-bit floating-point value, was converted to a 16-bit signed integer. Ariane 5 flew a faster early trajectory than Ariane 4, the value no longer fitted, and the conversion raised an error that was not handled. The two redundant units had identical hardware and software, so both shut down together, and the rocket's computer then read diagnostic data as if it were real guidance. The board's lesson was not "a programmer blundered". It was that an assumption valid for the old rocket was never tested against the new one: the board reported that the new rocket's trajectory data was left out of the unit's specification, and the units were not part of the full closed-loop simulation. Three of the seven vulnerable conversions had been left unguarded on the belief that the values were physically limited, and that belief proved wrong for this one.
1. Units. Slide the real impulse. The ground file gives a number in pound-force seconds; navigation reads it as newton-seconds.
2. Range. A 16-bit signed integer holds -32,768 to 32,767. Slide the value being converted, and choose whether the conversion is guarded.
Both stories share a shape. Every part worked for the conditions it was designed for. The failure sat in an assumption between parts. Systems engineers answer this with the same few habits: write the interface down, put units and ranges in it, test the parts together as early as possible, and test with real data rather than the data you expect.
FMEA: asking how it breaks before it does
Failure mode and effects analysis, or FMEA, is a structured way of asking "how could this break, and what happens then?" It was first described in a US military procedure in 1949, and by the early 1960s NASA contractors were using versions of it on programmes such as Apollo. For each part, a team lists the ways it can fail, the effect of each, and how it could be noticed. Then they rate three things from 1 to 10: how severe the effect is, how often it will happen (occurrence), and how hard it is to detect before it hurts someone. Multiply the three and you get a risk priority number (RPN), used to rank what to fix first.
An electric scooter. The ratings are invented for the exercise. Pick a failure and move its three ratings (for detection, 10 means hardest to detect).
The starting numbers show the catch. Battery overheating while charging has the worst possible consequence (severity 10), yet its RPN of 60 ranks it third, below a loosening bolt that scores 192. That is not an arithmetic error: multiplying scales hides a very bad but rare event behind a mild but common one. Critics have said exactly this, and the 2019 joint automotive handbook of the AIAG and VDA replaced the RPN with an "action priority" table that looks at severity first. The honest use of FMEA is the conversation it forces, not the number.
Integration, test and what the capstone teaches
The right-hand side of the V is where the plan meets the world. Integration means putting the parts together a little at a time, not all at once on the last week, so a surprise is found when it is cheap. Test is the evidence: vibration tables for launch, thermal-vacuum chambers for space, wind tunnels, fatigue rigs, and for software, automated suites (see 34/31). The rule teams repeat: test as you fly, and fly as you tested.
The senior capstone is the one place most students get to feel all of this at small scale. In the US, accreditation criteria from ABET require engineering programmes to include a culminating major design experience that draws on earlier coursework and works within multiple realistic constraints, which is why almost every programme has one. A typical capstone gives a team of four to six students a real or realistic customer, a budget of a few thousand dollars, and two semesters. The lessons are rarely the equations. They are these:
- The customer's first sentence is not the requirement; asking the second question is.
- The part you assumed would be easy is the one that is late.
- The interface you did not write down is the one that does not fit.
- Your design is only done when somebody else can build, test and run it from your documents.
What a graduate just sees
- The hard part of a product is on the lines between its parts, so read the interfaces first.
- A requirement you cannot test is a wish; every requirement should say how it will be verified.
- Verification is "built it right"; validation is "built the right thing". They fail separately.
- Everything gets heavier, hotter and later than the first estimate, so hold margin and shrink it only with evidence.
- In aerospace a kilogram late in the stack costs several at the start, and a watt costs heat, area and mass.
- Redundancy that runs the same software fails the same way twice.
- Ask "how could this break?" before it does, and rank by consequence, not only by a product of scores.
- Disagreements about a design are usually disagreements about weights; make them explicit.
Where it shows up next
- Machine Design (34/19) gives the parts and their loads; this is how they become a product. Mechanics of Materials (34/11) supplies the mass you can afford to remove.
- Control Systems (34/20): a controller is a subsystem whose interface is a sensor, an actuator and a rate. A wrong sign or a wrong unit there is the Mars Climate Orbiter story with a motor.
- Heat Transfer (34/16) and Thermodynamics (34/14) are the thermal budget. Vibrations (34/17) is why launch loads decide what survives.
- Software Engineering (34/31) is the other half of nearly every modern product; the Ariane story sits exactly between them. Computer Security (34/33) is the same discipline applied to an adversary.
- In the real world: spacecraft, aircraft, cars, medical devices and phones are built this way, and in companies the job title is often "systems engineer" or "integration and test engineer".
If you want to go deeper
- 📘 Systems Engineering: Principles and Practice, Kossiakoff, Seymour, Flanigan and Biemer (Wiley, 3rd ed., 2020): the standard university textbook for the whole subject.
- 📘 Product Design and Development, Ulrich, Eppinger and Yang (McGraw-Hill, 7th ed., 2020): a common capstone text on turning a need into a product.
- 🌐 NASA Systems Engineering Handbook: free to download from NASA, and the best-known practical reference.
- 📘 To Engineer Is Human: The Role of Failure in Successful Design, Henry Petroski (1985): a gentle, readable book on why things fail and what designers learn.
- 🌐 MIT OpenCourseWare 16.842, Fundamentals of Systems Engineering (Prof. Olivier de Weck): free and complete, though a graduate-level course, so expect it to be dense.
A product is many subsystems agreeing. Systems engineering is the discipline of writing the agreements down (requirements and interfaces), proving them level by level (the V, verification and validation), spending scarce mass, power and heat honestly (budgets and margins), and hunting the ways it can break (FMEA). The big failures were not exotic physics. They were two neighbours with different assumptions.
Try this: pick something in your home with two or more parts that must work together, such as a phone and its charger, or a door and its lock. Write down three things the one part assumes about the other. Which assumption would be most expensive if it were wrong?
Sources. Mars Climate Orbiter: NASA press release of 10 November 1999 on the Mishap Investigation Board's Phase I report; Wikipedia, "Mars Climate Orbiter". Ariane 5 flight 501: the Inquiry Board report of 19 July 1996 (chair Jacques-Louis Lions); Wikipedia, "Ariane flight V88". V-model and verification versus validation: Wikipedia, "V-model". FMEA history and the move to action priority: Wikipedia, "Failure mode and effects analysis". Dry-mass growth of 25 to 30 percent: NASA Systems Engineering Handbook SP-6105 (1995), p. 62, as quoted in a project document. Accreditation: ABET Criterion 5. Computed in node: rocket-equation ratio 3.577, radiator area 0.256 m², the mass-budget sums, trade-study scores and RPN products.
- 🌐 NASA Systems Engineering Handbook
- 🌐 MIT OpenCourseWare 16.842: Fundamentals of Systems Engineering
- 🌐 NASA: Mars Climate Orbiter Phase I report press release
- 🌐 Ariane 501 Inquiry Board report (mirror)
- 📘 To Engineer Is Human, Henry Petroski