The Community for Technology Leaders
RSS Icon
Issue No.02 - March-April (2013 vol.30)
pp: 61-67
David Ameller , BarcelonaTech—Universitat Politècnica de Catalunya
Claudia Ayala , BarcelonaTech—Universitat Politècnica de Catalunya
Jordi Cabot , École des Mines de Nantes
Xavier Franch , BarcelonaTech—Universitat Politècnica de Catalunya
Software architects often must work with incomplete or ill-specified non-functional requirements (NFRs) and use them to make decisions. Through this process, existing NFRs are refined or modified and new ones emerge. Although much research has centered on how software architects treat NFRs, no empirical studies have investigated the state of the practice. A survey based on interviews with 13 software architects addressed two fundamental issues: how do architects face NFRs from an engineering perspective, and how do NFRs influence their decision-making? The survey revealed that architects usually elicit NFRs themselves in an iterative process; they usually don't document the NFRs and only partially validate them.
Software, Interviews, Companies, Documentation, Educational institutions, Decision making, software architecturecontent type, nonfunctional requirements, non-functional requirements, NFR, quality requirements, architectural decisions, software engineering
David Ameller, Claudia Ayala, Jordi Cabot, Xavier Franch, "Non-functional Requirements in Architectural Decision Making", IEEE Software, vol.30, no. 2, pp. 61-67, March-April 2013, doi:10.1109/MS.2012.176
1. R. Kazman and L. Bass, Toward Deriving Software Architectures from Quality Attributes, tech. report CMU/SEI-94-TR-10, Software Eng. Inst., Carnegie Mellon Univ., 1994.
2. F. Buschmann, “Value-Focused System Quality,” IEEE Software, vol. 27, no. 6, 2010, pp. 84-86.
3. P. Kruchten, R. Capilla, and J.C. Dueñas, “The Decision View's Role in Software Architecture Practice,” IEEE Software, vol. 26, no. 2, 2009, pp. 36-42.
4. L. Chung and J.C.S. do Prado Leite, “On Non-functional Requirements in Software Engineering,” Conceptual Modeling: Foundations and Applications, A.T. Borgida et al., eds., Springer, 2009, pp. 363-379.
5. R. Conradi et al., “Reflections on Conducting an International Survey on Software Engineering,” Proc. Int'l Symp. Empirical Software Eng., IEEE, 2005, pp. 214-223.
6. D. Ameller et al., “How Do Software Architects Consider Non-functional Requirements: An Exploratory Study,” Proc. 20th IEEE Int'l Requirements Eng. Conf., IEEE, 2012, pp. 41-50.
7. U. van Heesch, and P. Avgeriou, “Mature Architecting—a Survey about the Reasoning Process of Professional Architects,” Proc. 9th Working IEEE/IFIP Conf. Software Architecture (WICSA 11), IEEE CS, 2011, pp. 260-269.
8. R.B. Svensson, T. Gorschek, and B. Regnell, “Quality Requirements in Practice: An Interview Study in Requirements Engineering for Embedded Systems,” Requirements Engineering: Foundation for Software Quality, LNC S 5512, Springer, 2009, pp. 218-232.
9. M. Ali Babar,L. Bass, and I. Gorton, “Factors Influencing Industrial Practices of Software Architecture Evaluation: An Empirical Investigation,” Software Architectures, Components, and Applications, LNC S 4880, Springer, 2007, pp. 90-107.
10. A. Borg et al., “The Bad Conscience of Requirements Engineering: An Investigation in Real-World Treatment of Non-functional Requirements,” Proc. 3rd Conf. Software Eng. Research and Practice in Sweden (SERP 03), CSREA Press, 2003, pp. 1-8.
11. B. Nuseibeh, “Weaving Together Requirements and Architectures,” Computer, vol. 34, no. 3, 2001, pp. 115-119.
12. J.P. Carvallo and X. Franch, “Extending the ISO/IEC 9126-1 Quality Model with Non-technical Factors for COTS Components Selection,” Proc. Int'l Workshop Software Quality (WoSQ 06), ACM, 2006, pp. 9-14.
13. Software Engineering—Software Product Quality Requirements and Evaluation (SQuaRE)—Guide to SQuaRE, ISO/IEC 25000, International Org. for Standardization, 2005.
16 ms
(Ver 2.0)

Marketing Automation Platform Marketing Automation Tool