Each requirement is simply stated in english. Each requirement must be objective and quantifiable; there must be some measurable way to assess whether the requirement has been met.
Often deciding on quality attributes requires making tradeoffs, e.g., between performance and maintainability. In the APPENDIX you must include an engineering analysis of any significant decisions regarding tradeoffs between competing attributes.
Here are some examples of non-functional requirements:
Requirements about resources required, response time, transaction rates, throughput, benchmark specifications or anything else having to do with performance.
List any run-time constraints. This could include system resources, people, needed software, ...
Discuss the target platform. Be as specific or general as the user requires. If the user doesn't care, there are still platform constraints.
Accuracy and Precision
Requirements about the accuracy and precision of the data. (Do you know the difference?) Beware of 100% requirements; they often cost too much.
Requirements about the effort required to make changes in the software. Often, the measurement is personnel effort (person- months).
The effort required to move the software to a different target platform. The measurement is most commonly person-months or % of modules that need changing.
Requirements about how often the software fails. The measurement is often expressed in MTBF (mean time between failures). The definition of a failure must be clear. Also, don't confuse reliability with availability which is quite a different kind of requirement. Be sure to specify the consequences of software failure, how to protect from failure, a strategy for error detection, and a strategy for correction.
One or more requirements about protection of your system and its data. The measurement can be expressed in a variety of ways (effort, skill level, time, ...) to break into the system. Do not discuss solutions (e.g. passwords) in a requirements document.
Requirements about how difficult it will be to learn and operate the system. The requirements are often expressed in learning time or similar metrics.
There may be legal issues involving privacy of information, intellectual property rights, export of restricted technologies, etc.
Others ... there are many others. Consult your resources.
of good and bad quality attributes, written by the fall 98 CSC 205 classes
for your viewing pleasure.
Here are some more examples.