How Architects See Non-Functional Requirements: Beware of Modifiability

  • Eltjo R. Poort
  • Nick Martens
  • Inge van de Weerd
  • Hans van Vliet
Part of the Lecture Notes in Computer Science book series (LNCS, volume 7195)


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).


Software Architecture Requirements Management Software Project Management NFR Modifiability Empirical Software Engineering 


Unable to display preview. Download preview PDF.

Unable to display preview. Download preview PDF.


  1. 1.
    Bass, L., Clements, P., Kazman, R.: Software Architecture in Practice, 2nd edn. Addison Wesley (2003)Google Scholar
  2. 2.
    Berntsson Svensson, R.: Managing Quality Requirements in Software Product Development. PhD thesis, Department of Computer Science, Lund University (2009)Google Scholar
  3. 3.
    Centraal Bureau voor de Statistiek. Nationale rekeningen 2006 (2007)Google Scholar
  4. 4.
    Chung, L., Nixon, B., Yu, E.S., Mylopoulos, J.: Non-Functional Requirements in Software Engineering. Kluwer Academic (1999)Google Scholar
  5. 5.
    Cronbach, L.J.: Coefficient alpha and the internal structure of tests. Psychometrika 16(3), 297–334 (1951)CrossRefGoogle Scholar
  6. 6.
    Dvir, D., Raz, T., Shenhar, A.J.: An empirical analysis of the relationship between project planning and project success. International Journal of Project Management 21, 89–95 (2003)CrossRefGoogle Scholar
  7. 7.
    Fairbanks, G.: Just Enough Architecture: The Risk-Driven Model. Crosstalk (November/December 2010)Google Scholar
  8. 8.
    Glinz, M.: On non-functional requirements. In: 15th IEEE International Requirements Engineering Conference RE 2007, pp. 21–26. IEEE (2007)Google Scholar
  9. 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. 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
  11. 11.
    Lawrence, B., Wiegers, K., Ebert, C.: The top risks of requirements engineering. IEEE Softw. 18(6), 62–63 (2001)CrossRefGoogle Scholar
  12. 12.
    Leffingwell, D.: Calculating your return on investment from more effective requirements management. American Programmer 10(4), 13–16 (1997)Google Scholar
  13. 13.
    Leung, H.K.N.: Quality metrics for intranet applications. Information and Management 38(3), 137–152 (2001)CrossRefGoogle Scholar
  14. 14.
    McCabe, T.: A complexity measure. IEEE Transactions on Software Engineering 2, 308–320 (1976)MathSciNetCrossRefGoogle Scholar
  15. 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
  16. 16.
    Mylopoulos, J., Chung, L., Nixon, B.: Representing and using nonfunctional requirements: A process-oriented approach. IEEE Trans. Softw. Eng. 18(6), 483–497 (1992)CrossRefGoogle Scholar
  17. 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. 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
  19. 19.
    Sheldon, F.T., Kavi, K.M., Tausworth, R.C., Yu, J.T., Brettschneider, R., Everett, W.W.: Reliability measurement: From theory to practice. IEEE Software 9(4), 13–20 (1992)CrossRefGoogle Scholar
  20. 20.
    Westland, J.C.: The cost of errors in software development: evidence from industry. Journal of Systems and Software 62(1), 1–9 (2002)CrossRefGoogle Scholar

Copyright information

© Springer-Verlag Berlin Heidelberg 2012

Authors and Affiliations

  • Eltjo R. Poort
    • 1
  • Nick Martens
    • 2
  • Inge van de Weerd
    • 2
  • Hans van Vliet
    • 3
  1. 1.LogicaAmstelveenThe Netherlands
  2. 2.Utrecht UniversityThe Netherlands
  3. 3.VU UniversityAmsterdamThe Netherlands

Personalised recommendations