Functional requirements: describe the quantitative tasks the system is to perform. These are likely to be based on physical (and readily measurable) quantities.

Nonfunctional requirements: describe how the system fits into its context:

• how it's viewed by its users
• how it interfaces with other systems
• how it's prioritized by the organization

The nonfunctional requirement is an attribute of the system or its environment. (e.g. "ilities" -- reliability, usability, portability, flexibility, scalability, maintainability) This requirement tends to be based on perspectives and possibly even feelings. It can sometimes be made into (or close to) a functional requirement through adding measurable details, though

• this is a limiting factor: too much detail and a requirement becomes more easily bypassed
• you can't always convert a nonfunctional requirement; don't assume you can

Another way of looking at the difference is to consider functional requirements as objectives, and nonfunctional requirements as constraints.

Traceability

In some engineering environments, part of the "big picture" of requirements is the making of an historical record of the design process. In that case, every non-trivial aspect of a design can be traced back to some requirement that was previously agreed upon by the engineers and other stakeholders.

The advantages of traceability in engineering design:

• settles arguments
• may prevent litigation (especially in the case of failures)
• enables re-use of some design characteristics (the fact that "the last model had A" isn't sufficient to justify giving A to the next model; if A is traced to a requirement it's like saying "the last model had A BECAUSE...")
• can prevent adding features just because we can
• can prevent "reinventing the wheel"

Once you have traceability, you generally have some formal process when requirements must be changed. (Many engineers I've met would rather avoid that process; this means the justification for the change is critical.) Traceability may provide a more efficient "buy-in" to design changes than you'd see otherwise.