I define quality as the degree to which a set of inherent characteristics of an item fulfills requirements. First, I mean this in a general sense. Then, I apply it to systems and software engineering. In that field, I describe it as the degree to which a system satisfies the stated and implied needs of its stakeholders. Therefore, I focus on fitness for intended use. In contrast, I do not equate it with mere goodness or excellence. Instead, I tie it to how well the product meets requirements.
I distinguish quality requirements from acceptance criteria. First, quality requirements address concerns that functional requirements do not. For example, they cover performance, availability, maintainability, security, and reliability. Next, acceptance criteria specify what a requirement must fulfill to gain stakeholder acceptance. Thus, both functional and quality requirements need acceptance criteria. Moreover, one statement can serve as a broad requirement or as a specific acceptance condition. For example, “The system must be easy to handle” influences many functions and needs further detail, such as subcriteria or concrete checks. By contrast, “The user can start the video from the training overview with one click” acts as a precise acceptance condition for one functional requirement.
Product owners should review each recognized quality requirement before placing it in the backlog. First, they should decide whether the statement represents a quality requirement, an acceptance criterion, or both. Then, they should decompose broad statements into measurable subcriteria. In addition, teams should define acceptance tests for each measurable subcriterion. Consequently, teams can accept or reject backlog items based on clear evidence.
Documentation and Definition of Done also matter. For example, some requirements demand comprehensive and understandable user documentation. However, teams should not copy a Definition of Done from another product without thinking. Instead, they should check which parts fit their context and which parts do not. Thus, they keep the Definition of Done tailored to the team and the product.
I assess the quality of requirements models as well. First, I model requirements with diagrams and supporting text. Then, I evaluate the model with three criteria: syntactic, semantic, and pragmatic aspects. To assess syntactic quality, I check whether each element follows the chosen modeling syntax, such as matching calls and replies in a sequence diagram. Next, I check semantic quality by reviewing correctness and completeness. Pragmatic suitability depends on whether the model serves the needs of its users. Therefore, I examine how diagrams and text work together. In addition, I recommend suitable modeling tools to strengthen syntactic correctness. Finally, I use these criteria to improve the overall intelligibility and usefulness of requirements.
In short, I treat quality as fitness for intended use. Moreover, I separate quality requirements from acceptance criteria. Therefore, I document, measure, and test both. Consequently, stakeholders get systems that meet stated and implied needs.