Sunday, December 30, 2012

2012-12-30 Sunday - NFRs

Non-Functional Requirements (NFRs) are often poorly documented, and there is often ambiguity that exists in the definitions of terms used by different team members.

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.

http://crisys.cs.umn.edu/re2012/

NON-FUNCTIONAL REQUIREMENTS IN SOFTWARE ARCHITECTURE PRACTICE
Report ESSI-TR-12-1
Departament d’Enginyeria de Serveis i Sistemes d’Informació
 http://upcommons.upc.edu/e-prints/bitstream/2117/15716/1/da-ca-jc-xf-report%20essi.pdf
by
David Ameller
Claudia Ayala
Xavier Franch
Software Engineering for Information Systems Group
Universitat Politècnica de Catalunya (GESSI-UPC)
Barcelona, Spain

and
Jordi Cabot2
AtlanMod
INRIA - École des Mines de Nantes
Nantes, France

A slide presentation is also available:
http://modeling-languages.com/how-do-software-architects-deal-with-non-functional-requirements/


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
http://www.volere.co.uk/template.htm
ISO/IEC 9126 Software engineering - Product quality
http://en.wikipedia.org/wiki/ISO/IEC_9126


Also see:

ISO/IEC 9126 in practice: what do we need to know?
http://www.essi.upc.edu/~webgessi/publicacions/SMEF%2704-ISO-QualityModels.pdf

ISO/IEC 25010:2011
http://www.iso.org/iso/home/store/catalogue_ics/catalogue_detail_ics.htm?csnumber=35733

Other Web Resource Links
http://en.wikipedia.org/wiki/Non-functional_requirement





No comments: