Non Functional Requirements
Non-Functional requirements are those requirements that are not readily captured in use-cases as use-cases are typically functional (behavioural)in nature.
Also known as 'Supplementary Specifications' they are the URPS+ of the FURPS+ model (Functional, Usability, Reliability, Performance, Supportability), described by Robert Grady (Practical Software Metrics for Project Management and Process Improvement. Prentice-Hall.). The + being requirements concerning design constraints, implementation requirements, interface requirements and physical environment requirements or constraints.
Whereas 'Functional' requirements describe the actions that the system must be able to perform, 'Non-Functional' requirements describe attributes of the system or attributes of the system environment.
Many times there is confusion about some requirements whether they are Functional or Non-Functional, especially frequently we see that re-usable functionality often ends up in the supplementary specifications rather than in some kind of use case that should be 'included' in many others, as a short cut that usually leads to confusion.
We can use this Forum to discuss what constitutes a Non-Functional requirement and how and where to capture it (in formal or informal or Agile or ....... methodlogies)

Requirements-by-Example
I have published Requirements-by-Example, a requirements guide.
It can be found at
http://www.analisi-disegno.com/requisiti/Requirements-By-Example.htm
The goal of this guide is to help practitioners to:
- reduce time and costs to identify requirements and eventually make a
first draft requirements specification (even if the guide is
methodology independent, and does not assume the need to do a formal
documentation)
- improve requirements quality, thanks to a lot of examples drawn from
the best requirements engineering literature.
Requirements-by-Example is mostly useful for non
functional (quality attribute) requirements, often neglected in real
projects. Questions and examples help to bring down to earth the
abstraction level of the "-ilities", helping practitioners to analyze
the real needs of their projects.
The guide is open for improvements and additions, and it is
intended to grow with the collaboration of requirements
practitioners.
Adriano Comai
www.analisi-disegno.com