Website Requirements: A Practical Guide for Non-Technical Teams

A requirement is a condition, not a feature wish

“Add advanced search” is a feature request. “A buyer must be able to narrow 600 products by application, certification, and regional availability” is a requirement.

The second version identifies the user, task, data, and successful outcome. It gives designers and engineers room to decide whether filters, guided questions, search, or a different catalogue structure solves the problem best.

Useful requirements make important behaviour testable without prescribing every implementation detail.

Begin with actors, tasks, and outcomes

List the people who use or operate the site. Include visitors and internal users such as editors, regional teams, support staff, or administrators.

For each actor, complete this sentence:

> As a [specific user], I need to [complete a task] so that [valuable outcome].

Then add the conditions that make success observable.

Example:

> As a regional editor, I need to translate an approved service page without duplicating its layout so that local content stays aligned with the primary version.

Acceptance conditions might include inherited structure, editable regional copy, translation status, preview, and permission rules.

Do not turn every sentence into a formal user story. Use the format to expose missing actors, motives, and outcomes.

Organise requirements into nine areas

1. Audience and journey requirements

State the priority tasks, entry points, and decisions the experience must support.

• Which visitor groups take priority?
• What questions must each answer?
• Which journeys are business-critical?
• What should happen after a successful action?
• Which failures require a recovery path?

Avoid requirements such as “three clicks to everything”. Some tasks deserve depth. Require clear paths and test them with representative users.

2. Content requirements

Define what content exists as structured information rather than a list of pages.

Identify:

• content types such as services, products, cases, people, locations, articles, and reports;
• fields and relationships;
• required and optional information;
• ownership, review, expiry, and archive rules;
• languages and regional variation;
• migration and redirect decisions.

“Editors can build any layout” sounds flexible. It often creates inconsistency. Specify the recurring publishing jobs the CMS must make safe and fast.

3. Functional requirements

Describe the behaviour the system must provide: forms, search, filtering, accounts, bookings, payments, calculators, downloads, or saved states.

For each function, document:

1. trigger;
2. inputs;
3. rules;
4. output;
5. success state;
6. validation and failure states;
7. permissions;
8. analytics event.

This exposes complexity hidden behind labels such as “simple form” or “customer login”.

4. Integration and data requirements

Name the source of truth and how information moves.

Include API availability, rate limits, test environments, data retention, and the person who can resolve questions about the external system.

5. Accessibility requirements

Name the current standard and the validation approach. For most public projects, WCAG 2.2 is the relevant W3C recommendation; select the conformance target with qualified accessibility and legal advice appropriate to the organisation.

Requirements should cover manual checks as well as tools: keyboard navigation, focus order, labels, errors, contrast, zoom, reduced motion, headings, landmarks, and representative assistive-technology testing.

6. Performance requirements

Define performance by representative page types, devices, and real-user conditions—not one desktop screenshot.

Include:

• Core Web Vitals expectations;
• page-weight or script budgets where useful;
• image and font handling;
• third-party script governance;
• performance monitoring after launch.

Troiana's Core Web Vitals guide explains how field and lab evidence work together.

7. Search and discovery requirements

Cover crawlability, indexability, metadata, canonicals, structured data, sitemaps, internal links, URL preservation, redirects, and social previews.

For a redesign, require an outcome for every existing URL with traffic, backlinks, conversions, or useful content. “SEO included” is not a requirement.

8. Security, privacy, and reliability requirements

Document authentication, roles, data collected, retention, consent, backups, monitoring, incident ownership, and recovery expectations. Bring security and privacy specialists into decisions that require them; a generic website checklist is not legal or security advice.

9. Operational requirements

The website must be usable by the team after launch.

Specify:

• editor roles and permissions;
• approval and preview workflows;
• documentation and training;
• hosting and deployment ownership;
• backups and monitoring;
• warranty and maintenance responsibilities;
• expected content and feature change frequency.

Prioritise by consequence

Use three levels:

• Required for launch: without it, a priority journey, obligation, or operation fails.
• Planned next: valuable, understood work that can safely follow.
• Needs validation: the need may be real, but the proposed solution is uncertain.

Do not label everything “must”. Ask what happens if the requirement waits four weeks. A concrete consequence separates priority from enthusiasm.

Add acceptance criteria

Acceptance criteria describe evidence of completion.

Weak:

> The contact form should be user-friendly.

Testable:

> The form identifies required fields before submission, preserves valid entries after an error, moves focus to the error summary, creates the CRM record once, sends the agreed confirmation, and records the successful event in analytics.

Criteria should be specific enough to test, but not so implementation-heavy that they prevent a better solution.

Track assumptions and open questions

Requirements built on an unverified assumption should say so.

Maintain four columns:

Unknown work is not a failure. Hidden unknown work is what damages estimates.

Sources

• W3C: Web Content Accessibility Guidelines 2.2
• Google Search Central: Core Web Vitals

Common questions