Product requirement specifications

Identifies documents containing references to product requirement specifications in Australian contexts. Higher confidence identifies populated product requirement specifications (requirement identifiers with shall/acceptance/priority/owner/release fields, or user-story structures); generic quality, compliance, and specification vocabulary remains discovery-only.

Type: regex
Engine: boost_regex
Confidence: medium
Confidence justification: category-aware structural regex with anchor and context constraints replaces phrase-only detection. Added context gating and exclusion rules improve precision and reduce incidental matches.
Detection quality: Topic false positive
Jurisdictions: global
Regulations: AML/CTF Act (Cth), HRIPA (Cth), IPA 2009 (Qld), My Health Records Act 2012 (Cth), NDB Scheme (Cth), Privacy Act 1988 (Cth), TIA Act 1979 (Cth), GDPR
Frameworks: ISO 27001, ISO 27701
Data categories: intellectual-property
Scope: wide
Risk rating: 5
Platform compatibility: Purview: Compatible, GCP DLP: Compatible, Macie: Compatible, Zscaler: Compatible, Palo Alto: Degraded, Netskope: Unsupported

Pattern

(?is)\b(?:product\s+requirement\s+specifications|requirements\s+document|functional\s+requirements|technical\s+specifications|product\s+specification|design\s+requirements|acceptance\s+criteria|quality\s+standard|compliance\s+requirement|performance\s+specification)\b

Corroborative evidence keywords

product requirement specifications, product, requirement, specifications, quality, safety

Proximity: 300 characters

Should match

product requirement specifications — Primary topic phrase match
requirements document — Case-insensitive topic phrase match
functional requirements — Alternative topic phrase match
technical specifications — Additional topic phrase match
REQ-241 Product: Atlas Mobile. The app shall cache 500 records. Owner: Priya. Priority: P1. Acceptance criteria: sync <2 s. — Populated product requirement record with ID, shall statement, owner, priority, and acceptance criteria (enforces at 75/85)

Should not match

unrelated generic text without domain phrases — No relevant topic phrases present
placeholder value 12345 — Random text should not match topic-specific regex
product failure — Generic word pair from old broad template should not match
The office-chair tender cites a quality standard and compliance requirement. — Procurement compliance without a product requirement record — discovery only, must not enforce
The product of two numbers meets the mathematical requirement. — Product and requirement in mathematical meaning must not match
Sample PRD template: REQ-001 placeholder acceptance criteria. — Sample/template/placeholder marks an empty form — suppressed from enforcement
requirements document — Document label alone has no populated requirements — discovery only, must not enforce

Known false positives

Common words and phrases related to product requirement specifications appearing in policy documents, training materials, HR templates, or compliance guidelines without actual personal data. Mitigation: Require corroborative evidence keywords within the proximity window to confirm sensitive data context rather than general discussion.
In Australian English, similar terminology used in formal or administrative contexts (education, professional documentation) that does not constitute sensitive data collection. Mitigation: Layer with additional contextual signals such as structured identifiers, form fields, or database column headers to distinguish sensitive records from general references.
High-frequency pattern matches in large document corpora due to broad regex anchors. Expected match rate is significantly higher than specific identifier patterns. Mitigation: Tune confidence thresholds for bulk scanning. Consider using this pattern primarily as a pre-filter with secondary validation.

References

https://www.productsafety.gov.au/product-safety-laws
https://www.safeworkaustralia.gov.au/doc/model-code-practice-how-manage-work-health-and-safety-risks