Requirement Engineering

A checklist of concerns to work through when starting a frontend project. Not every section applies to every engagement — scan the headers and focus on what's relevant to your project.

B2B or B2C?

The answer shapes most downstream decisions.

Concern	B2B	B2C
Users	Known employees or partners	Anonymous public users
Devices	Managed desktops, sometimes tablets	Any device — phones, tablets, desktops
Connectivity	Reliable corporate network	Variable — 3G, flaky Wi-Fi, offline
Key concerns	Feature depth, workflow efficiency	Conversion, engagement, reach
Performance focus	Responsiveness under complex UIs	Fast initial load, low data usage
Auth	SSO / corporate IdP	Social login, email/password, MFA
Compliance	Internal policies, SOC 2	GDPR, CCPA, accessibility laws

tip

Most Aliz projects are B2B. If the client says "internal tool," you can usually assume managed browsers, good connectivity, and known users — which simplifies several decisions below.

Browser Support

The Web Platform Baseline defines two tiers of cross-browser availability:

• Newly available — supported in the latest stable release of all core browsers (Chrome, Edge, Firefox, Safari — desktop and mobile).
• Widely available — 30 months after reaching Newly available. Safe to use without worrying about stragglers.

Practical guidance:

• Default to Widely available for B2C and public-facing apps.
• For B2B apps where you control the browser, Newly available is fine and unlocks newer APIs sooner.
• Browserslist supports baseline queries — use them in your build config.

Common pain points:

• PWA capabilities on iOS/Safari remain limited.
• Some newer CSS features (e.g., @container, :has()) only recently crossed into Widely available.
• Several Web APIs (e.g., Web Serial, Web USB) are Chrome/Edge-only and may never ship in other browsers.

Resources: caniuse.com · webstatus.dev · Web Platform Baseline

tip

Targeting Newly available Baseline in a controlled B2B environment lets you use features like View Transitions and CSS @starting-style before they reach Widely available status.

Internationalization & Localization

A locale combines a language with regional formatting rules (dates, numbers, currency). en-US and en-GB are the same language but different locales.

The single most important decision: externalize all user-facing strings from day one. Retrofitting i18n into an existing codebase is one of the most expensive frontend refactors.

Framework Comparison

Framework	Highlights	Best for
i18next	Most mature, 30+ plugins, ICU via plugin	General-purpose, recommended default
FormatJS / react-intl	Native ICU Message Format	React projects needing strict ICU
Paraglide	Compiler-based, zero runtime overhead	Performance-critical apps
next-intl	Purpose-built for Next.js App Router	Next.js projects

Key Concepts

• ICU Message Format handles pluralization, gender, and select expressions. Use it instead of hand-rolling conditional strings.
• RTL support: use CSS logical properties (margin-inline-start instead of margin-left) and the dir="rtl" attribute.
• Pseudo-localization — generate fake translations that stretch strings and add accents. Catches layout issues without needing real translations.

Localization Services

When translators (non-developers) manage translations, use a dedicated platform: Crowdin, Phrase, Lokalise, or Locize.

i18n adds roughly +10–20% to project effort — see Estimation.

caution

Adding i18n after the fact is one of the most expensive retrofits in frontend. If there's any chance the app needs multiple locales, set up the framework on day one — even if you only ship one language initially.

Accessibility (a11y)

WCAG 2.2

WCAG 2.2 (October 2023) defines three conformance levels:

• A — bare minimum
• AA — standard target for most projects
• AAA — enhanced; rarely required in full, but cherry-pick relevant criteria

Notable additions in 2.2:

• Focus Not Obscured — focused elements must not be fully hidden behind sticky headers/footers.
• Dragging Movements — every drag operation must have a non-dragging alternative.
• Target Size — interactive targets must be at least 24×24 CSS pixels.
• Accessible Authentication — no cognitive function tests (e.g., CAPTCHAs) without alternatives.

Legal Landscape

• US — ADA: courts consistently interpret it as requiring WCAG 2.1 AA for web apps.
• EU — European Accessibility Act (EAA): enforcement from June 2025. References WCAG 2.2 and applies to both public and private sector digital products.

Implementation

First rule of ARIA: don't use ARIA if native HTML does the job. Use <button> instead of <div role="button">.

Automated testing tools:

• axe-core — the engine behind most a11y tools
• Lighthouse — built into Chrome DevTools
• eslint-plugin-jsx-a11y — lint-time checks for React
• pa11y — CI-friendly automated testing

Screen readers for manual testing:

• NVDA (Windows, free)
• VoiceOver (macOS / iOS)
• TalkBack (Android)

Accessibility adds roughly +15–30% to project effort — see Estimation.

caution

The EU European Accessibility Act (EAA) applies from June 2025 to both public and private sector digital products sold in the EU. If the client operates in Europe, WCAG 2.2 AA compliance is likely a legal requirement, not a nice-to-have.

Performance

Core Web Vitals

