Three questions, one drawing
Most boundary arguments are three arguments wearing one marker pen. The CPRE Foundation Level syllabus (English v3.2.0) and the glossary (v2.2.0) keep system, context, and scope distinct. In a meeting they collapse because the whiteboard only has one rectangle.
Draw three lines, in that order, and the fight gets quieter. This piece is a visual essay: the drawings lead, the prose interpolates. Zoom when a label is too small. Toggle layers when you want the same picture to tell a second truth.
The system boundary says what is in the system under consideration.
The system boundary is not a compliment. It is a claim about what you will specify as this system. Neighbouring systems sit outside it even if your organisation owns them. A ledger you must not change is still a neighbour. Putting it inside the rectangle "because we own it" is how you inherit a rewrite you did not staff.
The context boundary says which neighbours and actors interact with that system.
Context is larger than the system. It includes the people and adjacent systems that exchange information or material with it. It does not include the rest of the universe. "Irrelevant" is a legitimate zone: things that exist but do not interact. The Foundation Level cares about this because elicitation without a context boundary is an unbounded interview list.
Scope says which of those neighbours this change is allowed to touch.
Scope is a project decision, not a property of the current system. You can leave the ledger inside the context and still put it out of scope for this release. That is not a contradiction. It is the difference between "it interacts" and "we may change it".
System
Context
Scope
The three-up is the meeting handout. At a phone width it stacks. At a desktop width it must be large enough to read the labels; that is why this gallery is on the full track, not squeezed into the measure.
One picture, three overlays
The same estate, three claims
Toggle the layers. The base claim is the system under consideration. Context adds the neighbours that interact. Scope is the political overlay: which of those neighbours this change may touch. If JavaScript never runs, each layer is still printed as its own figure so the argument survives.
- System. Name the system under consideration, not the programme and not the company.
- Capability. A visible behaviour or quality, not a slogan.
- Measure. A scale and a target. Without this you are still in conversation.
- Condition. When the statement applies, and for whom.
The template is not a boundary drawing. It is here because boundary mistakes show up as empty slots: a capability with no system, a measure with no condition. Hotspots are numbered so a printout still works.
Move the same elements between the lines
The explorer below is a local visual. Nothing is stored. Use the buttons to look at the same elements as system, as context, and as in-scope or out-of-scope for the change.
Move between the three boundaries
| Label | Zone | Scope | Requirement |
|---|---|---|---|
| Online register | system | in | This change specifies the register. |
| Existing ledger | system | out | Reuse the ledger unchanged. |
| Clerk | context | in | The clerk searches and exports. |
| Finance batch | context | out | Keep the existing SFTP pick-up. |
| Canteen till | irrelevant | out |
Why meetings fight
People argue as if there were one line. An architect defends the system boundary because a neighbour looks expensive to touch. A product owner defends scope because the release calendar cannot absorb the neighbour. An analyst defends context because elicitation has to include the clerk who will actually search. All three can be right. They are not answering the same question.
The Foundation Level does not grade your marker-pen technique. It does require that you can tell a system from its context. Scope, in the sense used here, is the project overlay practitioners add so that "in context" does not silently become "in this release". If you use another word for that overlay, use it consistently. Do not let it collapse into the rectangle.
A useful close to the meeting is three sentences, written where everyone can see them:
- The system under consideration is …
- The neighbours that interact with it are …
- This change may touch … and must not touch …
If you cannot finish those sentences, you are not ready to write quality requirements for the search, or constraints for the ledger. You are still choosing the picture.
Three lines
1
System under consideration
n
Neighbours in context
k
Neighbours in scope
k is never automatically equal to n. That is the whole essay.
A note on language in the room
The words that collapse the three lines are ordinary: "the system", "in scope", "stakeholders", "integration". Each of them can be used honestly. Each of them can also be used to skip a line. "The system" sometimes means the software, sometimes the organisation, sometimes the change. "In scope" sometimes means in the system, sometimes in this release, sometimes "someone important mentioned it". "Stakeholders" sometimes means the people who interact with the system, sometimes the people who signed a document, sometimes the people in the room. "Integration" sometimes means a neighbour in context, sometimes a work item in scope.
You do not need a glossary recitation in every workshop. You need one person who is allowed to ask which meaning is in play before the drawing is declared agreed. If that question is treated as pedantry, the drawing will be agreed and the programme will still argue. The pedantry is the cheap version of the argument.
When you write the three sentences after the meeting, read them aloud to someone who was not there. If they cannot tell which line is which, the sentences are still slogans. Rewrite until a stranger can place a new box on the correct line. That is the test. The visual essay on this page is only useful if those sentences exist. Pictures without sentences are how one rectangle gets three audiences.
What happens if you only draw one line
A single rectangle on a whiteboard is a social object. People gather around it because it looks like a decision. It is usually three decisions compressed until they can be mistaken for one. The architect hears "what is the system?" The product owner hears "what can we ship?" The analyst hears "who do I still have to talk to?" Each leaves the room believing they won, because each heard their own question answered.
Six weeks later the ledger change appears in a sprint board. The architect says it was never inside the system. The product owner says it was on the drawing. The analyst says the clerk described a workaround that only works if the ledger batch is retimed. All three are describing the same afternoon. They are not describing the same line.
The cost is not theoretical. Context interviews that were never bounded will still be demanded, because the clerk is real. Scope that was never written will still be assumed, because the drawing included the ledger box. System boundary that was never named will still be enforced, because the team that owns the ledger will not absorb an unfunded rewrite. You will then hold a second meeting to "clarify the original alignment". That meeting is this article, held too late, without the three sentences.
A milder failure is the opposite: drawing three lines and then treating them as theatre. The labels exist, the sentences were written, and the next workshop still talks as if in-context means in-scope. The overlay has to be used. When a new neighbour appears, ask which line it belongs on first. Do not ask whether it is "important". Importance is how all three lines get painted the same colour.
There is also a documentation failure that looks like sophistication. A context diagram is published with every corporate system on it, because completeness feels professional. The Foundation Level idea of context is not a map of the enterprise. It is the set of neighbours that interact with the system under consideration. Extra boxes are not extra safety. They are extra arguments you cannot staff. Put genuinely irrelevant systems in an "irrelevant" zone or leave them off. Either choice is more honest than a hairball.
If you need a physical practice for the next workshop, use three colours and refuse to let anyone change colour without saying which question they are answering. It feels childish. It is less childish than a programme that discovers, at integration test, that the ledger was always a neighbour and never a work item.
The explorer and the layered diagram on this page are the same lesson in two machines. One is a set of points you can filter. One is a set of pictures you can overlay. Both are useless if the meeting still only has one rectangle. Draw the three lines. Write the three sentences. Then, and only then, argue about the search quality target.
If you facilitate the next workshop, put the three sentences on the wall before anyone is allowed to draw. Drawing first invites the social object. Sentences first force the questions. When a new box appears, refuse to place it until someone says which sentence it answers. If two sentences claim it, you have found a real conflict, which is cheaper on a wall than in a release. The gallery on this page is the same three pictures at a readable size: system, context, scope. If they look similar, that is the problem the meeting was papering over. They are not similar. They answer different questions, and only one of them is a work item.