Problem Frames Approach¶

The problem frames approach specifies a machine through its interfaces with world domains so that domain properties and machine behavior jointly satisfy a world-level requirement.

Version: v2 · 2026-10-03 · History
Domain-specific #: 13519
Domain group: Applied Sciences & Engineering
Origin domain: Computer Science & Software Engineering
Subdomain: Requirements Engineering → Computer Science & Software Engineering
Aliases: Problem frames

Core Idea¶

Michael Jackson's problem frames approach begins outside the software. A customer wants some property of a part of the world to hold; a machine to be built can interact with that world only through specified shared phenomena. The analyst therefore distinguishes the requirement R (what must be true of the problem world), the domain properties D (what is already true about physical, human or informational domains), and the machine specification S (the machine's required behavior at its interfaces). The solution argument is S, D ⇒ R. Writing correct code for S is insufficient if the assumed domain properties fail or if R was misplaced inside the machine.^[1]

A problem frame is a recognizable shape of this arrangement, with a characteristic concern: can a controller actually impose a world behavior, or can an information machine infer the world state it must display? Jackson's original MIT lecture works both a sluice-gate controller and a car odometer/speedometer display. An airport-arrivals display could illustrate the genre, but it is not the source-located case here; the odometer is the author's actual example.^[1]^[2]

Structural Signature¶

Sig role-phrases:

Machine to be specified: the controller, editor, transformer or display computer whose behavior is under design.
Problem-world domains: given physical, human or lexical parts of the world with properties not defined by the software alone.
Shared/interface phenomena: observable or controllable events and states at machine–domain boundaries, noting which domain controls them.
World requirement: the desired effect on the world, not a mere instruction to emit a command.
Frame concern and solution argument: the problem-class-specific question that makes S, D ⇒ R credible, followed by composition checks when subproblems interact.^[1]^[2]

The diagram is not decorative. Its edges say what the machine can know or cause; a requirement attached to phenomena beyond those edges demands an inference or control argument. Jackson distinguishes causal domains (physical behavior), lexical domains (stored symbolic material), and biddable domains (people who can be requested but not physically compelled). The type affects what may safely be assumed.^[1]^[2]

What It Is Not¶

This is not the AI “frame problem” of representing what remains unchanged after actions, nor a software architecture diagram showing modules to implement. It is also not just a requirement list or a use-case picture. The analytical center is the interface between machine and non-machine domains, and the proof obligation that interface behavior under domain assumptions achieves a world-level requirement. A program could send Open at the right time yet fail to hold a gate open if the motor or sensors do not behave as assumed.^[1]

The frame names are classes, not a claim every real project fits one elementary diagram. Jackson's lecture lists simple behavior, simple information, workpieces and transformation instances, and then decomposes a package-router problem into different subproblems. Decomposition does not abolish composition issues: shared phenomena and concurrent demands must be reconciled. A frame can expose a missing assumption, but it does not mechanically prove the whole system safe or correct.^[1]^[2]

Scope of Application¶

For physical control, the method asks whether the machine has the right actuators and timely sensor information to impose a requirement on an autonomous causal domain. In the lecture's sluice-gate case, a controller sends clockwise, anticlockwise, on and off motor pulses; the gate/motor supplies top and bottom indications. The customer wants the gate fully open for ten minutes of each three-hour period and otherwise fully shut. The pulses and indications are interface phenomena, while open/shut position is the requirement's world-level subject. The frame concern is a valid control law connecting them.^[1]

For information display, the problem is not to control the car's motion but to infer something about it. The odometer microchip receives a rear-wheel rotation pulse, estimates speed and cumulative distance using assumptions about wheel behavior, then commands visible speed and distance counters. The desired information concerns travel, whereas the machine directly sees pulses and manipulates display registers. Jackson describes this as a simple information frame; an untimely or unreliable observation may require remembering or modeling the world separately.^[1]

Clarity¶

In the sluice example, Top is a sensor state, not the customer's sentence “the gate is fully open.” The two can be related by a domain assumption about sensor placement and gate mechanics. If the sensor sticks, a specification that merely reacts to Top cannot establish the physical requirement. This separation makes a hidden assumption testable. The lecture's notation marks controller-controlled motor events and motor-controlled sensor states separately, rather than conflating both as software variables.^[1]

