A Structured Approach for Eliciting, Modeling, and Using Quality-Related Domain Knowledge

  • Azadeh Alebrahim
  • Maritta Heisel
  • Rene Meis
Part of the Lecture Notes in Computer Science book series (LNCS, volume 8583)


In requirements engineering, properties of the environment and assumptions about it, called domain knowledge, need to be captured in addition to exploring the requirements. Despite the recognition of the significance of capturing and using the required domain knowledge, it might be missing, left implicit, or be captured inadequately during the software development. This results in an incorrect specification. Moreover, the software might fail to achieve its quality objectives because of ignored required constraints and assumptions. In order to analyze software quality properly, we propose a structured approach for eliciting, modeling, and using domain knowledge. We investigate what kind of quality-related domain knowledge is required for the early phases of quality-driven software development and how such domain knowledge can be systematically elicited and explicitly modeled to be used for the analysis of quality requirements. Our method aims at improving the quality of the requirements engineering process by facilitating the capturing and using of implicit domain knowledge.


Quality requirements domain knowledge problem frames knowledge management requirements engineering 


Unable to display preview. Download preview PDF.

Unable to display preview. Download preview PDF.


  1. 1.
    Lamsweerde, A.: Requirements Engineering: From System Goals to UML Models to Software Specifications. Wiley (2009)Google Scholar
  2. 2.
    Zave, P., Jackson, M.: Four dark corners of requirements engineering. ACM Trans. Softw. Eng. Methodol. 6, 1–30 (1997)CrossRefGoogle Scholar
  3. 3.
    van Lamsweerde, A.: Reasoning about alternative requirements options. In: Borgida, A.T., Chaudhri, V.K., Giorgini, P., Yu, E.S. (eds.) Conceptual Modeling: Foundations and Applications. LNCS, vol. 5600, pp. 380–397. Springer, Heidelberg (2009)Google Scholar
  4. 4.
    Prieto-Díaz, R.: Domain analysis: an introduction. SIGSOFT Softw. Eng. Notes 15(2), 47–54 (1990)CrossRefGoogle Scholar
  5. 5.
    Hooks, I.F., Farry, K.A.: Customer-centered Products: Creating Successful Products Through Smart Requirements Management. AMACOM (2001)Google Scholar
  6. 6.
    Modugno, F., Leveson, N., Reese, J., Partridge, K., Sandys, S.: Integrated safety analysis of requirements specifications. In: Requirements Engineering, pp. 65–78 (1997)Google Scholar
  7. 7.
    Fabian, B., Gürses, S., Heisel, M., Santen, T., Schmidt, H.: A comparison of security requirements engineering methods. Requirements Engineering – Special Issue on Security Requirements Engineering 15, 7–40 (2010)Google Scholar
  8. 8.
    Robillard, P.N.: The Role of Knowledge in Software Development. Commun. ACM 42, 87–92 (1999)CrossRefGoogle Scholar
  9. 9.
    Niknafs, A., Berry, D.M.: The impct of domain knowledge on the effectiveness of requirements idea generation during requirements elicitation. In: Proc. of the 20th IEEE Int. RE Conf., pp. 181–190 (2012)Google Scholar
  10. 10.
    Jackson, M.: Problem Frames. Analyzing and structuring software development problems. Addison-Wesley (2001)Google Scholar
  11. 11.
    Alebrahim, A., Choppy, C., Faßbender, S., Heisel, M.: Optimizing functional and quality requirements according to stakeholders’ goals. In: Mistrik, I. (ed.) Relating System Quality and Software Architecture, pp. 75–120. Elsevier (2014)Google Scholar
  12. 12.
    Alebrahim, A., Heisel, M.: A problem-oriented method for performance requirements engineering using performance analysis patterns. In: FGCS (submitted, 2014)Google Scholar
  13. 13.
    Beckers, K., Faßbender, S., Heisel, M., Meis, R.: A problem-based approach for computer-aided privacy threat identification. In: Preneel, B., Ikonomou, D. (eds.) APF 2012. LNCS, vol. 8319, pp. 1–16. Springer, Heidelberg (2014)CrossRefGoogle Scholar
  14. 14.
    Meis, R.: Problem-Based Consideration of Privacy-Relevant Domain Knowledge. In: Hansen, M., Hoepman, J.-H., Leenes, R., Whitehouse, D. (eds.) Privacy and Identity 2013. IFIP AICT, vol. 421, pp. 150–164. Springer, Heidelberg (2014)CrossRefGoogle Scholar
  15. 15.
    Kreutzmann, H., Vollmer, S., Tekampe, N., Abromeit, A.: Protection profile for the gateway of a smart metering system. Technical report, BSI (2011)Google Scholar
  16. 16.
    UML Revision Task Force: OMG Unified Modeling Language (UML), Superstructure (2009),
  17. 17.
    Hatebur, D., Heisel, M.: A UML profile for requirements analysis of dependable software. In: Schoitsch, E. (ed.) SAFECOMP 2010. LNCS, vol. 6351, pp. 317–331. Springer, Heidelberg (2010)CrossRefGoogle Scholar
  18. 18.
    Alebrahim, A., Hatebur, D., Heisel, M.: Towards systematic integration of quality requirements into software architecture. In: Crnkovic, I., Gruhn, V., Book, M. (eds.) ECSA 2011. LNCS, vol. 6903, pp. 17–25. Springer, Heidelberg (2011)CrossRefGoogle Scholar
  19. 19.
    UML Revision Task Force: UML Profile for MARTE: Modeling and Analysis of Real-Time Embedded Systems (2011),
  20. 20.
    Land, L., Aurum, A., Handzic, M.: Capturing implicit software engineering knowledge. In: Proceedings of the 2001 Australian Software Engineering Conference, pp. 108–114 (2001)Google Scholar
  21. 21.
    Bass, L., Klein, M., Bachmann, F.: Quality attributes design primitives. Technical report, Software Engineering Institute (2000)Google Scholar
  22. 22.
    Bass, L., Clemens, P., Kazman, R.: Software architecture in practice. Addison-Wesley (2003)Google Scholar
  23. 23.
    International Organization for Standardization (ISO) and International Electrotechnical Commission (IEC): Common Evaluation Methodology 3.1. ISO/IEC 15408 (2009)Google Scholar
  24. 24.
    Sharp, H., Finkelstein, A., Galal, G.: Stakeholder Identification in the Requirements Engineering Process. In: DEXA Workshop, pp. 387–391 (1999)Google Scholar
  25. 25.
    Alexander, I.F., Robertson, S.: Understanding Project Sociology by Modeling Stakeholders. IEEE Software 21(1), 23–27 (2004)CrossRefGoogle Scholar
  26. 26.
    Remero, G., Tarruell, F., Mauri, G., Pajot, A., Alberdi, G., Arzberger, M., Denda, R., Giubbini, P., Rodrguez, C., Miranda, E., Galeote, I., Morgaz, M., Larumbe, I., Navarro, E., Lassche, R., Haas, J., Steen, A., Cornelissen, P., Radtke, G., Martnez, C., Orcajada, K.H., Wiedemann, T.: D1.1 Requ. of AMI. Technical report, OPEN meter proj. (2009)Google Scholar
  27. 27.
    Deconinck, G.: An evaluation of two-way communication means for advanced metering in Flanders (Belgium). In: Instrumentation and Measurement Technology Conference Proceedings (IMTC), pp. 900–905 (2008)Google Scholar
  28. 28.
    Probst, G.J.B.: Practical Knowledge Management: A Model that Works. Prism (1998)Google Scholar
  29. 29.
    Kang, K.C., Cohen, S.G., Hess, J.A., Novak, W.E., Peterson, A.S.: Feature-Oriented Domain Analysis (FODA) Feasibility Study. Technical report, Carnegie-Mellon University Software Engineering Institute (November 1990)Google Scholar
  30. 30.
    Frakes, W., Prieto-Diaz, R., Fox, C.: DARE: Domain analysis and reuse environment. Annals of Software Engineering 5(1), 125–141 (1998)CrossRefGoogle Scholar
  31. 31.
    Peng, X., Lee, S., Zhao, W.: Feature-Oriented Nonfunctional Requirement Analysis for Software Product Line. Journal of Computer Science and Technology 24(2) (2009)Google Scholar
  32. 32.
    Chung, L., Nixon, B., Yu, E., Mylopoulos, J.: Non-functional Requirements in Software Engineering. Kluwer Academic Publishers (2000)Google Scholar

Copyright information

© Springer International Publishing Switzerland 2014

Authors and Affiliations

  • Azadeh Alebrahim
    • 1
  • Maritta Heisel
    • 1
  • Rene Meis
    • 1
  1. 1.Paluno – The Ruhr Institute for Software TechnologyGermany

Personalised recommendations