How Do Software Architects Specify and Validate Quality Requirements?

  • Andrea Caracciolo
  • Mircea Filip Lungu
  • Oscar Nierstrasz
Part of the Lecture Notes in Computer Science book series (LNCS, volume 8627)


Software architecture is the result of a design effort aimed at ensuring a certain set of quality attributes. As we show, quality requirements are commonly specified in practice but are rarely validated using automated techniques. In this paper we analyze and classify commonly specified quality requirements after interviewing professionals and running a survey. We report on tools used to validate those requirements and comment on the obstacles encountered by practitioners when performing such activity (e.g., insufficient tool-support; poor understanding of user’s needs). Finally we discuss opportunities for increasing the adoption of automated tools based on the information we collected during our study (e.g., using a business-readable notation for expressing quality requirements; increasing awareness by monitoring non-functional aspects of a system).


Software architecture empirical study quality requirements validation 


Unable to display preview. Download preview PDF.

Unable to display preview. Download preview PDF.


  1. 1.
    Ameller, D., Ayala, C., Cabot, J., Franch, X.: How do software architects consider non-functional requirements: An exploratory study. In: 2012 20th IEEE International Requirements Engineering Conference (RE), pp. 41–50 (September 2012)Google Scholar
  2. 2.
    Boucké, N., Garcia, A., Holvoet, T.: Composing structural views in xADL. In: Moreira, A., Grundy, J. (eds.) Early Aspects Workshop 2007 and EACSL 2007. LNCS, vol. 4765, pp. 115–138. Springer, Heidelberg (2007)Google Scholar
  3. 3.
    Carrière, S.J., Kazman, R.: The perils of reconstructing architectures. In: Proceedings of the Third International Workshop on Software Architecture, ISAW 1998, pp. 13–16. ACM, New York (1998)CrossRefGoogle Scholar
  4. 4.
    Creswell, J.W., Vicki: Designing and Conducting Mixed Methods Research, 1st edn. Sage Publications, Inc. (August 2006)Google Scholar
  5. 5.
    Feiler, P., Gluch, D., Hudak, J., Lewis, B.: Embedded systems architecture analysis using SAE AADL. Technical Report CMU/SEI-2004-TN-005, Software Engineering Institute, Carnegie Mellon University, Pittsburgh, Pennsylvania (2004)Google Scholar
  6. 6.
    Feiler, P., Gluch, D., Woodham, K.: Case study: Model-based analysis of the mission data system reference architecture. Technical Report CMU/SEI-2010-TR-003, Software Engineering Institute, Carnegie Mellon University, Pittsburgh, Pennsylvania (2010)Google Scholar
  7. 7.
    Feiler, P.H., Gluch, D.P., Hudak, J.J.: The architecture analysis & design language (AADL): An introduction. Technical report, DTIC Document (2006)Google Scholar
  8. 8.
    Garlan, D., Monroe, R.T., Wile, D.: Acme: Architectural description of component-based systems. In: Leavens, G.T., Sitaraman, M. (eds.) Foundations of Component-Based Systems, ch. 3, pp. 47–67. Cambridge University Press, New York (2000)Google Scholar
  9. 9.
    Gasparis, E., Nicholson, J., Eden, A.: Lepus3: An object-oriented design description language. In: Stapleton, G., Howse, J., Lee, J. (eds.) Diagrams 2008. LNCS (LNAI), vol. 5223, pp. 364–367. Springer, Heidelberg (2008)CrossRefGoogle Scholar
  10. 10.
    Haigh, M.: Software quality, non-functional software requirements and it-business alignment. Software Quality Control 18(3), 361–385 (2010)CrossRefMathSciNetGoogle Scholar
  11. 11.
    ISO/IEC. ISO/IEC 25010 — Systems and software engineering - Systems and software Quality Requirements and Evaluation (SQuaRE) — System and software quality models (2010)Google Scholar
  12. 12.
    Kruchten, P.B.: The 4+1 view model of architecture. IEEE Software 12(6), 42–50 (1995)CrossRefGoogle Scholar
  13. 13.
    Magee, J., Dulay, N., Eisenbach, S., Kramer, J.: Specifying distributed software architectures. In: Botella, P., Schäfer, W. (eds.) ESEC 1995. LNCS, vol. 989, pp. 137–153. Springer, Heidelberg (1995)CrossRefGoogle Scholar
  14. 14.
    Malavolta, I., Lago, P., Muccini, H., Pelliccione, P., Tang, A.: What industry needs from architectural languages: A survey. IEEE Transactions on Software Engineering 39(6), 869–891 (2013)CrossRefGoogle Scholar
  15. 15.
    Marinescu, R., Ganea, G.: inCode.Rules: An agile approach for defining and checking architectural constraints. In: 2010 IEEE International Conference on Intelligent Computer Communication and Processing (ICCP), pp. 305–312 (August 2010)Google Scholar
  16. 16.
    Mens, K., Kellens, A.: IntensiVE, a Toolsuite for Documenting and Checking Structural Source-Code Regularities. In: Proceedings of the 10th European Conference on Software Maintenance and Reengineering, CSMR, pages 10, pp. 239–248 (2006)Google Scholar
  17. 17.
    Miles, M.B., Huberman, M.: Qualitative Data Analysis: An Expanded Sourcebook, 2nd edn. Sage Publications, Inc. (1994)Google Scholar
  18. 18.
    Poort, E.R., Martens, N., van de Weerd, I., van Vliet, H.: How architects see non-functional requirements: Beware of modifiability. In: Regnell, B., Damian, D. (eds.) REFSQ 2011. LNCS, vol. 7195, pp. 37–51. Springer, Heidelberg (2012)Google Scholar
  19. 19.
    Svensson, R., Gorschek, T., Regnell, B., Torkar, R., Shahrokni, A., Feldt, R.: Quality requirements in industrial practice — an extended interview study at eleven companies. IEEE Transactions on Software Engineering 38(4), 923–935 (2012)CrossRefGoogle Scholar
  20. 20.
    Terra, R., Valente, M.T.: A dependency constraint language to manage object-oriented software architectures. Software Practice Experience 39(12), 1073–1094 (2009)CrossRefGoogle Scholar
  21. 21.
    Voelter, M.: Architecture as language: A story. InfoQ (February 2008)Google Scholar

Copyright information

© Springer International Publishing Switzerland 2014

Authors and Affiliations

  • Andrea Caracciolo
    • 1
  • Mircea Filip Lungu
    • 1
  • Oscar Nierstrasz
    • 1
  1. 1.Software Composition GroupUniversity of BernBernSwitzerland

Personalised recommendations