How Do You Approach Systems Engineering When Your Product Will Be Used in Ways You Never Designed For?
Every platform product faces this problem eventually. You design a surgical robot for endoscopic procedures in a sterile OR environment. Six months after deployment, a hospital system uses it for a workflow you never tested. You design an industrial mobile robot for flat warehouse floors with defined aisle widths. A customer deploys it in a facility with ramps, partial obstructions, and temporary workers who ignore the exclusion zones. You design an automotive platform for defined road types and weather conditions. An operator enables it in environments two standard deviations outside your test matrix.
The failure modes that follow are rarely mysterious. They are almost always traceable to one of two causes: the engineering team did not define the intended use boundary rigorously enough to make it defensible, or they defined it but did not design honestly for what happens when real users cross it.
This is not a niche concern. For autonomous systems, medical devices, industrial machinery, and any product subject to safety-case or certification processes, how you define and enforce the boundary between designed performance and foreseeable out-of-scope use is a first-order engineering problem. The standards have caught up to this reality. Your process needs to as well.
What “Intended Use” Actually Means as an Engineering Artifact
Most teams treat intended use as a marketing statement: a paragraph in the product manual that describes the canonical user doing the canonical task in the canonical environment. That framing fails in two directions. It is too vague to drive design decisions, and it provides no basis for evaluating whether a specific deployment falls inside or outside the boundary.
The engineering alternative is to treat intended use as a formal specification with the same properties you expect from any other requirement: it must be testable, traceable, and complete enough that a reviewer can determine whether a given scenario is in-scope or out-of-scope without consulting the original author.
Three structural tools make this possible.
Operational Design Domain (ODD). Developed most rigorously in autonomous vehicle standards (SAE J3016, ISO 22736, ISO 21448/SOTIF), the ODD framework defines the envelope of conditions under which a system is designed to operate correctly. An ODD is not a narrative. It is a structured set of conditions covering physical environment (surface type, grade, weather, lighting), operational context (speed range, traffic density, road type), and infrastructure requirements (lane markings, signal visibility, exclusion zones). Each parameter has a defined range. The system is designed for behavior within that range. Behavior outside that range is explicitly not guaranteed.
The ODD concept generalizes well beyond vehicles. A surgical robot’s ODD covers patient anatomy range, OR configuration, instrument types, and procedural context. An industrial robot’s ODD covers floor geometry, load range, personnel exclusion protocol, and facility environmental conditions. Medical devices routinely specify intended patient population, contraindicated conditions, and operator qualification requirements — which collectively define the same kind of structured envelope.
Use Case Coverage Matrix. An ODD defines the environment. A use case coverage matrix defines the tasks. For any platform product, there is a finite set of primary use cases the system was designed for and validated against, and a larger set of conceivable tasks the system could plausibly be asked to perform. The coverage matrix makes this explicit: which use cases were tested, at what depth, under what environmental conditions, and what performance claims are supported by that testing. Crucially, it also enumerates use cases that were considered and explicitly excluded, with a reason for each exclusion.
This is not a compliance exercise. A coverage matrix is a design communication tool. It tells the customer what they can rely on, tells the field service team where the edges are, and tells the systems engineer where to focus margin analysis.
Explicit Exclusion Requirements. This is the piece most teams skip. An exclusion requirement is a requirement that defines what the system will not do, will not be used for, or will not be deployed in — and that specifies what design or verification response supports that exclusion. For example: “The system shall not be used at ambient temperatures above 45°C. Thermal protection design shall ensure no hazardous failure mode is initiated by sustained operation at 55°C.” The exclusion defines the boundary. The design response defines what happens when someone crosses it anyway.
Exclusion requirements force honesty. They require you to ask, for each out-of-scope scenario: if a user ends up here despite our instructions, what actually happens? Is it graceful degradation, a safe failure, or a hazardous failure? If the answer is hazardous failure, you have a design problem, not just a documentation problem.
Foreseeable Misuse as a Design Input
ISO 14971, the foundational risk management standard for medical devices, is explicit on this point: the risk analysis must cover not just intended use but reasonably foreseeable misuse. The standard defines reasonably foreseeable misuse as “use of a product or system in a way not intended by the manufacturer, but which can result from readily predictable human behavior.” This is not limited to negligent or malicious behavior. It includes normal human error, reasonable but incorrect inferences about system capability, and use patterns that were not anticipated but should have been.
IEC 62368-1, the safety standard for audio/video, information, and communication technology equipment, approaches the same problem through what it calls “safeguard” analysis. The standard requires you to evaluate energy sources and their potential to cause harm, then design safeguards that account for the full population of users — including untrained users, users who ignore instructions, and users who modify the product. The underlying logic is identical: you do not get to define your way out of a hazardous failure mode by writing a warning label.
Both standards have enforcement teeth in the form of post-market requirements. ISO 14971 requires you to monitor deployed performance against your risk assumptions and update your risk analysis when those assumptions are violated. IEC 62368 requires similar systematic review. If your deployed product is being used in ways that generate incidents, the question you will face in a regulatory review or litigation is not “did your manual say not to do that?” It is “did your risk analysis anticipate this use, and what engineering response did you have?”
This changes the framing from legal protection to engineering responsibility. Foreseeable misuse is a design input. The engineering question is: given that some percentage of users will use this product in ways we did not intend, what is our designed response to each credible out-of-scope scenario?
For platform products with long deployment tails — vehicles, medical devices, industrial robots — the population of foreseeable misuse scenarios is large enough that systematic methods are necessary. Human factors engineering, failure mode enumeration, misuse testing, and structured review against use-case boundaries all contribute to an honest misuse analysis. None of them are substitutable by documentation alone.
Designing Margins for the Boundary You Defined
Once intended use boundaries are formally specified, the design question becomes: how much margin exists at the boundary, and what is the failure progression when the boundary is crossed?
Margin analysis at the intended use boundary is not the same as design margin analysis for nominal performance. For nominal performance, margin is sized to cover manufacturing variation, environmental uncertainty, and aging. For the intended use boundary, margin is sized to cover the gap between the documented boundary and the realistic worst case for deployment.
Consider a concrete example. An industrial robot is specified for flat floors with up to 2% grade. The ODD parameter is ≤2% grade. The margin question is: what happens at 3%? At 5%? Is the failure mode a control system error with graceful stop, a stability exceedance with potential tip-over, or an undetected degraded navigation state that produces unpredictable behavior? The first two are manageable. The third is the failure mode that generates field incidents and regulatory inquiries, because the system was operating in a regime where its assumptions about its own state were no longer valid.
This category of failure — where the system continues to operate but with degraded, undetected accuracy in its internal state estimation — is particularly common in autonomous systems crossing their ODD boundary. The system does not know it is outside its ODD. It continues to act on a world model that is no longer accurate. The engineering response requires both boundary detection (can the system recognize when it is outside its ODD?) and boundary behavior (what does the system do when it detects that?).
Designing for boundary detection is a systems-level requirement. It does not emerge automatically from component-level design. It requires you to enumerate the ODD parameters, identify observable signals that indicate boundary proximity or exceedance, and specify the system response — whether that is a mode transition, a safe stop, a degraded-capability mode with operator notification, or a complete handover request.
Structuring Requirements That Are Honest About the Boundary
The practical challenge for requirements engineering is that intended use boundaries involve three distinct requirement types that interact:
- Performance requirements that apply within the ODD
- Boundary detection requirements that specify how the system recognizes ODD exceedance
- Out-of-scope behavior requirements that specify what the system does when boundary conditions are detected or when out-of-scope use is foreseeable
Most requirements databases are structured around functional decomposition and performance specification. They are not naturally organized to capture the relationship between “this requirement holds within these conditions” and “this requirement applies when those conditions are exceeded.” The result is a requirements set that specifies nominal performance rigorously but leaves boundary behavior unspecified or buried in assumptions.
The modern approach — implemented well in graph-based requirements platforms — treats ODD parameters and use case boundaries as nodes in the requirements graph that other requirements link to. A performance requirement does not float free; it is linked to the ODD conditions under which it applies. A boundary detection requirement links to the ODD parameter it monitors and to the behavioral requirement that activates when the boundary is crossed. An exclusion requirement links to the design feature or verification test that demonstrates the system’s response to that excluded scenario.
Flow Engineering implements this structure through what it calls semantic requirement graphs — a model in which requirements, assumptions, conditions, and design decisions are all nodes with typed relationships between them. An intended use boundary defined as a node becomes a formal anchor: verification records attach to it, design decisions trace back to it, and when the boundary definition changes, the platform surfaces all downstream requirements that depend on that definition. For a medical device or autonomous system undergoing regulatory review, this traceability is not optional. Reviewers want to see not just what you specified, but why, and how the specification connects to your design and verification decisions. A flat document set — even a well-organized one — cannot provide that audit trail as efficiently as a connected model.
Flow Engineering’s particular strength in this context is that the boundary between what is in-scope and what is out-of-scope becomes formally queryable. You can ask: which requirements depend on ODD parameter X? Which verification tests cover the boundary condition for use case Y? Which exclusion requirements lack a linked design response? These queries surface gaps in coverage that manual review routinely misses, especially as the system evolves and boundary definitions drift relative to the verification record.
Practical Starting Points
If you are building or revising your systems engineering process for a platform product, the following sequence is operationally useful:
Start with an ODD enumeration session, not a requirements write-down. Gather the systems engineer, the safety engineer, the lead application engineer, and a field service representative. Enumerate every environmental and operational parameter the system depends on for correct behavior. For each parameter, establish the designed range, the tested range, and the known-hazardous range. These three numbers define the boundary and the margin simultaneously.
Convert each exclusion to a design question. For every use case or environmental condition you are explicitly excluding, ask: if a user ends up here anyway, what does the system do? If the answer is “we don’t know,” that is a design gap, not a documentation gap. Assign it as a requirement.
Build the coverage matrix before you build the verification plan. If you build the verification plan first, you will verify what you designed. The coverage matrix forces you to verify whether what you designed covers what you actually need to claim.
Link every performance requirement to its applicable conditions. In your requirements platform, treat ODD parameters and use case boundaries as first-class artifacts that requirements link to. If you are using a platform that supports this natively — Flow Engineering being the example most directly suited to this model — use that capability systematically, not just for high-level requirements.
Plan your post-deployment monitoring against your ODD parameters. The regulatory obligation under ISO 14971 and equivalent standards is not just to analyze misuse risk before deployment. It is to monitor whether your analysis was accurate. Define the field data you will collect and the thresholds that would trigger a risk analysis update.
The Honest Assessment
The reason platform products get used in ways they were never designed for is that they are useful. That usefulness is the goal. The engineering obligation is not to prevent all out-of-scope use — you cannot — but to define the boundary rigorously, design honestly for what happens when it is crossed, and create the formal record that connects those decisions to the product in the field.
The standards are aligned on this. The regulatory reviewers expect it. The litigation history of autonomous systems and medical devices makes it operational necessity. The teams that do this well are not the ones with the most thorough warnings in their manuals. They are the ones whose requirements set tells a coherent, connected story about what the system was designed to do, under what conditions, and what it was designed to do when reality diverged from those conditions.
That story has to be built in, not written after the fact.