Exercise 2: A Non-Numeric Vague Requirement — Possible Solution
====================================================================

FIVE PLAUSIBLE, GENUINELY DIFFERENT INTERPRETATIONS OF "SECURE"
------------------------------
    1. Passwords are hashed before storage (nothing about transport,
       access control, or auditing)
    2. All traffic is served over HTTPS (nothing about how data is
       stored once it arrives)
    3. Users can enable two-factor authentication (nothing about
       encryption or hashing at all)
    4. Access is logged and auditable after the fact (a detective
       control, not a preventive one)
    5. The system passes a specific compliance standard's checklist
       (e.g. OWASP Top 10) - itself a whole separate document's worth
       of specific, distinct requirements

WHY "SECURE" IS AT LEAST AS RISKY AS A VAGUE NUMBER
------------------------------
The chapter's own "fast" example at least has an implicit numeric
scale everyone agrees on - developers disagreed about WHERE on the
millisecond scale "fast" sits, but not about what "fast" is measuring.
"Secure" has no such shared scale at all: the five interpretations
above aren't five different THRESHOLDS of the same property, they're
five almost entirely DIFFERENT properties, each a legitimate but
partial slice of what "security" could mean. A team that builds
interpretation 2 (HTTPS) while a security reviewer expected
interpretation 1 (hashed passwords) hasn't disagreed about degree -
they've built something that doesn't address the reviewer's own
concern at all, a more severe gap than any of the "fast" thresholds
represented.

WHY THIS WORKS AS AN ANSWER
------------------------------
This extends the chapter's own testability finding to the harder,
more common real-world case: most vague requirements in practice
aren't vague numbers, they're vague multi-dimensional concepts (secure,
performant, accessible, reliable) where "testable" acceptance criteria
have to specify not just a threshold but WHICH dimension is even being
addressed. This is exactly why Security's own OWASP Top 10 course
exists as a specific, itemized checklist rather than a single
requirement - "secure" only becomes testable once broken into its own
concrete, individually verifiable sub-requirements.