Functional requirements describe what the user can do. Non-functional requirements describe how well the product must work.
Functional examples for a social feed:
- View a feed of posts.
- Like and comment on posts.
- Create a post with images.
- Load more posts on scroll.
Non-functional examples for the same feed:
- The first load stays under a set budget on a mid-range phone.
- Scrolling stays smooth with thousands of items.
- It is accessible with a keyboard and with screen readers.
- It works on flaky networks.
- It supports many languages, including RTL (right-to-left) languages like Arabic.
- Public posts have good SEO (search engine optimisation).
I ask first about scope and users:
- Which devices and network conditions do users have?
- Is it public or behind a login? If it is public, SEO matters, so I need SSR (server-side rendering).
- How fresh must the data be? Real-time, or refresh on demand?
- What is the scale? How many posts per page? Is it heavy on media, or mostly text?
Then I confirm what is out of scope, such as the ranking logic or the backend.
The answers change the design directly. For example, "mostly mobile on 3G" pushes me toward aggressive code splitting and a careful image strategy. "Real-time" adds a push channel, so the server can send new data without the client asking.
- Functional requirements are user-facing features, like liking or posting.
- Non-functional requirements are qualities: performance, a11y (accessibility), i18n (many languages), offline support and SEO.
- Asks about devices, network, data freshness and scale first.
- Says clearly what is out of scope.
- Links each answer to a concrete design decision.