Eh? About which requirement engineering process/methodology/religion are
you talking? I know one where nonfunctional requirements are called
quality requirements, but that might not necessarily be the methodology
you are talking about.

And why do you think there should be *a list* of requirements of some
kind which fits all purposes of all kinds?

There is a nice set of questions to help you enumerate application
requirements in Steve McConnell's Code Complete.  In my second edition,
it is pages 42-43.  It includes a general distinction between questions
relating to "functional" and "non-functional" requirements.  The eact
distinction may vary depending on the context.

Keep Thomas's comments in mind.  The questions that McConnell provides
are NOT a "list of nonfunctional requirements".  They are questions to
direct your creative thinking about the problem.  Requirements are
written by talking to people and understanding how the users go about
their tasks, and what the software can do to help them, and what
resources they tend to have at their disposal, etc.  If you write a
requirements document by systematically answering each of the questions
from McConnell's book without going much outside of that, you will end
up with a strikingly horrid requirements document.

Personally, I haven't written requirements documents in a long time.  I
prefer to do frequent internal releases to people who do customer
support and consulting for our customers who use our product, and get
their constant feedback on the needs of the product.  Occasionally, we
will agree deliver a specific feature for a specific feature, usually in
exchange for a sale or something like that, and that's the only time
anything gets specified all that formally.  Aside from that,
requirements documents tend to enshrine one day's concept of what
software should do over the next day's revised concept; there's really
little excuse for that, because you invariably know more on the second
day.