Functional and Non-Functional Requirements

Two Kinds of Requirements

Before you design any system, you need to know what it must do and how well it must do it.

Functional requirements describe features. They answer one question: what can a user do? In a dating app, swiping right or left is functional.

Non-functional requirements describe qualities. They answer: how fast, how big, how reliable?

Feed generation under 300ms is non-functional. It sets a speed limit and adds no new feature.

The Four Core Features

Our dating app has exactly four functional requirements. Together they form one user journey.

A user creates a profile with preferences: age range, interests, and max distance.

They view a stacked feed of potential matches, filtered by preference and location. Then they swipe right or left.

When two people both swipe right, each receives a notification about the mutual match.

Notice that each one is something a user does or experiences.

Drawing the Scope Line

Saying what you will not build matters as much as saying what you will.

For this design, three features are out of scope: photo uploads, direct messaging, and premium features.

Dating apps often have these. They are left out so the design stays focused on matching.

A clear scope line stops a design discussion from sprawling into every possible feature.

Putting Numbers on Scale

Non-functional requirements become useful when they carry numbers.

The app must scale to 20M daily active users. Each user makes about 100 swipes per day.

Multiply them and you get roughly 2B swipes per day.

That one figure tells you the load the system must handle. A vague goal like lots of users gives you nothing to design for.

No Lost Matches

The first non-functional requirement is strong consistency for swiping.

Strong consistency means every swipe is recorded reliably, so the system never loses a match.

Picture two users who both swipe right. If one swipe goes missing, neither gets the mutual match notification.

The feature exists either way. Consistency decides whether it works correctly every time.

Fast Feeds, No Repeats

Two more non-functional requirements shape the feed.

First, feed generation must take under 300ms. Users expect the next profile to appear almost instantly.

Second, the app must never re-show a previously swiped profile. Seeing someone you already passed on feels broken.

These two pull against each other. With about 100 swipes a day, a user's history keeps growing, and checking it must still fit inside 300ms.

Using This in Your Work

When you read any spec, sort each line into one of two buckets.

If it names something a user does, like swiping or getting a notification, it is functional.

If it sets a limit on speed, scale, or correctness, like under 300ms or no lost matches, it is non-functional.

Then list what is out of scope, such as direct messaging, so everyone agrees on the boundary.

In a dating app spec, the requirement "feed generation must take under 300ms" is a _____ requirement

• non-functional
• functional

Answer: non-functional

It sets a speed limit rather than adding a feature a user can do, so it is non-functional. Features like swiping are functional.

Sorting a dating app spec: "Users receive a notification on a mutual match" is _____ because it names something a user experiences. "No swipe is ever lost" is _____ because it sets a correctness limit. "Direct messaging" is _____ because the design deliberately excludes it.

Answer: Sorting a dating app spec: "Users receive a notification on a mutual match" is functional because it names something a user experiences. "No swipe is ever lost" is non-functional because it sets a correctness limit. "Direct messaging" is out of scope because the design deliberately excludes it.

Lines naming user actions or experiences are functional; lines setting limits on speed, scale, or correctness are non-functional; deliberately excluded features are listed as out of scope.

A dating app design must support 20M daily active users, each making about 100 swipes per day. Roughly how many swipes per day must the system handle?

• About 2B swipes per day
• About 200M swipes per day
• About 20B swipes per day
• About 120M swipes per day

Answer: About 2B swipes per day

20M × 100 = 2,000,000,000, about 2B swipes per day. This concrete figure gives the design a real load target, unlike a vague goal like "lots of users."