Requirements Analysis
Translate business intent into precise, testable frontend requirements before a single line of code is written.
Requirements analysis is the process of identifying, documenting, and validating what the interface must do, for whom, under what constraints. This phase produces the inputs for everything else in the Design & Architecture phase. Skipping it produces incorrect components that look right but solve the wrong problem.
Why This Phase Matters
The cost of a requirement change increases by roughly an order of magnitude at each stage of development. A change identified during requirements analysis might take 30 minutes to document. The same change discovered during implementation costs hours of rework. If it reaches production, it costs testing, deployment, and potential user impact.
Frontend requirements analysis specifically must address three dimensions: what the user does (interaction model), what the system shows (data and states), and how it performs (non-functional constraints). All three are required.
Do not confuse requirements with solutions. "The page needs a table" is a solution. "The user needs to compare 20+ items simultaneously across 8 attributes" is a requirement. The solution might be a table, a card grid, or a custom comparison interface — and that decision belongs in the design phase, not the requirements phase.
Stakeholder Interviews
Structured interviews with product owners, business stakeholders, and engineering leads surface the constraints and priorities that never appear in a feature ticket.
Key questions to ask
| Category | Question | What it reveals |
|---|---|---|
| Business | Who are the primary users and what is their technical level? | Complexity ceiling, terminology to use |
| Business | What metric does this feature move? | True success criteria beyond task completion |
| Business | What is the cost of downtime or data loss for this feature? | Reliability and data persistence requirements |
| Technical | What APIs or data sources does this depend on? | Loading states, error states, latency expectations |
| Technical | Are there existing design system constraints? | Component reuse vs. new components |
| Technical | What browsers and devices must be supported? | Progressive enhancement requirements |
| Scope | What is explicitly out of scope for v1? | Prevents scope creep during implementation |
| Scope | What does success look like in 6 months? | Flexibility and extensibility requirements |
User Research Methods
The appropriate research method depends on the question being answered and the time available. Do not default to user interviews for every question — many questions are better answered by analytics or usability testing.
| Method | Best for | Time required | Output |
|---|---|---|---|
| Analytics review | Identifying where users drop off or struggle today | Hours | Quantitative usage patterns |
| User interviews (5-8 users) | Understanding mental models and workflows | 1–2 days | Qualitative insights, jobs-to-be-done |
| Contextual inquiry | Observing users in their actual work environment | 2–3 days | Workflow maps, pain points |
| Card sorting | Determining how users expect information to be organized | Half day | Navigation and IA structure |
| Tree testing | Validating an existing or proposed IA structure | Half day | Navigation success rates |
| Usability testing | Validating a prototype against real tasks | 1 day | Task completion rates, failure points |
AI agents can accelerate requirements gathering. Give an agent rough stakeholder notes and ask for structured functional requirements in FR-XX format with Given/When/Then acceptance criteria. Agents also excel at identifying implicit non-functional requirements (performance, accessibility, security) that stakeholders rarely mention. Always review and adjust — but starting from a structured draft is faster than a blank page.
Functional Requirements
Functional requirements describe what the UI must do. Write them in the form: "The system shall [action] when [condition] so that [outcome]." This format makes each requirement testable and traceable.
FR-01: The dashboard shall display the user's last 30 days of activity data
upon successful authentication.
FR-02: The dashboard shall update activity data without a full page reload
when the user changes the date range filter.
FR-03: The dashboard shall display a non-blocking error notification when
the activity API returns an error, and show the last successfully
fetched data with a stale indicator.
FR-04: The dashboard shall allow export to CSV for any visible date range,
initiating a file download within 3 seconds for datasets up to 10,000 rows.
FR-05: The dashboard shall preserve the user's filter state across browser
sessions using URL search parameters.Non-Functional Requirements
Non-functional requirements (NFRs) define the quality constraints of the interface. They are frequently undocumented, which means they default to "whatever was built" — a poor standard. Document them explicitly.
| Category | Metric | Target (example) |
|---|---|---|
| Performance | Largest Contentful Paint (LCP) | Under 2.5 seconds on 4G mobile |
| Performance | Time to Interactive (TTI) | Under 3.5 seconds on low-end device |
| Performance | JavaScript bundle (initial load) | Under 200KB gzipped |
| Availability | Uptime SLA | 99.9% (8.7 hrs downtime/year) |
| Accessibility | WCAG conformance | Level AA minimum |
| Accessibility | Keyboard navigation | All interactive elements reachable |
| Browser support | Minimum supported browsers | Last 2 versions of Chrome, Firefox, Safari, Edge |
| Responsiveness | Breakpoints, strategy, touch targets | See Responsive Design for patterns and testing |
| Security | Content Security Policy | Strict CSP, no inline scripts |
| Internationalisation | Language support | English + French for v1 |
Acceptance Criteria
Acceptance criteria translate requirements into testable conditions. Write them in Given / When / Then (Gherkin) format. Every acceptance criterion becomes a test case — either automated or manual.
Feature: Dashboard error handling
Scenario: API failure with existing cached data
Given the user has previously loaded the dashboard
And the activity API returns a 503 error
When the dashboard attempts to refresh data
Then a toast notification appears with text "Unable to refresh data"
And the toast is dismissable
And the previously loaded data remains visible
And a "Data from [timestamp]" label appears below the chart
Scenario: API failure with no cached data
Given the user has no cached dashboard data
And the activity API returns an error
When the dashboard first loads
Then an inline error state replaces the chart area
And a "Retry" button is visible
And clicking "Retry" re-attempts the API callOutput Artifacts
Requirements analysis is complete when these documents exist and have been reviewed by both engineering and product stakeholders.
-
Requirements Document A structured document listing all functional requirements (FR-XX), non-functional requirements (NFR-XX), and explicit out-of-scope items. Version-controlled in the repository under
docs/requirements.md. -
Acceptance Criteria One or more Given/When/Then scenarios per functional requirement. These are the definition of done for each feature and become the basis for integration tests.
-
Constraint Inventory A list of all NFRs with their numeric targets, the rationale behind each target, and the measurement method (Lighthouse, WebPageTest, manual testing, etc.).
-
Open Questions Log Any unresolved questions that would block implementation. Each entry must have an owner and a resolution date. No open question should survive past the start of the design system phase.