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)

'R' for Reliability
When considering the Reliability requirements of a system we should consider such factors as:
* Availability
* Predicitability
* Recoverability
* Failure (both frequency and possible severities of)
* Accuracy of the system
* MTBF (mean time between failure)
Sometimes teams get the Software Architect or Technical Team to address these issues, but whomever collects the requirements we still have to understand what the business requires in terms of the 'Reliability' of the system.