Non-functional Requirements & Quality Attribute Analysis
What a system must do is only half the story — how well it does it (performance, reliability, availability, scalability, security, usability, maintainability, portability) often decides whether it's actually usable. The ISO/IEC 25010 quality model gives you a shared structure for these quality attributes, and quality attribute scenarios (stimulus, environment, response, measurable value) let you turn a vague wish like "the system should be fast" into something you can actually test. External standards — app store guidelines, OWASP ASVS, WCAG, Core Web Vitals — often set the real bar, separate from whatever internal quality you were already aiming for.
Starting Points
- SWEBOK Guide — "Software Requirements" and "Software Quality" chapters (IEEE Computer Society).
- Wiegers, K. E., & Hokanson, C. (2023). Software Requirements Essentials. Addison-Wesley.
- Technical requirements analysis
Key Points
- You identify relevant quality attributes for a system and its ecosystem (e.g. a mobile app in an app store, a web service on a cloud platform) and categorise them.
- You derive non-functional requirements from external quality standards and stakeholder expectations, such as app store guidelines, OWASP, WCAG, and Core Web Vitals.
- You express non-functional requirements as concrete, measurable quality attribute scenarios.
- You evaluate an existing design or implementation against defined non-functional requirements and standards, and identify gaps and risks.
- You communicate trade-offs between quality attributes (e.g. performance vs. security) with a clear, justified recommendation.