[August 2026 edition]

The Art of Defining Problems, Part 3 — Running the Definition and Handing It to Requirements

Published: Aug 11, 2026
Reading time: ~16 min

Part 1 and Part 2 got the problem written down.

The problem definition written first, though, is a hypothesis built from limited information. Part 3 covers the procedure for updating the definition as research comes in, through to handing it to requirements definition.

1. Running the definition

A problem definition is not a document you write once and finish. It is updated as research comes in, and how it is handled through to requirements definition is settled.

1.1 Treat the definition as a hypothesis

The first problem definition is a hypothesis built from limited information. Run user research and it can turn out that the people in most difficulty are not the users you assumed. Observe the work and differences emerge between the procedure a practitioner described and the procedure actually followed.

What gets observed is the work as actually performed, not the work as described. Where people wait, what they transcribe, where they route around the official procedure, which information they distrust. That record is what rewrites the problem statement written in the meeting room.

Even in the world of System Dynamics, problem definition is called the most important step while the methodology stays thin. The paper by Mashayekhi and Ghili points out that of Sterman’s textbook of over a thousand pages, five are given to problem definition. Richmond’s book gives it fewer than ten, and at the time the System Dynamics Review had carried no paper on the subject in the previous decade. On their account, one reason is that problem definition is iterative work. In practice, the problem definition is completed on the basis of information obtained from the later steps of modelling.

1.2 Measure the value and the scale of solving it

Judging whether something is worth solving has been worked out in practice too. The Ministry of Justice’s 2020 account of Discovery uses these seven questions.

Does the problem exist
Is it worth solving
Can we solve it
Is it urgent
Is it widespread
Are users solving it themselves
Has someone else already solved it

If 1 through 5 are yes and 6 and 7 are no, you have probably found a problem worth solving. Proceed to development without checking 6 and 7 and you will build something that competes with alternatives already in use.

That judgement comes with an estimate of scale. The GOV.UK Discovery page also asks teams to quantify the value of solving the problem. There are four axes to measure: the number of people affected, the number of occurrences, the loss per occurrence, and the duration. The bare fact that an operation takes 30 seconds longer looks small, but for an operation a million people perform 20 times a year, the time lost comes to roughly 167,000 hours annually.

Counts alone do not settle it, however. Work where a single failure becomes a serious incident is high priority even if it happens once a year. On top of the four axes, establish how far the damage reaches in the worst case, and whether the problem grows if nothing is done.

1.3 What to write in the problem definition document

Problem definition does not require producing one enormous document. What matters is being able to trace what was judged to be the problem, what backs that judgement, how far it remains unconfirmed, and what happens next as a result.

For that reason the deliverable is managed in three groups: “the problem itself”, “open items”, and “decisions”. Pulling the discussion so far together, it converges on the following items.

1.3.1 The three groups

The problem itself

Item	Content
As-is	Current values, procedures, frequency of occurrence
To-be	The destination, written without including means
Gap, and why it cannot be left alone	Whose gap, of what kind, and why solve it now
Evidence	Observations and figures backing the gap
Boundary	In scope and out of scope
Stakeholders	Those affected, those who benefit, those who bear the cost, those with decision rights
Change over time	How the main indicators have moved
Constraints	Law, contracts, deadlines, safety

Open items

Item	Content
Cause hypotheses	Supporting facts, counter-evidence, how to verify
Unverified assumptions	Custom, received belief, past decisions — conditions merely presumed to be unchangeable
Unresolved questions	What the next round of research will establish

Decisions

Item	Content
Success metrics	What the desired state is observed by
Next action	Further research, a change to the work, a trial, systematisation, or stopping

Of these, out-of-scope boundaries, policy or business intent, constraints, and users are all listed by the GOV.UK Discovery page as things to understand during research. That page writes that “reframing the problem also involves agreeing what is not part of the problem”, and asks teams to decide how success will be measured.

1.3.2 Separate constraints from unverified assumptions

