Scope Modelling

Goal

The scope model exists to settle, before any elicitation work, what falls within the analysis and what does not. It draws a boundary and attaches a judgement to it: every process, every actor, every system and every piece of data is declared inside or outside, with the criterion that justifies that placement. From this boundary follow three decisions that nothing else supplies as early. It sets a contractual and estimation baseline: effort is costed and obligations are written only against a settled scope. It settles boundary disputes: the question "is this in scope?" is decided against written criteria rather than the opinion of the day. It measures completeness: setting the requirements gathered against the declared scope reveals the forgotten zones and the overruns.

The deliverable combines three forms: one or more diagrams of the relationships between elements, one or more dependency matrices and a text that states the elements retained, the inclusion criteria and the critical assumptions on which the boundary rests. Described by phases when delivery is phased, it carries one boundary per phase.

Usage

When to use it

• Start of an initiative: fix the boundary before eliciting requirements, so in-scope decisions have a basis.
• Framing a contract or a mandate: give a defensible line for obligations, estimation and change control.
• Recurring boundary disputes: a shared model settles "is this in scope?" against written criteria.
• Multi-party or cross-organisation change: name the units, systems and external agents the change touches.
• Phased or iterative delivery: describe the scope by phase, so each increment carries its own boundary.

When not to use it

• Boundary already fixed and stable: on a small, well-understood change a one-line scope statement is enough, the full model is overhead.
• The difficulty is decomposition: use functional decomposition to open the inside into parts.
• A horizon-like boundary that shifts with the stakeholder's vantage point: a static model misleads, prefer adaptive milestone-based planning.

Two axes of classification

A scope model sits on two independent axes. The first axis states what the boundary shows. Seen from the inside, it displays the elements it contains; seen from the outside, it displays the elements it excludes; seen from both sides, it carries elements on either side. Each of these views has a proven form of artifact.

The second axis, independent of the first, states which scope the model illuminates. The control scope delimits what is analysed, the roles and responsibilities and what is internal or external to the organisation. The need scope frames the stakeholders' needs, the value to deliver and the units to explore. The solution scope covers the requirements satisfied, the value delivered and the impact of the change. The change scope lists the actions to carry out, the stakeholders affected and the events to bring about or to prevent. A single diagram belongs to both axes: it is seen from one side and illuminates one scope. The two readings combine.

Choosing the model and its form

The choice of notation follows from what the boundary has to show. When the point is to state what stays outside, the context diagram is the tool: it sets the system as a single process at the centre, surrounds it with the external entities that talk to it and draws only the flows that cross the boundary. It is the most economical form of a scope and the top level of a set of data flow diagrams. When the point is instead to detail what lies inside, functional decomposition opens the inside into functions and sub-functions. When the boundary must show both sides at once, the use-case model places the actors outside and the use cases inside, in a box that stands for the system. The Venn diagram, for its part, sets two sets and their intersection against each other.

Each of these representations is doubled by the two other forms of result. The text describes the elements and, above all, the criteria that make an in-scope decision defensible. The matrix exposes the dependencies between scope elements, those a diagram leaves in the shadows. A complete scope model combines the three, to the measure of the decision it serves.

The relationships to explore

Checking that a scope is complete comes down to exploring the relationships between its elements, because a forgotten dependency hides a forgotten element. Five families of relationship are worth exploring, each tied to a family of diagrams. The parent-child relationship decomposes an element into its parts, through an organisation chart, sub-processes or a data model. The function-responsibility relationship attaches a function to the agent that performs it, through a process model, a sequence diagram or a use-case model. The supplier-consumer relationship links elements by the data or the material they exchange, through a data flow diagram or a process model. The cause-effect relationship chains elements by logical contingency, through an Ishikawa diagram. That leaves the emergent properties, those results that an interaction produces and that no component taken alone would have foreseen, which a static boundary drawing struggles to capture.

Level of detail

The recurring difficulty is choosing at what granularity to describe the elements. The purpose of the analysis fixes that level. One and the same subject of change is described in three ways: by enumerating the elements one by one, by placing oneself at a chosen decomposition level or by grouping the elements into logical sets. A batch of processes thus appears as a list of named processes, as a high-level process that encompasses them or as a generic function.

Two symmetrical faults lie in wait for this choice. Too coarse, the model leaves the boundary elements in the vague. It is on these border elements that a poorly defined scope costs the most: the grey zone surfaces after signature, when it becomes a dispute. Too fine, the model tips into analysis paralysis: it decomposes beyond what the scope decision requires, and the exercise stops reducing uncertainty and becomes an inventory. The right level reduces uncertainty usefully without crossing that threshold.

