Not all requirements are created equal, and not all requirements are written down. A QA engineer must be able to classify requirements by type — functional, non-functional, explicit, and implicit — because each type demands a different testing approach. Functional requirements tell you what to verify. Non-functional requirements tell you what quality standards to measure against. Explicit requirements are stated in the spec. Implicit requirements are the ones everybody assumes but nobody documents — and they are where some of the most embarrassing production defects hide.
Classifying Requirements — A Tester’s Taxonomy
Understanding the four categories helps you build test suites that cover not just what the spec says, but what the spec should have said.
# Requirements classification with examples from an e-commerce platform
REQUIREMENT_TYPES = {
"Functional — Explicit": {
"definition": "Stated behaviour the system must perform",
"source": "Requirements document, user stories, acceptance criteria",
"examples": [
"REQ-F01: Users can add items to their shopping cart",
"REQ-F02: The system sends an order confirmation email within 60 seconds",
"REQ-F03: Discount codes reduce the subtotal by the specified percentage",
],
"testing_approach": "Derive test cases directly from each stated requirement",
},
"Functional — Implicit": {
"definition": "Expected behaviour not explicitly documented but universally assumed",
"source": "Industry conventions, common sense, user expectations",
"examples": [
"Pressing the browser Back button does not resubmit a payment",
"Session expires after a period of inactivity",
"Error messages are displayed in the user's language",
"Prices display with the correct currency symbol",
],
"testing_approach": "Create test cases based on domain knowledge and UX conventions",
},
"Non-Functional — Explicit": {
"definition": "Stated quality attributes and constraints",
"source": "SLAs, NFR documents, compliance requirements",
"examples": [
"NFR-01: Page load time < 2 seconds at 95th percentile under 5000 concurrent users",
"NFR-02: All user passwords stored using bcrypt with a cost factor of 12",
"NFR-03: Application must meet WCAG 2.1 AA accessibility standards",
],
"testing_approach": "Performance tests, security audits, accessibility scans",
},
"Non-Functional — Implicit": {
"definition": "Quality expectations not documented but expected by users and stakeholders",
"source": "Industry standards, competitor baseline, professional judgement",
"examples": [
"The application does not crash under normal usage",
"Data entered by the user is not lost during navigation",
"The application works on current versions of major browsers",
"Sensitive operations require re-authentication",
],
"testing_approach": "Exploratory testing, stability testing, cross-browser checks",
},
}
for req_type, info in REQUIREMENT_TYPES.items():
print(f"\n{'='*60}")
print(f" {req_type}")
print(f"{'='*60}")
print(f" Definition: {info['definition']}")
print(f" Source: {info['source']}")
print(f" Testing: {info['testing_approach']}")
print(f" Examples:")
for ex in info['examples']:
print(f" - {ex}")
Common Mistakes
Mistake 1 — Testing only explicit functional requirements
❌ Wrong: "The spec has 20 functional requirements and I wrote test cases for all 20. Testing is complete."
✅ Correct: "The spec has 20 explicit functional requirements. I also identified 8 implicit requirements (session timeout, back-button safety, error handling), 3 explicit NFRs (performance, security), and 5 implicit NFRs (crash resistance, browser compatibility). My test plan covers all 36."
Mistake 2 — Ignoring non-functional requirements because they are harder to test
❌ Wrong: "Performance testing requires JMeter and I do not know how to use it, so I will skip NFR-01."
✅ Correct: "I do not have JMeter expertise, so I will flag NFR-01 as a coverage gap in my test plan and recommend that the team either trains me or brings in a performance testing specialist. The requirement exists and must be tested."