To put it as simply as Dalip Mahal does in this blog post, if a functional requirement is what creates code which addresses the needs of the customer, non-functional requirements address the needs of those who install, operate, or configure that code.
Or, to think of it in another way, non-functional requirements are what make functional requirements work, as they help the people who meet the requirements work.
But what falls into the non-functional requirements, specifically? Mahal explains how they concern time, memory, access, and location. So, in this case: performance, availability, capacity, continuity, and security. These might seem familiar, as the last 4 items deal with the warranty and utility of the service.
Mahal then moves into explaining the non-functional requirements, starting with availability:
Availability is about making sure that a service is available when it is supposed to be available. Availability is about a Configuration Item (CI) in the environment of the operations center that specifies how the code is accessed. Availability is decided independently of the code and is at best part of the Service Design Package (SDP) that is delivered to the operations department, at worst it is simply code dumped on the operations personnel.
Developer’s need to be aware of the difficulty of creating the CI for the operations personnel. If a CI is manually created then there will always be a potential for an error when the service is installed or updated. The requirement to create a CI is a non-functional requirement and the ability to minimize errors is another non-functional requirement.
The blog post then moves through all of the non-functional requirement areas, explaining what they are and how they are handled. Mahal then shares what happens when you forget non-functional requirements: more work later in the process of creation.
To read the whole post, click here: http://accelerateddevelopment.ca/blog/what-the-heck-are-non-functional-requirements/