Module
Module 2 of 6Lesson 2 of 2~16 min

From vague expectations to measurable requirements

As long as "fast" or "reliable" remain adjectives, nobody can compare two architectures or tell whether a project succeeded. This lesson shows how to turn those expectations into testable non-functional requirements, pick a metric that does not hide the users who suffer, and keep only the scenarios that weigh on the decision.

Take this lesson: your first course is freeSee the full syllabus

Lesson objective

By the end of this lesson, you will be able to name the quality attributes that matter for your product, rewrite a vague expectation ("fast", "reliable", "scalable") as a measurable six-part scenario, and choose an honest measure, such as a percentile rather than an average.

Topics covered

  • non-functional requirements
  • quality attributes
  • quality attribute scenario
  • latency percentile
  • ISO 25010

Where it fits

Reading an architecture

How do you read an architecture diagram and state precisely what the system must guarantee?

Lessons in this module

  1. Reading an architecture diagram with the C4 model
  2. From vague expectations to measurable requirements (this lesson)

What you will learn in the course

This lesson is part of the course Read and challenge a technical architecture

  • Read an architecture diagram (context and container levels of the C4 model) and spot its components, flows, boundaries and gray areas.
  • Turn vague expectations ("fast", "reliable", "scalable") into measurable non-functional requirements, written as quality attribute scenarios.
  • Compare monolith, modular monolith and microservices, then synchronous calls and asynchronous processing, based on the team, the load and the consequences for the user.
  • Assess data choices (source of truth, transactions, replicas, consistency), scaling and caching, and spot the bottleneck of a user journey.
  • Assess dependencies on third-party services (composite availability, degraded mode, vendor lock-in) and a build or buy decision.
  • Frame an architecture trade-off, record it in an ADR and treat technical debt as a product decision.
  • Run an architecture review of your product or of a proposal, with ten questions, a risk register and explicit trade-offs.

Related courses