Requirements are often organized into two categories: Functional and Non-Functional.
As the name suggests, a functional requirement is a function that a system can perform.
We can think of a functional requirement as a mathematical function of the form:

For example:

This is a convenient view for testing purposes because we can feed a function a list of pre-determined inputs and compare the outputs with the expected outputs.
In reality, a system function gathers its inputs from a dialog with the user. The nature of this dialog must be carefully specified. Also, the output might be multi-faceted, including updates to the system data and updates of all open views of the system data. (Think of the difference between the compute-tax function above and TurboTax!) For this reason functional requirements are often expressed in the form of use cases.
Non-functional requirements can be grouped as follows:
Usability answers the question:
Is it needlessly difficult to understand how to use the system?
Usability can be improved with help systems, good documentation, tutorials, and a well thought out user interface.
There are deeper usability factors though. For example:
Uniformity: do similar functions work in similar ways?
Click counts: on average, how many mouse clicks are required to perform an operation?
Deeper still is impedance mismatch: does the workflow imposed by the system match the workflow of the system being replaced (even if that system was a paper system)?
Reliability answers questions like:
How often will the system fail?
How catastrophic will the failures be?
How accurate are results produced by the system?
Performance answers questions like:
How fast will operations be performed?
How much memory will the system use?
How many transactions can be performed in a given length of time?
How long will users have to wait to access the system?
Supportability answers questions like:
How easy will it be for people to fix bugs? Add new features? Adapt to changes in the operating environment?
How easy will it be for people to test the system?
These in turn depend on the answer to the questions:
Is it needlessly difficult to understand the system's design?
Can the design be extended without needing to be modified?