4.9 KiB
NFR Requirements Plan — react-frontend-app
Steps
- Assess Security Baseline rule applicability for a static, no-backend React frontend
- Determine performance expectations (Lighthouse-style targets, bundle size sensitivity)
- Determine testing/tooling expectations (test runner, linting, formatting)
- Determine routing fallback strategy for the FTP/static hosting target (NFR-4 follow-up) — AI recommendation: hash-based routing (see nfr-requirements.md)
- Determine accessibility target level
- Determine CI expectations for this iteration
- Generate nfr-requirements.md and tech-stack-decisions.md
Clarification Questions
Please answer each question by filling in the letter choice after the [Answer]: tag.
Question 1: Performance target
Is there a specific performance target for this static marketing site (e.g. Lighthouse score, load time)?
A) No hard numeric target — just keep the bundle reasonably small and avoid obvious performance mistakes (code-splitting not required yet for a single page) B) Target a Lighthouse Performance score of 90+ on the built production bundle C) No performance requirements at all for this iteration X) Other (please describe after Answer: tag below)
Question 2: Testing tooling
Which testing setup should be used for this iteration (component/unit tests)?
A) Vitest + React Testing Library (natural fit with Vite) B) Jest + React Testing Library C) No automated tests for this iteration — only manual verification and a successful build X) Other (please describe after Answer: tag below)
Question 3: Linting / formatting
Should linting and formatting be configured as part of this setup?
A) Yes — ESLint (with React/TypeScript rules) + Prettier, configured and passing on the initial codebase B) Only ESLint, no Prettier C) Not needed for this iteration X) Other (please describe after Answer: tag below)
Question 4: Routing fallback strategy for FTP hosting (NFR-4 follow-up)
Since the target deployment is a plain FTP/static web host and TanStack Router is being set up now, which routing mode should be used to avoid future deep-link/404 problems on that kind of host?
A) Use TanStack Router's hashHistory (URLs like /#/pakketten) — works on any static host without server configuration, at the cost of slightly less clean URLs
B) Use browser history mode now and defer the FTP rewrite-rule (.htaccess) problem to Deployment Setup in the Operations phase, since there's only one route today
C) Not sure — let the AI recommend based on best practice for this hosting target
X) Other (please describe after Answer: tag below)
Question 5: Accessibility target
What accessibility (a11y) target should this frontend meet?
A) WCAG 2.1 AA as a target (semantic HTML, sufficient color contrast for both themes, keyboard-operable theme toggle, aria labels per functional design) B) No formal target — best-effort only, matching whatever the reference HTML already provides X) Other (please describe after Answer: tag below)
Question 6: CI for this iteration
Should a CI pipeline (e.g. GitHub Actions) running build/lint/test be set up as part of this iteration?
A) Yes — set up a basic CI workflow that runs install, lint, test, and build on every push B) Not yet — CI can be addressed later, possibly during the Operations phase (Deployment Setup) X) Other (please describe after Answer: tag below)
Question: Security Baseline Rule Applicability
Given this is a static, no-backend marketing frontend (per requirements.md), most backend-oriented Security Baseline rules (SECURITY-01, 02, 05, 06, 07, 08, 11, 12, 13, 14, 15) will be marked N/A. The following rules ARE potentially applicable and need a decision on scope:
- SECURITY-04 (HTTP security headers) — depends on hosting; may need to be deferred to Deployment Setup if the FTP host doesn't support custom headers easily
- SECURITY-09 (hardening/misconfiguration) — mainly "no sample/demo pages", generic error handling for a client-side app
- SECURITY-10 (software supply chain) — dependency lock file + vulnerability scanning, applicable to any npm project
- SECURITY-13 (integrity) — Subresource Integrity (SRI) for the Google Fonts CDN
<link>tags
How should these be handled for this iteration?
A) Address SECURITY-10 (lock file + npm audit/dependency scanning) and SECURITY-13 (SRI where feasible) now during Code Generation; defer SECURITY-04 (HTTP headers) to Deployment Setup since it depends on the final hosting choice; mark SECURITY-09 items as addressed via a standard production build (no demo pages, generic error boundary)
B) Defer ALL of these to the Operations phase (Deployment Setup / Production Readiness) — do not address any Security Baseline rule during Code Generation
X) Other (please describe after Answer: tag below)