On Non-Functional Requirements in Software Engineering
Lawrence Chung and Julio Cesar Sampaio do Prado Leite
Mylopoulos Festschrift, LNCS 5600 2009

Now, what should a software practitioner do then, when even well-known
classification
schemes are inconsistent with one another, not only terminologically but also
categorically?
A software practitioner should be aware of some of the well known
classification
schemes, such as ISO 9126 - an international standard for the evaluation
of software
quality, and consider one or more to adopt with some tailoring. No matter
what classification
scheme a software practitioner might choose to adopt, the most important
thing to bear in mind is that s/he should know what s/he means by an NFR
term, such
as performance, so that the meaning of such an NFR can be communicated
with the
user as well as with system/software developers so that the end product
will behave as
expected.

---------------
14. ISO/IEC 9126-1:2001(E):
Software Engineering - Product Quality - Part 1: Quality Model(2001)

15. Jureta, I.J., Faulkner, S., Schobbens, P.-Y.: A more expressive
softgoal conceptualization
for quality requirements analysis. In: Embley, D.W., Olivé, A., Ram, S.
(eds.) ER 2006.
LNCS, vol. 4215, pp. 281–295. Springer, Heidelberg (2006)

16. Roman, G.-C.: A Taxonomy of Current Issues in Requirements
Engineering. IEEE Computer,14–21 (April 1985)

17. Boehm, B.W., Brown, J.R., Kaspar, H., Lipow, M., MacLeod, G.J.,
Merritt, M.J.:
Characteristics of Software Quality. North-Holland, Amsterdam (1978)

18. Grady, R., Caswell, D.: Software Metrics: Establishing a Company-wide
Program.
Prentice-Hall, Englewood Cliffs (1987)

19. Bowen, T.P., Wigle, G.B., Tsai, J.T.:
Specification of Software Quality Attributes, Report
RADC-TR-85-37, vol. I (Introduction), vol. II
(Software Quality Specification Guidebook),
vol. III (Software Quality Evaluation Guidebook),
Rome Air Development Center,
Griffiss Air Force Base, NY (February 1985)

20. Bass, L., Nord, R., Wood, W., Zubrow, D.: Risk Themes Discovered
Through Architecture
Evaluations, Technical Report CMU/SEI-2006-TR-012, ESC-TR-2006-012 (2006)
--------------

http://www.ibm.com/developerworks/rational/library/4706.html

Functional Requirements

These requirements generally represent the main product features. In a
warehouse application, we might have requirements pertaining to order
processing or stock control, for example. However, functional requirements
are not always domain-specific. Providing printing capability is a
functional requirement of particular significance to architecture, for
example.

Table 1 lists additional functional requirements that might be considered.
Table 1: Architecturally Significant Functional Requirements
Function        Description