Assumptions and the lifespan of the scope

The validity of a scope model rests on assumptions: the definition of the needs, the causality of the expected effects, the impact of the change, the feasibility of the solution. These assumptions are most often tacit, and a model that looks accepted may rest only on beliefs no one has stated. The discipline is to write the critical assumptions and their implications onto the model itself, beside the boundary they support. A boundary accepted on a false assumption is a deferred dispute.

A scope ages. Once settled, it becomes hard to change, for political as much as contractual reasons, even as several forces erode its validity: an initial assumption disproved, a situation that shifts, needs that evolve, a technical innovation. Treating the model as frozen is therefore a mistake: it is re-read and revised, in whole or in part, each time one of these forces appears. One confusion remains to avoid, between the change scope, which states what is modified, and the solution scope, which states what the solution must cover: a single initiative distinguishes them, and merging them produces a model that lies about one or the other.

AI considerations

Two uses are solid. The first is the first draft: from existing process documents, actor maps or integration diagrams, a language model proposes a list of internal and external elements, a set of candidate external entities and a context diagram to correct. It replaces the blank page with a rough draft, which has value on a legacy system whose real flows have been lost. The second is the cross-check: setting a scope model against the list of requirements gathered, to surface the elements present on one side and absent on the other and to propose the dependency pairs that will feed the matrix.

Three decisions escape the tool. The in-scope decision itself is a political and contractual trade-off that no input data contains. The critical assumptions require knowing what the organisation tacitly takes for granted, which a model trained on generic text does not. The boundary elements, where the whole difficulty sits, demand the judgement the technique exists to exercise. A final caution on the data: submitting internal process maps, where the names of partners and suppliers appear, to an external service is a matter of confidentiality and data protection under the revised Federal Act on Data Protection (revFADP). The boundary is where these sensitive names appear.

Examples

A canton puts online a portal for declaring a change of address, through which a resident reports a move without going to the counter. The scope question is what the portal takes on and what it leaves to the systems in place. The context diagram answers it in a single drawing: the portal is the central bubble, and around it stand the resident who declares, the identity provider that authenticates them, the communal residents' register office that receives the validated notice and the payment provider that collects the fee. Each flow that crosses the boundary, the submitted declaration, the verified identity, the validated notice, the payment confirmation, is an interface to study.

The in-scope decision is then recorded element by element, with its criterion. The sorting criterion is the element's relation to the change: what the portal creates or modifies is inside, what it merely exchanges with is outside. This line, drawn and justified before elicitation, is what the contract will cost and what acceptance testing will verify.

Cost

Tooling

The choice of tool follows the model's expected use. For a boundary discussion among people gathered together, the whiteboard or paper are enough, and their ephemeral nature is an asset while the line is still being sought. A diagram editor (diagrams.net, Lucidchart, Visio) carries the context diagram and the use-case model as soon as they have to be shared, versioned and reworked. The spreadsheet holds the dependency matrix and the table of in-scope decisions, where sorting and filtering beat a drawing. A modelling tool (Enterprise Architect, Sparx) becomes necessary when the scope model feeds a larger model, of requirements or architecture, with which it must stay consistent. A document space or a wiki, finally, carries the textual scope statement and the register of assumptions, which must stay legible and time-stamped through their revisions.

Sources

• IIBA, A Guide to the Business Analysis Body of Knowledge (BABOK Guide) v3, §10.41 Scope Modelling: the classification of scope models by what the boundary shows and the scope it illuminates, the elements to determine, the level of detail, the assumptions and the limitations of the technique.
• Tom DeMarco, Structured Analysis and System Specification, Yourdon Press, 1978: the origin of the levelled flow model whose top level, the context diagram, sets the system as a single process facing its external entities, the scope boundary seen from the outside.
• Chris Gane and Trish Sarson, Structured Systems Analysis: Tools and Techniques, Prentice-Hall, 1979: the second structured-analysis notation for the context diagram, carrying the same idea of a boundary.
• Ivar Jacobson, Object-Oriented Software Engineering: A Use Case Driven Approach, Addison-Wesley, 1992: the origin of the use-case model, whose system box places the actors outside and the use cases inside, a scope seen from both sides.
• Object Management Group, Unified Modeling Language (UML), v2.5.1: the current standard for the use-case diagram and the subject (system) boundary.