Why requirements and constraints make software problem-solving better

A requirement is a decision boundary, not paperwork

A useful requirement states an outcome that matters, who it matters to and the conditions that make it true. It does not have to prescribe the implementation. “A customer can see their payment history for seven years” is more useful than “add a history screen” because it invites the team to ask about access, data retention, response time and evidence.

Without a shared outcome, each person fills in the gaps differently. A designer may optimise for a simple journey, an engineer for a minimal change and an operations colleague for low risk. None of those instincts is wrong, but they can pull the work in different directions unless the team has agreed what success means.

Requirements make a later decision reviewable. They let a team say why a field was retained, a report is asynchronous or a request is rejected, rather than treating the current implementation as the only explanation.

Degrees of freedom are choices the problem leaves open

Every under-specified problem has degrees of freedom: choices about scope, behaviour, data, interface, architecture, time and cost. At first this can feel like creative freedom. In practice, too many unbounded choices make estimates vague, discussions circular and solutions difficult to compare.

Imagine being asked to “make account search better”. Does better mean faster, more tolerant of spelling, available to support staff, safe for personal data, usable on a phone or all of those? Each unanswered question creates a branch in the solution space. A team can build a polished answer to one interpretation while missing the actual need.

The aim is not to eliminate judgement. It is to remove the choices that should already have been made by product, policy, user need or operational reality, so engineering judgement can focus on the choices that genuinely need it.

Restrictions create useful focus

A constraint narrows the solution space: a deadline, legal obligation, accessibility need, supported browser, response-time target, budget, existing integration or rule that personal data must stay in a particular boundary. It is tempting to describe these as obstacles, but they are also design input.

A restriction can rule out attractive but unsuitable options early. If an audit trail is mandatory, a destructive update is not a serious candidate. If a service must work on an old device and unreliable connection, a large client-side application may be the wrong default. Discovering those facts before implementation is cheaper than discovering them during acceptance or after release.

Good constraints are specific enough to test. “It must be secure” is an intention; “only an authenticated caseworker with the right role can view this record, and access is logged” gives the team behaviour to design and verify.

Use constraints to compare options, not to end the conversation

Constraints should expose trade-offs rather than silently dictate a solution. A request to return a report in two seconds may conflict with a large historical data set. The options may be to narrow the report, prepare it asynchronously, improve the underlying query or accept a different service level. The team can then discuss the cost and consequence of each option openly.

Write down the constraint, its source and what happens if it is not met. This separates a genuine non-negotiable rule from a preference or an assumption. It also makes it safer to revisit a decision when the product or policy changes.

Where constraints conflict, decide who has authority to make the trade-off. Engineering can explain feasibility and risk; product, policy and operational owners may need to decide which outcome matters most.

Turn a broad request into testable examples

Examples make requirements concrete. Instead of agreeing that a user can “edit a contact address”, describe a normal case, a permission failure, an invalid address, a concurrent change and what the user sees after a successful update. These examples reveal missing rules while there is still time to change the design.

Acceptance criteria should cover observable behaviour, not a list of internal implementation steps. They provide a useful bridge from a conversation to automated checks, exploratory testing, support guidance and release evidence.

Keep a small set of representative examples close to the work. A large specification that no one reads does not reduce uncertainty; a concise set of examples that people use in planning and review can.

Outcome: A registered user can update their contact address.

Constraints:
  - Only the account owner or authorised staff may make the change.
  - The previous address and the change actor are retained for audit.
  - The confirmation must be available within the same session.

Examples:
  - Given a valid UK address, when the owner saves it, then the new address is shown.
  - Given another user's account, when a user tries to edit it, then no address is disclosed or changed.

Keep discovery alive as the work changes

Requirements are not a one-time handover. New evidence may show that a rule was misunderstood, a dependency behaves differently or a user journey has an important edge case. Treating every new fact as scope failure encourages people to hide uncertainty; treating it as information allows the team to adjust deliberately.

The useful discipline is to record what changed, which requirement or constraint it affects and whether the solution still meets the agreed outcome. This keeps change controlled without pretending the original understanding was complete.

A well-constrained problem does not make software development mechanical. It makes creativity more valuable: the team can spend its effort finding the best viable solution instead of repeatedly rediscovering what the problem was.

• State the user or business outcome before choosing a solution
• Record non-negotiable constraints alongside preferences and assumptions
• Ask which degrees of freedom are genuinely still open
• Use concrete examples to expose rules and edge cases
• Make conflicting constraints and their decision owner visible
• Review requirements when new evidence changes the problem