Welcome to chapter nineteen. This chapter is about one transformation: turning "it seems to work" into an explicit question, a reproducible test, a recorded result including the failures, and an honest account of what is still unknown. That transformation is most of what separates a professional engineering culture from an enthusiastic one. Whatever you build with, whether it is machined, sewn, moulded, wired or written, the habits in this chapter are what make your work legible to the people who will have to trust it.
None of what follows is bureaucracy for its own sake. Every element exists because somebody was harmed by its absence. A requirement nobody wrote down, and so nobody checked. A hazard that was obvious in hindsight. A test result carried forward to a version of the object it was never obtained on. A prototype that met every dimension on its drawing and was still unusable. Keep those four failures in mind; each tool in this chapter is the answer to one of them.
Before any requirement can be written, three things must be stated, because they constrain everything else. The intended use: what the thing is for, in one sentence, including what it is not for. For the elbow model that means a tabletop teaching aid demonstrating flexion and the role of a tendon, not for attachment to a person, not for clinical use, and not for bearing load. The intended users: who operates it, their training, how often, and with what capabilities. And the use environment: lighting, noise, interruptions, gloves, wet hands, the space available, the time available, and where it is stored. Leaving these implicit is the commonest cause of a design that is right for a situation nobody is in.
Include the unglamorous conditions. A device is used by real people in real conditions, not by an attentive expert in a quiet room. Think of interruptions, a cluttered surface, gloved hands, poor lighting, someone else needing the trolley, and a user who has done this nine times today and is no longer reading the label. And include reasonably foreseeable misuse. Not deliberate abuse, but the predictable kind. If a part can be assembled backwards, someone will assemble it backwards. If a cord can be pulled hard, someone will pull it hard. The question is never whose fault that is. It is whether your design tolerates it.
Now the core skill: turning adjectives into requirements you can actually check.
"Easy to use", "durable", "robust" and "intuitive" are conversation starters, and none of them can be checked. A usable requirement states who does what, under what conditions, to what criterion, and the criterion is agreed before the test with the person who cares about it. "Easy to reset" becomes: after one demonstration, the intended educator can restore the starting position without tools. "Washable" for a sewn strap becomes: after fifty cycles of the laundry's actual programme, no seam has separated and the fastening still holds its test load. "Reliable" for firmware becomes: after power is lost at any point, the device restarts into a defined safe state. And "safe" is not a requirement at all. It has to be broken down into specific hazards and controls, which is where we go next.
A warning. Do not select numbers because they are convenient to pass. Choosing ten cycles because you are fairly sure it will manage ten is not a requirement; it is a formality dressed up as evidence. The number should come from the intended use. How many times will it actually be handled in a term? And it should be agreed with the person who will rely on it. If no principled number is available, say so plainly, like the sentence on this slide. An honest statement of an exploratory check is far more valuable than a fabricated justification.
Next, hazards, and the chain of reasoning that the medical device risk standard uses.
The international standard for medical device risk management, ISO fourteen nine seven one, uses a chain worth adopting whatever you build. A hazard is a potential source of harm, such as an exposed moving gap. A sequence of events has to happen, like a learner holding the model there while someone else operates it. That produces a hazardous situation, a finger in the gap, and finally harm, a pinch injury. The chain matters because it shows three places to act. You can remove the hazard, prevent the sequence of events, or reduce the severity if harm does occur. A warning label acts only at the weakest point in that chain.
Controls come in a ranked order. First, inherently safe design: eliminate the hazard, for example by changing the geometry so no pinch gap exists anywhere in the travel. Second, protective measures: a guard, an interlock, a mechanical stop, or a cord that detaches at a low force rather than transmitting a jerk. Third, information for safety: labels, instructions and training. The label is necessary, and it is the least effective, because it depends on someone reading, remembering and complying. The order is not a preference, it is an effectiveness ranking. It is the same principle as the asymmetric connector from chapter seven: make the wrong thing impossible rather than labelling it as wrong.
This is the part people miss. Adding a guard is a design change, and design changes have consequences. Does the guard hide the anatomy the model exists to show? For a teaching aid that might defeat the purpose entirely. Does it obstruct the reset, making a different requirement fail? Can it loosen in use and become a new hazard of its own? Does it create a crevice that cannot be cleaned? Does it add mass at the end of a moving part? So implement the control, then re-test everything the change could have affected. A control does not end the discussion. It opens a new one.
For a teaching aid, the most likely harm is not a pinch. It is teaching something false. A cord labelled ambiguously produces learners who believe tendons contract, and that belief then shapes how they understand injury, rehabilitation, and every later explanation they hear. The harm is educational, delayed and invisible at the bench, and it belongs in your hazard analysis alongside the physical ones. The same logic applies to software: a misleading display, a value whose staleness is not shown, or a label that implies a clinical judgement you were not qualified to make.
Here is what a lightweight hazard table looks like for the elbow model. Each row runs from hazard, through the situation where someone is exposed, to the harm, and ends with a control and how you will check that the control actually works. Notice the last column always says how effectiveness is verified, by measuring the gap at every point of travel, not just at rest, or by asking unfamiliar learners to explain the model back. On probability: formal risk management combines severity and probability, but for a learning project, do not invent numbers you cannot support. Rank by judgement, say it is judgement, and spend your effort on controls and verification.
Now testing. The rule is simple: a test answers one question.
A test that answers five questions badly is worse than three tests that each answer one. Every test record should name the exact version tested, the single question, and the requirement with its acceptance criterion, agreed before the test. Then the setup and procedure in enough detail that someone else could repeat it. Then the result, including everything unexpected. The conclusion is stated narrowly. The limits say what the result does not establish. And the action says what changes and what must be re-tested as a consequence. Write the first half of the record before you start.
An invented example. You set a target of ten consecutive tool-free resets, and on attempt seven the cord slips out of its guide. The honest record is: failed at attempt seven of ten, cord slipped from the guide, guide retention needs revision. "Worked six times" is true and misleading, because it drops the criterion and the failure. "Mostly successful" is not a result at all. "Passed after fixing the guide" conflates two different versions of the object. And "ten out of ten after retest" is only acceptable if that retest really happened on the new version and is recorded as its own entry.
This is the single most common documentation failure, in amateur and professional work alike. The old result applied to the old object. When you revise the cord guide, ask what else the change affects. Does it alter the cord's line of action, and so the motion and the force? Does it create a crevice that complicates cleaning? Does it hide the force path the model exists to teach? Each of those may be a test that needs repeating. A test record that cannot be tied to a specific version is not a test record.
Two words that are often confused. Verification asks: did we build the thing right? It confirms that an output meets its specified requirements, by measurement, inspection and test. Validation asks: did we build the right thing? It confirms that the result meets user needs in its intended use, with representative users doing the real task. Each has its own failure mode. An object can meet every dimension and be unusable, and users can love an object that misses a requirement that matters. And be honest about scale. Handing the model to a colleague who likes it is an informal tryout. It is useful. It is not validation. Call it by its real name.
Traceability ties it all together. Every requirement should trace back to a need and forward to evidence. Here, the need is that learners confuse force generation with transmission. That derives a requirement that an unfamiliar learner can say which element is which, unprompted. A design feature satisfies it, verification checks the labels are present and durable, validation asks real learners, and both feed a dated, versioned record. If a requirement traces to no need, ask why it exists. If it traces to no evidence, it is only an intention.
Software people version by instinct; physical makers often do not. The rule is the same: a version is a configuration you can reproduce. Record an identifier on the object itself that survives cleaning, the design files with their revision, the materials down to grade and batch, and the process settings for every process used: the CNC program, the laser settings, the print profile, the casting cure schedule, the stitch, the weld procedure, and the firmware actually flashed. Put the whole project in version control and the tag on the object's label. A photograph is useful, but you cannot reconstruct a cure schedule or a firmware build from a photograph.
You are not implementing a quality management system for a teaching model, but knowing its shape tells you which habits transfer. Design controls structure inputs, outputs, review, verification, validation and transfer. The design history file is the accumulated record, and your project portfolio is one in miniature. The risk management file maintains the hazard analysis for the product's whole life. Usability engineering, software lifecycle, biological evaluation and electrical safety each have their own standard, and post-market surveillance means development does not end at launch. The useful insight is the shape: every element pairs an intention with a record. That habit costs nothing to adopt today.
Each way of making things has its characteristic failures, and each deserves a line in the hazard table and a test. For software: synthetic data, units carried in the type system, no-data kept distinct from zero, rejected rather than silently clamped inputs, and the version visible in the interface. For electronics: low-voltage battery power, protected cells, a defined safe state on fault, and nothing connected to a person. For metal: burrs removed, welds proof-tested and the grade recorded. For moulded and cast parts: lot and cure recorded and voids inspected. For fabrics: seam strength after the real laundering process. For glass and clear plastics: edges, breakage, and stress cracking from cleaning agents.
A worked example with three requirements. The cord pull demonstrates visible flexion. That establishes that the motion occurs and that the educator accepts the labelling, but not that every joint mechanic is represented or that learners interpret it correctly. The model can be reset without tools. That establishes that this educator could do it on this occasion, not that every user can, or that it stays true with wear. The version label is readable after the handling trial. That establishes legibility after that handling, not survival of a cleaning process you have not yet run. Notice the pattern. What a test establishes is always narrower than you hoped. That is what honest evidence looks like.
For the exercises: take three vague words about your project, such as strong, clear and easy, and rewrite each as a question that could lead to a requirement, then agree one full requirement before testing. Build a hazard table with at least five rows, including one non-physical harm, and a control at the highest feasible level for each. Write a complete test record before you test, then run it and fill in the result, including the unexpected. Change one thing on purpose and find every earlier test it could invalidate. And try to rebuild a tested configuration from your records alone, noting everything you had to remember rather than read.
Finally, the limits. Learning the shape of ISO fourteen nine seven one does not mean your project complies with it; that takes competence, resources and an organisation. A bench test characterises an object under conditions you chose; it is not clinical evidence. An informal tryout is not validation, so say what you actually did. Whether the project proceeds is decided by the sponsor and the institution; your job is to give them an accurate picture, including the parts that do not flatter your work. And a ranking by judgement should never be dressed up as a calculation. Next, health data, medical software, and security.