How should Product and Engineering define quality requirements for a Feature?
Define quality requirements by identifying the Feature’s important operating conditions and the minimum acceptable behaviour under them. Product explains the user consequence and priority; Engineering turns reliability, performance, accessibility, security or other relevant properties into testable conditions. Agree ownership, evidence and exceptions during shaping, then verify them before release. A generic checklist alone is unlikely to capture the Feature’s risks.
Key takeaways
- Name the user and operational consequence of poor quality.
- Set measurable thresholds only where evidence supports them.
- Use specialist input for accessibility, security and other material risks.
- Connect each requirement to a way of checking it.
A Feature may meet its functional acceptance criteria yet fail customers when traffic rises, an assistive technology is used or a dependency becomes unavailable. Quality needs become costly to address when they surface only during release review. Product and Engineering should surface the properties that matter while the design can still change.
Identify the quality properties that matter
Quality requirements describe how well a Feature must work in its context, beyond what action it performs. They may concern accessibility, response time, resilience, privacy, security, maintainability or interoperability. Product states the user journey and harm if it fails. Engineering identifies system limits and feasible checks. The ISO product quality model offers a reference for quality characteristics, but the team still has to choose what matters in this product.
Use existing standards as a starting point
Reuse organisation-wide design, accessibility, security and service standards where they apply. Those standards prevent each Feature from redefining basic expectations. Add Feature-specific conditions when the journey or data warrants them. A bulk upload has different performance and recovery concerns from a simple preference change. Defra's digital service guidance describes categories for non-functional requirements. Such guidance is a useful prompt, not an automatic target for every product.
Turn concerns into verifiable conditions
Replace 'must be fast' with a context-specific, testable statement: which operation, for whom, under what load and with what acceptable result? Use baselines, service objectives or research where available. If no baseline exists, measure current behaviour before promising a number. Include failure paths and accessibility checks, not only the happy path. Engineering chooses the test method and assesses architectural implications; Product confirms that the condition protects the intended user outcome.
Manage trade-offs and exceptions
Record the requirement with its owner, evidence source, test and release consequence. Security and privacy specialists should review material exposure; GOV.UK guidance recommends considering information risks from discovery. When a threshold cannot be met, Product can change scope or timing, while Engineering explains the technical risk. Escalate any exception to the relevant risk owner. AI may help enumerate scenarios, but cannot certify that a product meets them.
Example
Hypothetically, a benefits administration team shapes a document upload Feature. Product identifies users on slow connections and the cost of a lost submission. Engineering specifies resumable upload behaviour, error messages and checks under representative file sizes. An accessibility specialist tests the journey. The team records how each condition will be verified before release.
FAQs
-
Are quality requirements the same as a Definition of Done?
A Definition of Done gives shared product or team quality measures; Feature-specific conditions add contextual acceptance evidence.
-
Should every Feature have a response-time target?
Only where response time materially affects the journey; use a meaningful baseline and state the conditions of measurement.
-
Who can accept a quality exception?
The accountable product and technical owners should escalate to the designated risk owner when a control or threshold is material.
