Functional Requirements

The top three capabilities, phrased so they map to code

A functional requirement is a statement of what a user can do, phrased so concretely that it maps to code. The template is "users should be able to X." The discipline is ruthless prioritization: pick the three capabilities that define the primary journey and defer the rest out loud. Three is not a magic number, but it is the practical ceiling for what you can design well in 45 minutes, and stating exactly three signals that you understand the product's core rather than trying to boil the ocean.

Why three and not fifteen

Every functional requirement you accept becomes an endpoint, a data path, and a chunk of your time budget. An unbounded feature list guarantees an incomplete design: you will draw ten half-boxes and finish none. Interviewers read a long list as an inability to prioritize, which is the opposite of the signal you want. The best candidates say "There are dozens of features in this product. The three that define the core loop are these, and I am deferring the rest deliberately."

Nouns become entities, verbs become endpoints

The mechanical trick that makes this phase pay off later: pull the nouns and verbs out of your requirements. The nouns become your core entities (the data model), and the verbs become your endpoints (the API). For a photo app, "users can post a photo" gives you the noun Photo and the verb post, which becomes POST /photos. This is why functional requirements are not throwaway; they are the seed of the entire design. If you phrase them well, your data model and API almost write themselves.

Consider a photo-sharing app like Instagram. The dozens of possible features include stories, reels, DMs, explore, shopping, and comments. But the core loop is:

Requirement                         Noun(s)        Verb -> Endpoint
------------------------------------------------------------------
Users can post a photo              Photo, User    POST /photos
Users can follow other users        Follow         POST /follows
Users can view a feed of photos     Feed, Photo    GET  /feed
       from people they follow

Three requirements, three nouns, three endpoints. Everything else (search, notifications, likes, stories) is a variation or an add-on that assumes these three exist. Post, follow, feed is the irreducible core. Deferring the rest is safe precisely because they do not change the shape of the core system: adding likes later is a new table and endpoint, not a redesign.

Interview nuance: Phrase requirements as user capabilities, not system features. "The system stores photos in S3" is not a functional requirement, it is an implementation detail leaking in too early. "Users can post a photo" is the requirement; where the bytes live is a design decision you make later. Keeping the requirement at the user-capability level keeps you from prematurely committing to a design before you have scoped and estimated.

One more nuance: when you defer, say why it is safe. "I am deferring likes and comments because they are additive: they do not change the post, follow, or feed data paths, so we can bolt them on without redesigning." That sentence shows you understand the architecture well enough to know what is core versus peripheral.

Recap: State exactly the three user capabilities that define the core loop as "users can X," extract nouns as entities and verbs as endpoints, and defer everything else out loud with a reason it is safe.