Types of Requirements — Functional, Non-Functional, Explicit and Implicit

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}")
Note: Implicit requirements are the hidden minefield of software testing. Nobody writes "the app should not crash" in a requirements document because it is assumed. But when an application does crash, stakeholders do not care that it was not in the spec — they consider it a defect. A mature QA engineer maintains a personal checklist of implicit requirements based on experience: session management, browser back-button behaviour, concurrent access, data persistence, and error recovery. This checklist grows with every project and becomes one of your most valuable professional assets.
Tip: When reviewing a new feature specification, create a "requirements classification table" — list every requirement and tag it as Functional/Non-Functional and Explicit/Implicit. Then look for gaps: are there non-functional requirements for every critical feature? Are implicit requirements documented anywhere? This exercise takes 30 minutes and frequently reveals 5–10 missing requirements that would otherwise become production defects.
Warning: Do not assume that non-functional requirements are "someone else's problem." Performance, security, and accessibility requirements directly affect your test plan. If the specification says "page load under 2 seconds" but your test plan does not include performance testing, you have a coverage gap. If there are no non-functional requirements at all, raise this with the product owner — their absence does not mean the software has no quality expectations; it means those expectations are undocumented and untested.

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."

🧠 Test Yourself

A user complains that pressing the browser's Back button after submitting a payment causes the payment to be submitted a second time. The requirements document does not mention back-button behaviour. Is this a defect?