I define quality criteria as the expected properties of good requirements and good RE work products. In other words, I describe what makes a requirement useful in practice. First, I explain why these properties matter: they reduce misunderstandings and lower project risk. Therefore, I review requirements against an explicit checklist. In addition, I tailor that checklist to the project context, because each project comes with different constraints and levels of formality.
Next, I follow a value-oriented approach. Consequently, I assess each requirement by the value it creates. Thus, I do not force every statement to satisfy every check to the same degree. Instead, I prioritize what matters most. For instance, adequacy and understandability often rank highest. However, verifiability becomes critical when the project uses formal acceptance procedures.
For single requirements, I rely on a small set of key checks. First, adequate: the statement reflects true and agreed stakeholder needs. Second, necessary: it lies inside scope and supports at least one stakeholder goal. Third, unambiguous: everyone shares the same interpretation. Fourth, complete: it contains all parts needed for understanding. Fifth, understandable: the target audience can grasp it fully. Sixth, verifiable: the team can objectively confirm whether the implemented system fulfills it.
A few terms need clarification. Some people use “correctness” instead of “adequacy.” However, I prefer “adequacy,” because “correctness” suggests a formal procedure that decides what is correct. Since most projects lack that kind of formal proof, I avoid the term. Instead, I validate requirements with stakeholders and treat them as adequate when stakeholders agree.
For RE work products, additional checks matter. First, consistent: no two requirements contradict each other. Second, non-redundant: the set avoids duplicates and unnecessary overlap. Third, complete: the work product covers the intended scope at the chosen level of detail. In addition, I review the structure for clarity and maintain traceability when it adds value. Thus, I support impact analysis and change management.
Trade-offs always apply. For example, prototypes can clarify uncertain requirements. However, exploratory prototypes can cost time and money. Therefore, I weigh the effort against the expected insight for elicitation and risk reduction. Consequently, I choose the method that delivers the best value for the specific context.
Finally, I separate quality requirements from acceptance criteria. Quality requirements describe concerns such as performance, availability, maintainability, security, or reliability. By contrast, acceptance criteria define the concrete conditions a requirement must meet for stakeholder acceptance. Therefore, both functional requirements and quality requirements should include acceptance criteria. For example, a broad statement like “the system shall be easy to handle” needs refinement, so I break it down with a quality tree or with specific acceptance checks.
In short, I use a tailored set of checks to make requirements useful. First, I adapt them to the project context. Second, I prioritize them by value. Third, I balance effort and benefit. Finally, I validate requirements with stakeholders so they support real project goals.