Functional Requirements

Functional requirements answer the question “what?”

Functional requirements describe the actions the system must be able to perform from the perspective of a user, another system, or a business process. They do not say how fast this happens or how many users the service can handle — they capture the function itself.

For a URL shortener, a basic set might look like this:

• a user can create a short link for a long URL;
• when a short address is opened, the system redirects to the original URL;
• a link can have an expiration time;
• the owner can delete their link.

A requirement is better expressed as observable behavior

The phrase “we need a links table in PostgreSQL” is not a functional requirement. That is already one possible implementation. A real requirement should remain true even if we completely change the internal architecture tomorrow.

Bad:  Store links in PostgreSQL.
Good: After a short link is created, it must redirect to the saved original URL.

This separation matters: when we turn a requirement into a specific technology too early, we reduce the space of possible solutions ourselves.

Core and additional scenarios

Not all features are equally important. At the beginning of design, it is useful to identify a few core scenarios without which the product loses its purpose, and separate them from additional capabilities.

For a messenger, for example, sending and receiving messages is the core of the system. Search through history, reactions, and message editing also matter, but they can be discussed after the main data flow is clear.

Do not forget other participants

A system interacts with more than just the end user. Functional requirements can describe the work of an administrator, a background job, a payment provider, or another service. If such a participant affects a key scenario, its actions should be included in the requirements as well.