Skip to content
BoKSA

Non-Functional Requirements & Quality Attributes

Non-Functional Requirements & Quality Attributes

Functional behaviour is only half the story. Quality attributes — latency, reliability, power, maintainability, security — decide whether a device is usable in the field. This subject is about making those attributes explicit, ranking them when they conflict, and turning them into measurable criteria instead of slogans ("it should be fast and robust").

Starting Points

  • Bass, L., Clements, P., & Kazman, R. Software Architecture in Practice (quality-attribute chapters). Addison-Wesley.
  • ISO/IEC 25010 — system and software quality models.
  • Technical requirements analysis

Key Points

  • You name the quality attributes that matter for your device and give a measurable definition for each.
  • You identify conflicts (e.g. sampling rate vs. battery life) and record the trade-off you recommend.
  • You map quality attributes to design tactics (watchdog, brown-out detection, modular firmware, encryption at rest).
  • You write acceptance checks for at least two non-functional requirements that a coach could actually run.