Non-functional requirements are essential to define the software architecture, and if they are not identified and handled correctly, the impact can be huge. This talk will present some common mistakes when handling non-functional requirements. It starts talking about the ones defined at the beginning of the project with a false certainty, which can become an even worst problem if they are never revised. Then, we will pass through the client that always wants the complete package and talk about the ones that are only remembered when some user complains. Of course, the talk does not forget about those that try to treat those very different non-functional requirements in exactly the same way. In the end, it will be presented some practices that can be used to avoid these problems.