In the odometer example, a wheel pulse is not itself a vehicle speed reading. A rate of pulses over time, wheel circumference and possible slip inform an inference about speed and cumulative distance; the machine then sets counters. The source states the basic pulse-to-display problem, and the circumference/slip remarks are explicit engineering implications, not asserted measured facts of Jackson's slide. The requirement remains that the displayed state correspond to actual travel, not merely that the microchip emit increment commands.^[1]

Manages Complexity¶

The approach partitions what can be specified from what must be assumed or learned. The machine's output pulses are under its control; the motor's mechanical response is a property of a causal domain. The odometer's counter commands are under the machine, but actual travel is autonomous. Marking control at each interface prevents the common error of solving the program while leaving the world problem unsolved.^[1]

Frames also give a disciplined decomposition. The sluice gate is a control problem, the odometer an information problem, and a package router in Jackson's longer lecture requires control plus misrouting display subproblems. Each has a local frame concern; their specifications then must compose without inconsistent assumptions or interference. The original paper abstract likewise emphasizes recognized subproblem classes and separate composition concerns. The method manages complexity by postponing combination until the parts' obligations are clear, not by pretending combination is automatic.^[1]^[2]

Abstract Reasoning¶

Identify the desired world phenomenon first. Then draw the machine and all relevant domains, label interfaces by phenomena and by which side controls them. State R only with world phenomena, S with machine-visible and machine-controlled phenomena, and D with domain properties that can bridge them. Ask whether S ∧ D entails R; if not, find which sensor, actuator, model or assumption is missing. In a required-behavior frame this is a control-law question; in an information frame it is an inference question.^[1]

For sluice control, the implication could fail if the motor does not move when commanded or the sensor signal arrives too late. For the odometer, it could fail if wheel pulses do not faithfully encode distance. Those are not afterthoughts about implementation quality; they identify premises in the world-to-machine argument. The general method does not promise that all premises hold, only makes them available for analysis and validation.^[1]

Knowledge Transfer¶

The machine/domain/interface/requirement skeleton transfers from irrigation control to vehicle display, but the frame concern changes. The gate example asks how to cause and maintain a position; the odometer asks how to infer and show an autonomous world condition. Copying a control-law solution into an information problem would miss the estimation step; copying an information-display argument into a control problem would not actuate the gate. Transfer is recognition of structure plus renewed proof, not the reuse of a diagram name.^[1]

Within a larger project, a single domain may appear in multiple frame decompositions. Jackson's package router example separates required routing behavior, commanded conveyor behavior and reporting of misroutings. One must later test whether their local specifications can coexist. The decomposition transfers a problem-solving discipline; it does not license treating subproblems as physically isolated systems.^[1]^[2]

Examples¶

Sluice-gate control in Jackson's lecture¶

The original 2002 MIT slides specify an irrigation gate that must be fully open for ten minutes every three hours and otherwise shut. A small motor moves it in response to clockwise, anticlockwise, on and off pulses; top and bottom sensors provide position indications. Jackson's diagram distinguishes those machine/motor interface phenomena from the open/shut phenomena mentioned in the requirement. The simple-behavior frame asks whether a controller can find a control law, given the motor's properties and timely information, to enforce the regime.^[1]

Mapped back: the sluice controller is the machine to be specified; gate and motor are the problem-world causal domain; motor pulses and top/bottom states are shared/interface phenomena with separate controllers; the ten-minute open/otherwise shut regime is the world requirement; the control-law and timely-information test is the frame concern and solution argument. Merely sending On is not the same as proving Open.

Odometer and speed display in Jackson's lecture¶

Jackson's second source-located diagram describes a car's rear-wheel pulse generator, odometer microchip and visible fascia counters. The microchip detects pulses and sets a current-speed counter and total-distance counter. The simple-information frame asks how the machine can infer speed and cumulative travel from pulses and known domain behavior, then make the display correspond to those world quantities. The car's travel is autonomous relative to the display machine; the counters are not travel itself.^[1]

Mapped back: the odometer microchip is the machine to be specified; car travel and fascia counters are problem-world domains; wheel pulses and counter-update signals are shared/interface phenomena; correct displayed speed and cumulative distance are the world requirement; pulse-to-travel inference and display correspondence are the frame concern and solution argument. Changing the pulse calibration would require revisiting the domain premise, not simply renaming the counter.

Structural Tensions¶

