chapter two

2 Understanding the problem

 

This chapter covers

  • Separating problem from solution
  • Identifying architecture-shaping requirements
  • Using tiers for non-functional requirements
  • Handling compliance constraints
  • Knowing when to move to solutions

Thinking up a brand-new solution is always inspiring. A product team asks for a drag-and-drop canvas where users arrange items freely, and you are already picturing how satisfying it would be to build from scratch a custom rendering engine. You hear that users type something fuzzy into a search box and don't get the results they expected, and full-text search comes to mind straight away, along with the indexing setup you read about last week. We've all been there. Search will follow us through this chapter as a running example, as one area where it is so easy to picture a solution before anyone has properly defined the problem.

As engineers, we are trained to think in terms of solutions – architectures, patterns, technologies. It’s tempting to move quickly into decision mode, especially as we can prototype a solution so quickly these days, thanks to AI capabilities. But jumping to the solution too fast is risky: we may solve the wrong problem, or solve the right one in a way a missed constraint later invalidates.

2.1 Problem definition beyond requirements

2.1.1 From quick solutions to the real needs

2.1.2 How engineering shapes the requirements

2.1.3 Architecturally significant requirements

2.2 Thinking in service tiers

2.2.1 Availability

2.2.2 Durability

2.2.3 Latency

2.2.4 Load

2.2.5 Volatility

2.2.6 Comparing service tiers

2.3 Compliance requirements

2.3.1 Separating requirements from controls

2.3.2 Legal requirements

2.3.3 Security requirements

2.3.4 Common tips for addressing compliance requirements

2.3.5 What about architecture requirements?

2.4 When the problem is ready for solution discussion

2.5 Summary