6. Non-Functional Requirements

Non-functional requirements (NFRs) are cross-cutting constraints that apply to every epic and story unless explicitly overridden in a specific story's acceptance criteria. The vendor's bid MUST document, for each NFR category below, (a) the approach and architectural pattern selected to meet the target and (b) the verification method and testing strategy that will evidence compliance. Each NFR category shall be testable and measurable; verification is a contractual deliverable in the engagement's definition of done.

Scale targets in this document are sized for Kibble & Co.: a single mid-market pet-supply storefront on BigCommerce. Every figure is anchored to that store's subscriber volume and stated with the verification method that evidences it.

6.1 Performance

• P99 interactive UI response < 500ms (merchant dashboard, subscriber portal) — illustrative
• P99 charge execution latency < 5s from scheduler pickup to processor call initiated — illustrative
• P99 webhook ingestion < 300ms to 2xx response (processing is asynchronous) — illustrative
• Sustained throughput: 40 charges/minute during renewal windows (month-start batch, post-holiday resubscribe push) — illustrative

Figures above are invented for this demonstration, sized to a single mid-market storefront's subscriber volume.

6.2 Reliability

• 99.9% uptime SLA for the subscriptions capability — illustrative
• Zero data loss on charge state transitions
• At-least-once delivery semantics on all external webhook deliveries
• At-most-once charge execution (idempotency key enforcement at adapter and processor levels)

The uptime figure is invented for this demonstration; the delivery-semantics and idempotency requirements are architectural properties, not scale-dependent figures, and are stated as requirements rather than targets.

6.3 Security

• All data-at-rest encrypted (AES-256-GCM for secrets; transparent data encryption for bulk data stores)
• All data-in-transit encrypted with TLS 1.3
• Cardholder-data containment: the subscriptions capability never receives, transmits, or stores PAN, CVV, or full card data; card capture stays inside BigCommerce's hosted checkout, and stored payment references are tokens obtained through the BigCommerce Payments API's Payment Access Tokens flow. Containment keeps the capability out of the cardholder-data environment — it does not exempt it from assessment (see 6.8)
• SOC 2 Type II readiness by end of Phase 2 — illustrative timeline

The scheduler and webhook-handling components run outside BigCommerce's own infrastructure (see 05-platform-integration-contract.md), which is why they carry an independent SOC 2 posture rather than inheriting one from the platform.

6.4 Scalability

• Subscription data is logically isolated from Kibble & Co.'s other connected systems (POS, loyalty); all BigCommerce API calls are scoped to Kibble's single store_hash.
• Target: 15,000 active subscriptions at Year 1 steady state, headroom to 50,000 by Year 3 — illustrative
• Peak handling: subscription charge volume during the BFCM week may run 3x baseline without breaching the 6.1 latency targets — illustrative

Subscriber counts and the peak multiplier are invented for the fictional scope; they anchor the capacity-planning and load-test targets a bid would need to size against, not a claim about Kibble & Co.'s real subscriber base.

6.5 Observability

• Every state transition emits an audit event (append-only, per-store partitioned)
• Every external call (BigCommerce API, payment processor, email delivery) is logged with latency, status code, and correlation ID
• Merchant-visible event timeline on every subscription detail view

6.6 Accessibility

• WCAG 2.2 Level AA for both the merchant admin interface and the subscriber portal
• Full keyboard navigation support; screen-reader tested with adaptive technology

6.7 Internationalization

• Subscriber portal: English at MVP; Spanish by end of Phase 2 — illustrative timeline, scoped to Kibble & Co.'s stated market
• Merchant admin: English only through Phase 2, consistent with BigCommerce control panel standard

Kibble & Co. is a single-region US retailer at MVP. The two-language target reflects its own customer base — Spanish is the second-most-common language among its stated markets — and nothing more.

6.8 Compliance

• CCPA: data subject access and deletion requests fulfilled within 45 days, extendable by a further 45 days per statute; "do not sell" classification (subscriber data is not sold)
• GDPR: out of scope for MVP — Kibble & Co. does not sell into the EU at launch. If international expansion enters scope before launch, this NFR is revisited and the engagement's change-control process (see 08-scope-boundary-and-engagement-model.md) applies.
• PCI DSS — two distinct obligations, both binding: (a) merchant-facing: card entry remains inside BigCommerce's hosted checkout, preserving Kibble & Co.'s SAQ-A eligibility — the capability must never introduce a card-entry surface that degrades it; (b) build-facing: because the scheduler and webhook-handling components are connected, security-impacting systems in Kibble & Co.'s own PCI DSS scope, they must produce audit-consumable evidence (data-flow diagrams, segmentation, secure-SDLC records) for Kibble & Co.'s SAQ — not for a platform-level assessment, since this is a single-merchant build
• Data residency: subscriber PII retained in US-region infrastructure; no cross-border data transfer in MVP scope

The CCPA fulfillment window is the statutory figure, not an invented one. The GDPR out-of-scope call and the PCI SAQ framing are judgment calls specific to a single-merchant, US-only build.

6.9 Acceptance

Each NFR category above requires a named verification method in the vendor's proposed test strategy. The vendor's statement of work and test plan shall specify:

• Performance: load testing methodology, tool/framework, target environment specifications, pass/fail criteria for each latency and throughput target, how test results are captured and reported
• Reliability: failure-mode testing approach (chaos/resilience drills), backup/recovery procedure validation, idempotency verification, webhook retry and de-duplication testing
• Security: cryptography and encryption algorithm validation (e.g., OWASP Top 10 code review, penetration testing scope), data classification audit, TLS configuration verification, evidence package for Kibble & Co.'s PCI DSS SAQ (data-flow diagrams, segmentation, secure-SDLC records)
• Scalability: capacity modeling against the Year 1 and Year 3 subscriber targets, baseline performance at target subscription volume, BFCM peak-load simulation
• Observability: event audit trail completeness check, log delivery SLA validation, timeline rendering accuracy
• Accessibility: automated accessibility scanning (WCAG 2.2 AA coverage), keyboard navigation audit, screen-reader testing plan and tools
• Internationalization: content translation review, locale-aware formatting (currency, dates, numbers) for the Phase 2 Spanish rollout
• Compliance: CCPA impact assessment, PCI DSS SAQ attestation, audit trail review

Acceptance of work shall not occur until all NFR verification methods have been executed, results documented, and any gaps remediated or explicitly waived in writing by Kibble & Co.'s product owner.

See also: 08-scope-boundary-and-engagement-model.md (engagement structure and change control) and 09-estimation-scaffold.md (estimation inputs and contingency framework).

Kibble & Co. is a fictional demo merchant. This package is an independent demonstration by Nino Chavez of a scoping method — not a BigCommerce product, and not a real procurement.