Constraints and unverified assumptions go in separate tables because they are handled differently. The moment “the existing system cannot be changed” is written into the constraints column, it is treated as a settled condition and the field of candidate solutions narrows. If you cannot point to the document or approval that decided it, move it over to the unverified assumptions side and leave it there as something to check.

Part 2 divided constraints into four kinds: absolute constraints, chosen constraints, negotiable constraints, and unverified assumptions. In this table the first three go in the constraints column and the last one in the unverified assumptions column. Law and safety cannot be moved, while budget and deadlines can be renegotiated as a management decision, and contracts and inter-department rules are open to adjustment. Even when they are written together in the constraints column, note which classification each one falls under.

Including constraints in the deliverable of problem definition is the same on the systems engineering side. SEBoK’s System Concept Definition writes that Stakeholder Needs Definition identifies integrated needs on the basis of input from key stakeholders, higher-level requirements, and analysis of life cycle concepts, drivers, constraints, and risks. Constraints are not something that surfaces at the stage of designing a solution; they are treated as an input at the stage of fixing needs.

The act of writing them out carries its own value. SEBoK’s Foundations of Systems Engineering cites boundary critique as an example of a pragmatic approach that selects methods to suit the situation, and writes that it “allows stakeholders with different perspectives to make their assumptions and constraints explicit”. Assumptions that are never written out stay in each person’s head.

1.3.3 Write the boundary in two stages

The boundary column carries two things: in scope and out of scope. Write only what is in scope and there is no way to tell whether the unwritten remainder is “not yet considered” or “considered and excluded”. Without that distinction, the same discussion repeats whenever new stakeholders join later.

Deciding what is out of scope, though, requires grasping the whole picture of the problem first. Narrow the scope without that grasp and it is not a decision to exclude, merely a range you have not looked at.

SEBoK’s Identifying and Understanding Problems and Opportunities asks for these two stages. It states that the problem context sets boundaries on cost, time to realisation, duration of use, and operational effectiveness, and then writes that “in general, one describes both the full problem and the version of the problem agreed to be addressed next”. Write the whole picture, and on top of that write this round’s version — that is the order.

1.3.4 Separate success metrics from the desired state

The desired state and the success metrics look like the same statement while playing different roles. The desired state states the destination; the success metrics state what that arrival is confirmed by.

“Process 90% of standard cases by the next business day” is a desired state. The success metric against it is “the 90th percentile of elapsed time from receipt of an application to completion”. The former is what stakeholders agree on; the latter is the design of measurement.

Keep them together and you shrink the desired state down to what can be measured. Where existing logs yield only processing time, rewriting the desired state as “shorten processing time” removes from the description the outlook on the wait that genuinely troubles users. Write the desired state apart from the convenience of measurement, and work out how to measure it on the success metrics side.

Putting down a metric that cannot be measured is not a defect in the problem definition either. It shows that work remains on deciding what to measure and how.

1.4 A worked example

Written out for real, it comes out as follows. This takes the request covered in Part 1 — “we need to stop managing this in Excel and introduce a customer management system” — and drops it into the three tables.

The problem itself

Item	Example entry
As-is	Sales staff record their contact history with customers in individual Excel files. Handover on a change of account owner takes an average of 3 business days
To-be	Even when the account owner changes, the customer contact history needed can be checked the same day
Gap, and why it cannot be left alone	During the handover period, replies to the customer are delayed and renewal negotiations stall
Evidence	The handover record for 18 changes of account owner over the past year, plus interviews with the sales department
Boundary	In scope is contact history for the corporate sales department. Post-order maintenance support history is not covered this time
Stakeholders	Sales staff, the incoming account owner, sales management, the customer
Change over time	Changes of account owner have doubled to 8 per year since last fiscal year’s reorganisation
Constraints	Because customer personal data is involved, storage on an external service requires review by the information systems department

Open items

