I'm not familiar with how the IREB teaches requirements engineering or the content that they recommend for learning about requirements engineering. I'm familiar with software requirements engineering from the works of Karl Wiegers and Joy Beatty, Anthony Chen and Joy Beatty, and Stephen Withall in addition to my own experiences gathering and analyzing requirements.
Since you know that the statement that quality requirements are elicited after the functional requirements is false, there are only two possible meanings. Either all requirements should be elicited concurrently or the quality requirements are elicited before the functional requirements.
Looking at what is considered a non-functional requirement or quality attribute, some quality attributes are specifically related to specific functionality. Examples of these may include performance and stability - a given function needs to complete in a specified amount of time or the system must be measurably responsive under certain loads or when performing certain work. Other quality attributes are more likely to affect the system as a whole - disaster recovery, fault tolerance, maintainability, security. A third set of quality attributes applies to the product and processes used - configuration management, escrow, licensing.
The statement that quality requirements are elicited before the functional requirements doesn't make sense. It's hard to talk about specific performance requirements in a manner that makes for a good requirement unless you are talking about functionality either first or concurrently.
Therefore, the intention is the recognize that quality attributes should be elicited from stakeholders concurrently with functional requirements. However, discussing some characteristics of requirements (such as completeness or consistency) must be done in a context that includes all of the requirements - functional and non-functional.