Metric	Good	Needs Improvement	Poor
LCP (Largest Contentful Paint)	≤ 2.5 s	2.5 s – 4.0 s	> 4.0 s
INP (Interaction to Next Paint)	≤ 200 ms	200 ms – 500 ms	> 500 ms
CLS (Cumulative Layout Shift)	≤ 0.1	0.1 – 0.25	> 0.25

Supporting metrics: TTFB (server response time), FCP (first render), TBT (lab-only proxy for INP).

Performance Budgets

Set budgets per page type. Example:

Landing page: LCP ≤ 2.0 s on 4G, JS bundle ≤ 200 KB.

Measurement

• Field data (real users): CrUX, PageSpeed Insights, Search Console, web-vitals JS library.
• Lab data (synthetic): Lighthouse, Chrome DevTools Performance panel, WebPageTest.

Field data is the source of truth — lab data is for debugging.

Architecture choices (SSR vs SSG vs SPA) have a major impact on LCP and TTFB — see Rendering.

tip

Install the web-vitals library and report real user metrics from day one. Lab data alone isn't enough — field data shows what actual users experience.

SEO

Relevant for B2C, marketing sites, e-commerce, and public documentation. Irrelevant for B2B internal tools behind auth.

Technical Checklist

• Rendering: SSR or SSG for content pages — see Rendering
• Meta tags: unique <title> and <meta name="description"> per page
• Canonical URLs: prevent duplicate content issues
• Social tags: Open Graph and Twitter Card meta tags
• Structured data: JSON-LD using schema.org vocabularies
• Semantic HTML: proper heading hierarchy, landmarks, lists
• Crawl control: robots.txt and XML sitemap
• Mobile-first indexing: Google indexes the mobile version — responsive design is mandatory

Core Web Vitals affect search ranking — see Performance.

note

For B2B internal tools behind auth, you can skip this section entirely.

Security

Frontend-relevant concerns to discuss with the team and client.

XSS Prevention

React escapes output by default. Avoid dangerouslySetInnerHTML, href="javascript:...", and never interpolate user input into raw HTML.

Content Security Policy (CSP)

Prefer nonce-based CSP headers. Avoid unsafe-inline and unsafe-eval — they defeat the purpose of CSP.

CORS

Never use Access-Control-Allow-Origin: * for authenticated API endpoints.

Authentication

Use established providers: Auth0, Firebase Auth, Clerk. Store tokens in HttpOnly cookies, not localStorage.

Supply Chain Security

Run npm audit regularly. Use lockfiles. Consider Snyk or Socket for continuous dependency scanning.

Access Control

Always enforce authorization server-side. Frontend role checks improve UX but are trivially bypassed.

danger

Never trust the frontend for authorization. Role checks in the UI improve UX but are trivially bypassed. Every permission must be enforced on the server.

PWA & Offline

Consider a PWA when the app needs offline support, push notifications, home screen install, or re-engagement features.

Browser Support Status

• Chrome / Edge — full PWA support
• Firefox — limited (no install prompt)
• Safari — push notifications since 16.4, but still the weakest: no background sync, limited service worker lifetime

Key Capabilities

Service Workers, Web App Manifest, Push API, Background Sync.

Caching Strategies

Strategy	Use Case	Tradeoff
Cache First	Static assets, fonts, images	May serve stale content
Network First	API responses, dynamic data	Slower when offline
Stale While Revalidate	Frequently updated content	Brief staleness acceptable

Use Workbox for service worker generation and precaching.

caution

Safari's PWA support is still limited. If the target audience is heavily iOS, test thoroughly and have fallbacks for unsupported capabilities.

Analytics & Monitoring

User Analytics

• GA4 — the default; widely understood, free
• Plausible — privacy-focused, cookieless, GDPR-friendly
• PostHog — product analytics with session replay and feature flags

Error Tracking

• Sentry — dominant choice, excellent source map support
• Bugsnag — solid alternative

Performance RUM

Report real user metrics with the web-vitals library or Vercel Analytics — see Performance.

Privacy

GDPR and the ePrivacy Directive require user consent for cookie-based analytics. Plausible and some PostHog configurations are cookieless and don't require a consent banner.

tip

Sentry + web-vitals is a solid baseline for any project. Add Plausible if you need privacy-friendly user analytics.

Devices & Responsive Design

• Mobile-first approach with 3–4 breakpoints (sm / md / lg / xl). Tailwind's defaults are a sensible starting point — see Tailwind CSS.
• Designers typically deliver 2–4 viewport sizes. Clarify with the client which breakpoints matter most.
• Touch vs pointer: interactive elements need larger hit targets on touch devices (minimum 24×24px at AA, ideally 44×44px at AAA per WCAG 2.2).
• Responsive implementation adds roughly +20–50% effort depending on complexity — see Estimation.

Design

For design approach decisions — using an existing design system, building a custom one, or working with a customer's design — see Design Systems.