Item	Example entry
Cause hypotheses	Transcription takes time because the record format is not standardised. The supporting fact is that the Excel format differs by member of staff. Verification is to measure the time taken with a standardised format
Unverified assumptions	The practice that “history is something the account owner manages”. No approval document has been found
Unresolved questions	Of the 3 business days of handover, which is longer, the transcription work or the verbal briefing

Decisions

Item	Example entry
Success metrics	Elapsed time from a change of account owner to the successor being able to consult past contact history
Next action	Measure the breakdown of the handover work for one month, then judge whether systematisation is needed

What to check in this example is that nowhere in the three tables is a solution written. Both introducing a SaaS and moving to shared documents get compared after the measurement in the next action is finished. What can be written at this point goes as far as what will be measured and when the judgement will be made.

1.5 Judging whether you have written it

Condensing the three tables into a single sentence gives you something usable as it stands in meetings and in exchanges over requests. The sentence pattern is assembled from two sources: the items in 1.3, and the page where GOV.UK writes about user research in Discovery.

GOV.UK lists what research should establish: who the users are, what they are trying to do, how they currently do it, and what obstacles and frustrations they meet. Put those four in the first half and follow with the items from 1.3 in the second half, and you get this form.

“[Target group] is trying to [what they want to achieve] in [situation], but is [specific impact] because of [observed obstacle]. Currently it is [current value], and by [deadline / scope] we need to achieve [desired state]. The cause and the solution, however, remain undetermined.”

The frame in the second half maps one-to-one onto the tables in 1.3. The target group is the stakeholders column; the observed obstacle and current value are the As-is and evidence columns; the specific impact is the column for why the Gap cannot be left alone; the deadline and scope are the boundary and constraints columns; the desired state is the column of the same name. Fill in the tables and the sentence is a matter of transcription.

Whether the closing sentence is kept changes how the whole thing is handled afterwards, because at this point both the cause and the solution are still hypotheses.

Fitting the worked example from 1.4 into this form:

The incoming account owner in the corporate sales department is trying to check past contact history immediately after taking over a customer, but requires an average of 3 business days before that check because the history sits in the previous owner’s personal Excel file. Changes of account owner currently occur 8 times a year, and by next fiscal year’s reorganisation we need to reach a state where the customer contact history needed can be checked the same day even when the account owner changes. The cause and the solution, however, remain undetermined.

Neither a customer management system nor a SaaS appears in that sentence. What appears is who, when, trying to do what, and how long they are kept waiting. If a product name is in there, you are still at the stage of having transcribed the request.

Judging whether you have written it shows up in the changes that followed rather than in the quality of the prose.

Change	What to check
Discussion	Whether stakeholders can now talk about the same problem
Separation	Whether symptom, cause, and solution are handled separately
Identification	Whether users and the range of impact are settled, and unverified assumptions are visible
Options	Whether candidate solutions have increased and the scope of development has shrunk
Measurement	Whether the metric for success and the next question to investigate are decided
Stopping	Whether a problem not worth solving could be stopped

Inspecting the worked example against these six gives the following.

Change	State in the worked example
Discussion	The sales department and the information systems department can talk while looking at the same figure, the handover duration
Separation	The lack of a standardised format sits in a separate table as a cause hypothesis, unmixed with the problem itself
Identification	In scope is settled as the corporate sales department and out of scope as maintenance support history, and the assumption that “history is something the account owner manages” remains as unverified
Options	Standardising the format, moving to shared documents, and introducing a SaaS stand as candidates, not yet narrowed to one
Measurement	Measuring the elapsed time until history can be consulted is decided, and which of transcription and verbal briefing is longer is the next question
Stopping	If measurement shows most of the handover is verbal briefing, the proposal to build a record system is withdrawn

Better not to mistake the open items column being filled in for a state of having failed to write it. Leaving open the possibility, as the last row does, that measurement makes development unnecessary is a problem definition doing its job.

A good problem definition does not necessarily converge the team quickly on a single solution. It widens the options once, and narrows the solutions after agreement on what should be solved. Diverge on solutions before defining the problem and you get a great many answers to the wrong question.

