How Architects See Non-Functional Requirements: Beware of Modifiability
This paper presents the analysis and key findings of a survey about dealing with non-functional requirements (NFRs) among architects. We find that, as long as the architect is aware of the importance of NFRs, they do not adversely affect project success, with one exception: highly business critical modifiability tends to be detrimental to project success, even when the architect is aware of it. IT projects where modifiability is perceived to have low business criticality lead to consistently high customer satisfaction. Our conclusion is that modifiability deserves more attention than it is getting now, especially because in general it is quantified and verified considerably less than other NFRs. Furthermore, IT projects that applied NFR verification techniques relatively early in development were more successful on average than IT projects that did not apply verification techniques (or applied it relatively late in development).
KeywordsSoftware Architecture Requirements Management Software Project Management NFR Modifiability Empirical Software Engineering
Unable to display preview. Download preview PDF.
- 1.Bass, L., Clements, P., Kazman, R.: Software Architecture in Practice, 2nd edn. Addison Wesley (2003)Google Scholar
- 2.Berntsson Svensson, R.: Managing Quality Requirements in Software Product Development. PhD thesis, Department of Computer Science, Lund University (2009)Google Scholar
- 3.Centraal Bureau voor de Statistiek. Nationale rekeningen 2006 (2007)Google Scholar
- 4.Chung, L., Nixon, B., Yu, E.S., Mylopoulos, J.: Non-Functional Requirements in Software Engineering. Kluwer Academic (1999)Google Scholar
- 7.Fairbanks, G.: Just Enough Architecture: The Risk-Driven Model. Crosstalk (November/December 2010)Google Scholar
- 8.Glinz, M.: On non-functional requirements. In: 15th IEEE International Requirements Engineering Conference RE 2007, pp. 21–26. IEEE (2007)Google Scholar
- 9.Grady, R.B.: An economic release decision model: Insights into software project management. In: Proceedings of the Applications of Software Measurement Conference, Orange Park, Software Quality Engineering, pp. 227–239 (1999)Google Scholar
- 10.Johansson, E., Wesslén, A., Bratthall, L., Höst, M.: The importance of quality requirements in software platform development - a survey. In: HICSS 2001: Proceedings of the 34th Annual Hawaii International Conference on System Sciences, vol. 9, p. 9057. IEEE Computer Society, Washington, DC (2001)Google Scholar
- 12.Leffingwell, D.: Calculating your return on investment from more effective requirements management. American Programmer 10(4), 13–16 (1997)Google Scholar
- 15.Mylopoulos, J.: Goal-oriented requirements engineering, part ii. In: RE 2006: Proceedings of the 14th IEEE International Requirements Engineering Conference, IEEE Computer Society, Washington, DC (2006)Google Scholar
- 17.Paech, B., Detroit, A., Kerkow, D., von Knethen, A.: Functional requirements, non-functional requirements, and architecture should not be separated - a position paper. In: REFSQ, Essen, Germany (September 2002)Google Scholar
- 18.Paech, B., Kerkow, D.: Non-functional requirements engineering - quality is essential. In: 10th Anniversary International Workshop on Requirements Engineering: Foundation for Software Quality (2004)Google Scholar