Problem Space, Solution Space, and Elicitation | Software and Security Engineering

Problem Space vs Solution Space

Peter Drucker observed:

There is nothing quite so useless as doing with great efficiency something that should not be done at all.

This captures the central risk of requirements engineering: building the wrong thing perfectly. Engineers must separate two distinct conceptual spaces:

Problem Space (the “Why”): technology-agnostic; business value, user needs, market realities, the actual friction or opportunity. Example: “Our warehouse packing process is too slow and error-prone, causing delayed shipments and customer complaints.”
Solution Space (the “What”): introduces technology, architecture, and engineering constraints. Example: “We will build a tablet-based barcode scanning application that calculates optimal walking routes through the warehouse.”

The problem space exists objectively — the warehouse is slow. The solution space is a human choice among many possible options; a tablet app is one option among many (faster conveyors? better training? a different warehouse layout?).

The Translation Gap

The Translation Gap is the distance between how stakeholders describe their needs and what engineers actually build:

Stakeholders know the problem intimately — they live in the warehouse every day — but they speak vaguely. They say “make it faster” without quantifying, and they are prone to describing a solution (“give us tablets”), not the underlying problem.
Engineers know how to build solutions but lack domain expertise. They don’t know the warehouse layout, the packing protocols, or the edge cases that occur at 4 a.m.

Requirements Engineering is the discipline that formally bridges this gap — eliciting the real problem before designing the solution.

Requirements Elicitation Methods

Interviews

Direct conversations with stakeholders. Useful for initial scoping and understanding high-level business goals.

Strengths: efficient; gives rich context; builds rapport between engineers and users.

Weakness: the “faster horses” problem. Users often describe a solution to what they think the problem is, not the underlying need. Henry Ford’s (possibly apocryphal) observation: “If I had asked people what they wanted, they would have said faster horses.” Users lack the technical vocabulary to imagine a fundamentally different solution, so they propose incremental improvements to the status quo.

Ethnography (Observation)

Observing users in their real working environment, doing their real work.

Strengths: reveals invisible workarounds that users consider “normal” and would never think to mention in an interview.

Weakness: time-consuming; requires physical access to the real environment; can be expensive.

The Nurse and the Sticky Note

The classic illustration of why ethnography matters: a nurse who keeps a sticky note of passwords on her monitor.

If you interview her, she would never mention this. She considers it a normal, unremarkable part of her daily workflow — the system logs her out too frequently, so she keeps the password handy. She is not consciously hiding a security vulnerability; she has simply adapted to a poorly designed system and forgotten that it was ever an issue.

Only direct observation would reveal the sticky note, and only further observation would reveal why: the mandatory re-login timeout is too aggressive for a fast-paced clinical environment where a nurse may need to enter data in 30-second bursts between patient interactions. The workaround — writing down the password — is a rational adaptation to a system that does not fit the real workflow.

The engineer’s job is not to scold the nurse. It is to fix the timeout policy so the workaround becomes unnecessary.

The Danger of Natural Language

Human language is ambiguous, context-dependent, and imprecise. Code is binary, deterministic, and merciless. This asymmetry is at the heart of why requirements go wrong.

Consider this requirement:

“The search system should be fast and easy to use.”

What does “fast” mean — 100 ms? 2 seconds? Under what load? What does “easy to use” mean, and how would you programme a test for it? If the client later rejects the software as “too slow,” the engineer has no contractual defence. The requirement was never defined in falsifiable terms.

A better version:

“The search system shall return results for a database of 1 million records in under 500 milliseconds for 95% of queries under a sustained load of 100 concurrent users.”

This is quantifiable, testable, and sets a clear boundary for acceptance. The engineer can write a load test that passes if 95% of queries return within the threshold. Both parties can agree on what “done” looks like.

The Cost of Fixing Requirements Errors: Boehm’s Curve

Getting requirements wrong does not just produce the wrong product — it is exponentially expensive to fix. Boehm’s empirical observation of real-world software projects shows that the cost of fixing a defect rises dramatically the later it is discovered:

$\text{Design} \; (1\times) \;\to\; \text{Coding} \; (5\times\text{--}10\times) \;\to\; \text{Testing} \; (10\times) \;\to\; \text{Production} \; (100\times+)$

During the design phase, fixing a misunderstood requirement costs $1\times$ : you update the document, email the team, and carry on. During coding, you have rewritten modules built on the wrong assumption — perhaps $5\times$ to $10\times$ the original cost. During testing, you must not only fix the code but re-integrate, re-test the fix, and verify no new bugs were introduced — roughly $10\times$ . In production, fixing a requirements error may require: patching live services without downtime, migrating corrupted data, compensating affected users, dealing with regulatory penalties, and repairing reputational damage — $100\times$ or more.

This is why Waterfall (where testing happens in Phase 4, years after the requirements were frozen) is so dangerous for projects with unstable requirements. Agile reduces this risk by delivering working software every two weeks: if a requirements error is present, it is caught in the next Sprint Review, not years later, when the cost is still near the design end of the curve.

Expected Learning

Distinguish the problem space from the solution space and explain why this separation is critical.
Define the Translation Gap and explain how it causes requirements failures.
Compare interviews and ethnography as elicitation methods, giving concrete examples of what each misses.
Explain why a good requirement must be quantifiable and testable, not ambiguous.

Past Paper Questions

Example Sheet 1, Question 6 presents a hospital-ward scenario that directly tests your understanding of why ethnography might surface requirements that interviews miss. Example Sheet 1, Question 2 asks you to critique the ambiguous requirement “ultra-fast and safe” and rewrite it as three testable NFRs.