No universal intrinsic two-sided cost is established for the problem frames method by these sources. The lecture identifies control reliability, untimely information and subproblem composition as concerns to resolve, not unavoidable benefits that must be traded for harms. Decomposition can aid understanding, yet composition can fail; that is a proof obligation, not by itself a demonstrated theorem that more decomposition necessarily worsens integration. The appropriate section-level conclusion is therefore a precise absence of a supported intrinsic tension, with missing assumptions treated as diagnostics in the method itself.^[1]^[2]

Structural–Framed Character¶

Problem frames is strongly structural in method: diagrams identify typed domains and shared phenomena, and S, D ⇒ R expresses a solution obligation. Its evaluative weight enters through the stakeholder's chosen R: what counts as acceptable gate timing or accurate display is a human requirement. It depends on human engineering practice to classify domains, select boundaries and validate assumptions; even “biddable” human behavior is not mechanically guaranteed. The vocabulary originated in Jackson's software requirements research and teaching, also represented by his separately published book, not in every generic use of “frame.” It travels between physical control and information systems because the machine/world distinction can be reidentified, but an imported frame is recognition only after the local phenomena and concern fit. Calling an arbitrary UI mockup a problem frame without a world requirement and domain argument is false import. Its character: a formalized, practice-dependent method for reasoning from software interfaces to desired world effects.^[1]^[2]^[3]

Structural Core vs. Domain Accent¶

The skeletal relation is machine interface specification + given domain properties ⇒ world-level requirement, refined by a recognized problem class and its concern. Sluice motors and wheel pulses are accents. The domain-bound mechanism is requirements engineering: software is designed, world behavior is partially given, and shared phenomena limit what the software can establish. The named entry fails the prime bar because abstracting it to “solve a problem using context” loses the machine/domain split and S,D⇒R test. It presupposes the live Problem Framing prime, but is not coextensive with a generic framing act. A portable context-to-requirement principle would need independently verified unlike systems and a sharper discriminating invariant.

This entry presupposes Problem Framing.

Strict compositional prerequisite: Problem Framing (presupposes, strict). Jackson's method needs a delineated world requirement, machine boundary and interface before the S,D⇒R argument can be made; ordinary problem framing need not use Jackson's machinery. This is not a subsumption claim. The AI “frame problem” remains a different identity,.

Relationships to Other Abstractions¶

Current abstraction Problem Frames Approach Domain-specific

Parents (1) — more general patterns this builds on

Problem Frames Approach presupposes Problem Framing Prime

Problem frames presuppose a delineated problem and machine/world boundary.

Hierarchy paths (2) — routes to 2 parentless roots

Problem Frames Approach → Problem Framing → Representation → Abstraction

Show alternative path (1)

Neighborhood in Abstraction Space¶

Problem Frames Approach sits in a sparse region of the domain-specific corpus (72^nd percentile for distinctiveness): few abstractions share its structure, so a faithful description tends to retrieve it precisely.

Family — Software & Systems Architecture (29 abstractions)

Nearest neighbors

Computed from structural-signature embeddings · 2026-10-08

Not to Be Confused With¶

Do not confuse a world requirement with a machine interface specification, a sensor indication with the physical state it indicates, or a software module diagram with a problem diagram. Causal domains do not obey software commands by definition; biddable people can choose how to respond; lexical domains are representational material rather than physical actuators. An airport display is not claimed to occur in Jackson's inspected original lecture; the source-located information case here is the odometer.^[1]^[2]

References¶

[1] Jackson, Michael. “Problem Frames: A Lecture,” MIT 6.898, 6 March 2002. Original author-authored lecture slides hosted by MIT CSAIL; especially slides 9–25 and package-router decomposition slides 31–40: https://people.csail.mit.edu/dnj/teaching/6898/lecture-notes/session8/slides/mj-problem-frames.pdf . registry ↩a ↩b ↩c ↩d ↩e ↩f ↩g ↩h ↩i ↩j ↩k ↩l ↩m ↩n ↩o ↩p ↩q ↩r ↩s ↩t ↩u

[2] Jackson, Michael. “Problem Analysis and Structure” (2001). Original author-uploaded abstract and figures: https://www.researchgate.net/publication/244439281_Problem_Analysis_and_Structure . Full paper not relied on for detailed slide claims. registry ↩a ↩b ↩c ↩d ↩e ↩f ↩g ↩h ↩i

[3] Jackson, Michael. Problem Frames: Analysing & Structuring Software Development Problems (2001), separate book publication; publisher record used only for bibliographic provenance, not for the lecture's worked examples. registry ↩