2. Defining Nonfunctional Requirements
2. Defining Nonfunctional Requirements
This chapter covers four of them:
"The Internet was done so well that most people think of it as a natural resource like the Pacific Ocean, rather than something that was man-made." — Alan Kay
Functional requirements = what screens, what buttons, what each operation does. Nonfunctional requirements = fast, reliable, secure, legally compliant, maintainable. Usually unwritten because they seem obvious — and just as important: an app that is unbearably slow or unreliable might as well not exist.
This chapter covers four of them:
- Performance — defining and measuring it
- Reliability — continuing to work correctly even when things go wrong
- Scalability — efficiently adding capacity as load grows
- Maintainability — keeping it workable long-term
Sections
- 2.12Case study: social network home timelinesThe numbers (X/Twitter-shaped, simplified):
- 2.24Describing PerformanceIn the case study: posts/s and timeline writes/s are throughput; time to load the home timeline and time until a post reaches followers are response times.
- 2.3Reliability and Fault ToleranceReliability ≈ "continuing to work correctly, even when things go wrong."
- 2.41ScalabilityFor a new product with few users, the overriding engineering goal is keeping the system simple and flexible so you can adapt as you learn what customers need.
- 2.5MaintainabilitySoftware doesn't wear out or suffer material fatigue.
- 2.6Deep dives1Technology deep dives
- 2.7Failure catalogProduction failure catalog for this chapter
- 2.8Decision sheetDecision cheat sheetp50 for "typical user experience," p99 for the SLO, p999 only if your slowest requests correlate with your most valuable customers (the Amazon case).
- 2.9TerminologyTerminology introduced here
- 2.10Worked examplesWorked examplesQuery-on-read: 10M online users ÷ 5 s polling = 2M queries/s; × 200 followees = 400M lookups/s.
- 2.11Self-testSelf-test
- 2.12Forward linksForward links