It occurred to me a while back that there are two distinct categories of requirements: Those that are deemed necessary and can be categorically verified, and those that are more lofty and more difficult to test.
I suggest that the first set are called Imperative Requirements, or simply requirements. These are binary in nature, either they make it into the system or they don't--a test case can be written that will pass or fail. Use cases and functional requirements fall into this category, as well as performance, reliability, security, and perhaps other non-functional areas as well.
The second category, which I'll call Non-Imperative Requirements (or maybe just Qualities), are different. They can not be tested or verified in any straight forward way, but rather are qualities to shoot for. Scalability, maintainability, useability, and ease-of-development, for example, fall into this category. These Qualities are better expressed as goals with relative importance. Those less verifiable, these need not be completely useless. Qualities can be expressed with relative importance weights, and still traced with a correlation matrix.
In future posts, I plan on fleshing out my idea of a requirements model, especially regarding how requirements should be systematically addressed in architecture.