2. The relationship to requirements definition and use cases

2.1 The difference in role from requirements definition

Problem definition and requirements definition are close in name and different in role.

Item	Problem definition	Requirements definition
Central question	What needs to change	What the solution must satisfy
Subject	Reality, users, work, the organisation	A system or service
Main output	Current state, desired state, gap, importance	Features, quality, constraints, data
Solution	In principle not settled	Makes the chosen solution concrete
Possibility of ending	Includes the conclusion of building nothing	Normally something exists to be realised
Consequence of failure	Choosing the wrong problem	The solution fails to meet the requirement

What requirements definition handles is the conditions the chosen solution must satisfy. Which problem is being solved was settled in the preceding phase. If for every single requirement you can answer which problem it exists to solve, the correspondence with the problem definition holds.

That order is in IPA’s Requirements Definition Guide for Users, 2nd edition as well. Eliciting business requirements is structured as grasping the current state, extracting problems and issues, extracting goals, and extracting means, in that order. The current state and the problems are examined before requirements are gathered.

2.2 The stage at which use cases can be written

The same order applies to use cases. A use case contains, as a premise, that the work written in it continues in future. Write one before the problem definition and the boundary between the current work and the assumed system is fixed at that moment. A use case can serve as a tool for discovering problems, and it is no substitute for a problem definition.

The order runs as follows.

Define the problem
Consider eliminating, reducing, or redesigning the work
Decide the scope the system covers
Write the remaining user objectives as use cases
Derive requirements from there

Use cases can be written once you have reached the fourth step. With step two having decided that the work stays and step three having decided the scope the system covers, a use case can describe what a user achieves within that scope.

2.3 Five questions that find gaps in the problem definition before implementation

The following five are things that ought to have been answered at the problem definition stage. Because they ought to have been settled before requirements definition, they are not items a development team should be taking on for checking right before implementation.

They still have to be checked because requirements sometimes arrive without having passed through a problem definition. It is work beyond the boundary of the role, and without noticing here, the gap goes into implementation unaddressed. If an item turns up that cannot be answered, send it back to the commissioning party or the user department as an undefined problem before proceeding with implementation.

Question	What to suspect when it applies
If you were forbidden to build a system, would the problem remain	If it would not, the problem is not on the technical side
Is there an organisational problem being hidden with technology	Missing allocation of responsibility or missing agreement
Would this feature become unnecessary if the rules were changed	Convoluted rules are being absorbed in implementation
Is there a mismatch of meaning being absorbed in the data model	Terminology definitions not agreed
Is a flexible system needed, or are the business rules simply unorganised	Vague requirements are being substituted with configurability

When the commissioning party or user department that received the return redoes the problem definition, problems can surface that the department’s own authority cannot settle. That becomes a decision to change the design of the organisation, so from there management sometimes takes it over.

At that point, what had been handed to the development team as a technical issue turns out to have been an issue for management to decide. Had the development team not sent it back, that issue would have been absorbed as implementation and might never have reached management.

Summary — Falling Development Costs and the Weight of Problem Selection

The capacity to build software keeps rising. Cloud, open source, low-code, generative AI, and coding agents have made it possible to build faster, in greater volume, and more intricately than before. The lower the cost of building, the stronger the sense that there is no need to think before building.

What has fallen, though, is only the cost of implementation. The cost of users learning it, of maintaining the data, of managing permissions, of responding to incidents, of keeping it secure, of keeping up with regulatory change, of retiring the old machinery. The UK government’s legacy IT guidance notes that continuing to maintain ageing assets is itself a security and cost burden. Retirement remains as a phase too. GOV.UK treats retiring a service as its own stage, asking teams to consider user needs as they did during construction and to work out how those needs will be met once the service is gone.

Being easy to build is a separate matter from being worth building. Now that solutions can be produced without limit, what determines the result is not the speed of implementation but what was chosen as the problem.