A brief mixes two kinds of statement and hands them to you as one list. A functional requirement names a behaviour: the system accepts an order, sends a receipt, refuses an expired card. You can check it with one input and one expected output, and it is either present or absent. A quality attribute is not a behaviour at all. It is a property of how every behaviour is delivered: how fast, how often the system is reachable, how safely, how cheaply, how easily a person can change it later. The same function can be built ten ways that are all functionally correct and wildly different in quality. This distinction matters because functional requirements almost never decide a structure, and quality attributes almost always do. Two systems that accept orders identically will look nothing alike if one must answer within fifty milliseconds and the other may take a minute. It is the fifty-millisecond figure, not the word order, that forces a copy of the data close to the reader, a different storage layout, and work moved out of the request. A designer who lists only functions ends up with a shape chosen by habit rather than by need. After this Concept you can take any line in a brief, say which of the two kinds it is, and explain why the quality lines are the ones that will shape your components.
In requirements engineering, requirements collected from an application domain are classified into functional requirements, which specify what a system computes or does and generally admit well-defin…