non-functional-requirement-extractor

Overview

ISTQB defines non-functional testing as "A test type to evaluate that a component or system complies with non-functional requirements" (istqb-nft (opens in new window)). The eight ISO/IEC 25010:2011 product-quality characteristics define the canonical NFR categories (cite by stable standard ID; iso.org is paywalled / Cloudflare-protected):

Plus two practitioner-emergent NFR families that are increasingly treated as first-class:

Acceptance-criteria-extractor handles functional requirements (Given/When/Then). This skill handles everything else - the threshold-and-measurement requirements that don't fit Gherkin's shape.

When to use

• A PRD mentions "performance," "fast," "accessible," "secure," or similar - words that fail the Observable testability heuristic.
• A team is shifting from informal to formal NFRs in tickets.
• A non-functional regression is being added to a release plan and needs a measurable baseline.

How to use

1. Confirm functional requirements are already covered by gherkin-from-stories (qa-bdd); this skill takes everything else.
2. Scan the doc family-by-family for the Step 1 signal phrases.
3. For each signal, run the Step 2 testability test: does it have a threshold, a measurement source, and a scope?
4. Rewrite each testable signal as a threshold-bound assertion; never invent a missing number - flag it as a threshold gap instead.
5. Map each NFR to its canonical measurement source per Step 3 (references/measurement-sources.md).
6. Emit the Output-format tables plus a "Threshold gaps (HUMAN INPUT REQUIRED)" list, and return it to the author for confirmation.

Step 1 - Scan the doc for each NFR family

Per family, look for the canonical signal phrases:

Each signal becomes a candidate NFR - but NOT every signal is testable as authored. Run each through Step 2.

Step 2 - Make every NFR threshold-bound

Per ISTQB testability (istqb-testability (opens in new window)), an NFR is testable only when it has:

1. A threshold (numeric or boolean).
2. A measurement source (which tool / metric provides the value).
3. A scope (which surface / user / scenario it applies to).

The agent never fabricates a threshold. If the doc says "fast" without a number, the agent emits an explicit question ("What's the target p95? Common defaults: 2.5s for landing, 1.5s for cached, 200ms for API."), it does not invent 2.5s.

Step 3 - Map to canonical measurement sources

Each NFR must name how it's measured. Look up the canonical source for its family in references/measurement-sources.md, which catalogs sources for Performance (Web Vitals, k6), Accessibility (WCAG 2.2, axe-core), Security (OWASP ASVS, ZAP), Compatibility (MDN, Can I use), Reliability (Google SRE Workbook), and Internationalization (W3C i18n, Unicode CLDR).

Load-bearing defaults - Web Vitals: LCP ≤2.5s, INP ≤200ms, CLS ≤0.1. Per-criterion a11y citations use the WCAG SC ID format (WCAG 2.2 SC 1.4.3 Contrast (Minimum)) so the test report back-references the standard.

Output format

# NFRs extracted from `<doc-id>`

**Source doc:** `<path or URL>`
**Date extracted:** YYYY-MM-DD
**NFRs found:** N
**Threshold gaps flagged:** M

## Performance

| ID    | Requirement                                                | Threshold | Measurement | Scope                |
|-------|------------------------------------------------------------|-----------|-------------|----------------------|
| PRF-1 | LCP on /dashboard                                          | ≤2.5s     | Lighthouse CI; Web Vitals 75th-percentile field data | logged-in user, 4G, 1280x800 |
| PRF-2 | p95 latency on POST /api/orders                            | ≤200ms    | k6 load test, 50 RPS for 5 min | production-like staging |

## Accessibility

| ID    | Requirement                                                | Threshold        | Measurement | Scope            |
|-------|------------------------------------------------------------|------------------|-------------|------------------|
| A11Y-1| WCAG 2.2 AA conformance                                    | zero serious/critical violations | axe-core scan | every page in app sitemap |

## Security

| ID    | Requirement                                                | Threshold        | Measurement | Scope                  |
|-------|------------------------------------------------------------|------------------|-------------|------------------------|
| SEC-1 | No high-severity dependency vulnerabilities                | zero high/critical | npm audit --audit-level=high | every PR; production deps |
| SEC-2 | OWASP ASVS Level 2 baseline                                | pass              | ZAP baseline scan + manual ASVS checklist | release readiness gate |

## Compatibility / i18n / Reliability / Observability

(similar tables, only included when the source doc raised them)

## Threshold gaps (HUMAN INPUT REQUIRED)

| Vague phrase                       | Where in doc          | Suggested concretization                                       |
|------------------------------------|-----------------------|----------------------------------------------------------------|
| "fast checkout"                    | line 12               | LCP ≤1.5s (typical for cached transactional flow)?            |
| "supports global users"            | line 28               | Locale list? RTL support? Timezone handling? Unicode in fields? |

The agent does NOT pick the answers - author must confirm.

Worked example

A team submits a checkout PRD. The skill runs it through two passes.

Pass 1 - vague PRD. Input:

"Checkout must feel snappy and work for users worldwide. We need to meet enterprise security requirements."

Every phrase fails the Step 2 testability test, so nothing is emitted as an NFR - each becomes a threshold-gap question:

**NFRs found:** 0 (all phrases are vague)
**Threshold gaps flagged:** 3

| Vague phrase                              | Suggested concretization                                                                  |
|-------------------------------------------|-------------------------------------------------------------------------------------------|
| "feel snappy"                              | LCP ≤2.5s, INP ≤200ms (Web Vitals defaults)?                                            |
| "work for users worldwide"                 | Specify: which locales? RTL? timezones? Unicode validation? CLDR-based number/date formatting? |
| "enterprise security requirements"         | OWASP ASVS Level 2 (typical baseline) or Level 3 (strict)? SOC 2 Type II audit? FedRAMP? |

The output is a question list, not a fabricated set of thresholds.

Pass 2 - author returns with concrete thresholds. Input:

"Page load on /dashboard must be ≤1.5s p95 measured by Lighthouse CI on the GitHub Actions ubuntu-latest runner. Color contrast ratio ≥4.5:1 for normal text per WCAG 2.2 SC 1.4.3."

Every phrase is now threshold-bound and measurement-cited, so the skill emits tables with zero gaps:

## Performance

| ID    | Requirement                                                | Threshold | Measurement | Scope          |
|-------|------------------------------------------------------------|-----------|-------------|----------------|
| PRF-1 | Page load on /dashboard                                    | ≤1.5s p95 | Lighthouse CI on GitHub Actions ubuntu-latest | /dashboard route |

## Accessibility

| ID    | Requirement                                                | Threshold | Measurement | Scope          |
|-------|------------------------------------------------------------|-----------|-------------|----------------|
| A11Y-1| Color contrast ratio for normal text                       | ≥4.5:1    | WCAG 2.2 SC 1.4.3 | every page |

**Threshold gaps:** 0 - all NFRs are threshold-bound and measurement-cited.

Anti-patterns

References

• istqb-nft (opens in new window) - ISTQB Glossary: non-functional testing.
• istqb-testability (opens in new window) - testability heuristic underlying the threshold-bound rule.
• ISO/IEC 25010:2011 - eight product-quality characteristics. Cite by stable standard ID; spec is paywalled.
• W3C WCAG 2.2 - https://www.w3.org/TR/WCAG22/
• OWASP ASVS - https://owasp.org/www-project-application-security-verification-standard/
• Web Vitals - https://web.dev/articles/vitals (LCP / INP / CLS).
• gherkin-from-stories (qa-bdd plugin) - for functional requirements.