Often teams approach NFRs using a boil-the-ocean approach - in which case, all NFRs are treated equally (at best) - or ignored (at worst) by the developers en masse due to the sheer volume of NFRs specified.
Today I happened across a paper that was published in March 2012 as part of the
20th IEEE International
Requirements Engineering Conference
September 24th-28th, 2012. Chicago, Illinois, USA.
NON-FUNCTIONAL REQUIREMENTS IN SOFTWARE ARCHITECTURE PRACTICE
Departament d’Enginyeria de Serveis i Sistemes d’Informació
Software Engineering for Information Systems Group
Universitat Politècnica de Catalunya (GESSI-UPC)
INRIA - École des Mines de Nantes
A slide presentation is also available:
A few interesting quotes from the paper:
- "Our interviews show that in 10 out of the 13 projects considered, the software architect was the main source of the NFRs."
- "Architects did not share a common vocabulary for types of NFRs and showed some misunderstandings."
- "The two most important types of technical NFRs for architects were performance and usability. On the other hand, architects considered non-technical NFRs to be as relevant as technical NFRs."
- "Inability to interpret some particular term, e.g., “availability”, “accuracy”, and “sustainability”, requiring additional explanations from the interviewers"
- "Use of a term with an incorrect definition. We found a serious confusion in the answer, e.g., “Maintainability is very important, because when something is working, we can’t make changes”
Other Resources Mentioned in the Paper
Volare Requirements Specification Template
ISO/IEC 9126 Software engineering - Product quality
ISO/IEC 9126 in practice: what do we need to know?
Other Web Resource Links