Functional and Non-Functional Requirements

Requirements come in two kinds. A functional requirement is a behaviour: something a user or another system can do with the product. A non-functional requirement is a quality that behaviour must have, such as how quickly it responds or how rarely it is unavailable. Keeping the two in separate lists shows which parts of a design exist to add features and which exist to add qualities.

Telling them apart. Ask whether the sentence names something the system does, or describes how well it does something. "A customer can cancel an order" names an action, so it is functional. "Search results appear in under 300 milliseconds" describes an action that already exists, so it is non-functional. A useful test is to delete the requirement: if a button or a screen disappears, it was functional; if everything still works but slower, less often, or for fewer people, it was non-functional.

The non-example: "real time". "Listeners see what their friends are playing in real time" sounds like a quality, because "real time" reads like a speed. It is functional: it describes a feature, a live activity feed, that would vanish if you deleted the sentence. The quality hiding inside it is how fresh the feed must be, for example "within five seconds", and that belongs on the second list as its own line.

Why the split changes the design. Functional requirements decide which components exist: a playlist feature needs somewhere to store playlists. Non-functional requirements decide how those components are arranged: a one-second playback target decides whether songs are served from a server near the listener. Two products with identical feature lists can need very different systems, because their second lists differ.

So write the two lists separately before drawing anything, because the second list is where the design decisions come from.