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.
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
In the glossary
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
- Reading an architecture diagram with the C4 model
- From vague expectations to measurable requirements (this lesson)
What you will learn in this module
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.
Related courses
- Product ManagementAdvancedRegular practice: you already use the tools or work on this topic.
Git for PMs: ship as a team without putting production at risk
3 hr 30 min
- Tech for PMsAll levelsNo prerequisites: accessible to everyone.
Explain how a web product works, from browser to server
2 hr 30 min
- Tech for PMsJuniorSome basics are useful: introductory knowledge of the topic.
Design and test an API integration as a PM
3 hr