Artefact-based requirements engineering: the AMDiRE approach

Abstract

The various influences in the processes and application domains make requirements engineering (RE) inherently complex and difficult to implement. In general, we have two options for establishing an RE approach: We can either establish an activity-based RE approach, or we can establish an artefact-based one where project participants concentrate on the RE artefacts rather than on the way of creating them. While a number of activity-based RE approaches have been proposed in recent years, we have gained much empirical evidence and experiences about the advantages of the artefact-based paradigm for RE. However, artefact orientation is still a young paradigm with various interpretations and practical manifestations whereby we need a clear understanding of its basic concepts and a consolidated and evaluated view on the paradigm. In this article, we contribute an artefact-based approach to RE [artefact model for domain-independent RE (AMDiRE)] that emerges from 6 years of experiences in fundamental and evidence-based research. To this end, we first discuss the basic notion of artefact orientation and its evolution in recent years. We briefly introduce a set of artefact-based RE models we developed in industrial research cooperations for different application domains and show their empirical evaluations and their dissemination into academia and practice, eventually leading to the AMDiRE approach. We conclude with a discussion of experiences we made during the development and different industrial evaluations, and lessons learnt.

This is a preview of subscription content, access via your institution.

Fig. 1
Fig. 2
Fig. 3
Fig. 4
Fig. 5
Fig. 6
Fig. 7
Fig. 8
Fig. 9
Fig. 10
Fig. 11
Fig. 12
Fig. 13

Notes

  1. 1.

    REMsES guide available at http://www.remses.org.

  2. 2.

    We understand learning curve in the sense of being related to the power law of practice, such that continued application will lead to learning, as defined and described in [58, p. 3/4].

  3. 3.

    http://www.projekt-aramis.de/.

  4. 4.

    http://www.nomagic.com.

References

  1. 1.

    Avison D, Fitzgerald G (2006) Information systems development: methodologies, techniques, and tools, 4th edn. McGraw-Hill Education, Berkshire

    Google Scholar 

  2. 2.

    Berenbach B, Paulish D, Kazmeier J, Rudorfer A (2009) Software and systems requirements engineering. In Practice. McGraw-Hill Osborne Media, ISBN-13: 978–0071605472

  3. 3.

    Besner V (2013) Bsc. thesis: evaluation of an artefact-based requirements engineering approach. Master’s thesis, Technische Universität München, Department of Informatics

  4. 4.

    Boegh J (2008) A new standard for quality requirements. IEEE Softw 25(2):57–63

    Article  Google Scholar 

  5. 5.

    Boehm B, Brown J, Kaspar H, Lipow M, Macleod G, Merrit M (1978) Characteristics of software quality. Elsevier Science Ltd North-Holland Pub. Co, ISBN-13: 978–0444851055

  6. 6.

    Braun C, Wortmann F, Hafner M, Winter R (2005) Method construction—a core approach to organizational engineering. In: Proceedings of the 20th ACM symposium on applied computing (SAC’05), ACM New York, NY, USA, pp 1295–1299

  7. 7.

    Braun P, Broy M, Houdek F, Kirchmayr M, Müller M, Penzenstadler B, Pohl K, Weyer T (2010) Guiding requirements engineering for software-intensive embedded systems in the automotive industry. Comput Sci Res Dev 29:21–43

  8. 8.

    Brinkkemper S (1996) Method engineering: engineering of information systems development methods and tools. Inf Softw Technol 38(4):275–280

    Article  Google Scholar 

  9. 9.

    Broy M (2006) Requirements engineering as a key to holistic Software Quality. In: Levi A, Savas E, Yenigun H, Balcisoy S, Saygin Y (eds) Proceedings of the 21st international symposium on computer and information sciences (ISCIS 2006), Springer, Berlin, vol 4263, pp 24–34

  10. 10.

    Broy M, Feilkas M, Grünbauer J, Gruler A, Harhurin A, Hartmann J, Penzenstadler B, Schätz B, Wild D (2008) Umfassendes architekturmodell für das engineering eingebetteter software-intensiver systeme. Tech Rep TUM-I0816, Technische Universität München

  11. 11.

    Cavano J, McCall J (1978) A framework for the measurement of software quality. SIGSOFT Softw Eng Notes 3(5):133–139. doi:10.1145/800283.811113

    Article  Google Scholar 

  12. 12.

    Classen A, Heymans P, Schobbens PY (2008) What’s in a feature: a requirements engineering perspective. In: Fiadeiro J, Inverardi P (eds) Proceeding of the 11th international conference on fundamental approaches to software engineering (FASE 08) in conjunction with ETAPS 08, Springer, Berlin, no. 4961 in FASE/ETAPS, pp 16–30

  13. 13.

    Cleland D (ed) (2005) Project management field guide. Wiley, ISBN-13: 978–0471292067

  14. 14.

    Cockburn A (2000) Writing effective use cases. Addison-Wesley Longman Publishing Co. Inc., ISBN-13: 978-0201702255

  15. 15.

    Deissenboeck F (2009) Continuous quality control of long-lived software systems. PhD thesis, Technische Universität München, Department of Informatics

  16. 16.

    Deissenboeck F, Juergens E, Lochmann K, Wagner S (2009) Software quality models: purposes, usage scenarios and requirements. In: Proceedings of the 7th international workshop on software quality (WoSQ 09), IEEE Computer Society Press, p N/A

  17. 17.

    Doerr J, Kerkow D, Von Knethen A, Paech B (2003) Eliciting efficiency requirements with use cases. In: Proceedings of the 9th international workshop on requirements engineering: foundation for software quality (REFSQ 03), pp 23–32

  18. 18.

    Eveleens J, Verhoef T (2010) The rise and fall of the chaos report figures. IEEE Softw 27(1):30–36

    Article  Google Scholar 

  19. 19.

    Foorthuis R, Brinkkemper S, Bos R (2009) An artifact model for projects conforming to enterprise architecture. In: Stirna J, Persson A (eds) Proceedings of the 1st working conference on the practice of enterprise modeling (POEM), Springer, vol 15, pp 30–46

  20. 20.

    Garvin D (1984) What does product quality really mean? MIT Sloan Manag Rev 26(1):25–43

    Google Scholar 

  21. 21.

    Geisberger E, Broy M, Berenbach B, Kazmeier J, Paulish D, Rudorfer A (2006) Requirements engineering reference model (REM). Tech Rep TUM-I0618, Technische Universität München

  22. 22.

    Glinz M (2007) On non-functional requirements. In: Proceedings of the 15th IEEE international conference on requirements engineering (RE 07), IEEE Computer Society, pp 21–26

  23. 23.

    Gonzalez-Perez C, Henderson-Sellers B (2006) A powertype-based metamodelling framework. Softw Syst Model 5(1):72–90

    Article  Google Scholar 

  24. 24.

    Hevner AR, March ST, Park J, Ram S (2004) Design science in information systems research. MIS Q 28(1):75–105, http://www.jstor.org/stable/25148625

  25. 25.

    Hummel B, Thyssen J (2009) Behavioural specification of reactive systems using stream-based I/O tables. In: Proceedings of the 7th IEEE international conference on software engineering and formal methods (SEFM 09), IEEE Computer Society, pp 137–146

  26. 26.

    IEEE (1998) IEEE recommended practice for software requirements specifications—IEEE Std 830-1998. Technical standard IEEE Std 830-1998, The Institute of Electrical and Electronics Engineers Inc

  27. 27.

    IIBA (2009) A guide to the business analysis body of knowledge (BABOK Guide). International Institute of Business Analysis (IIBA), ISBN-13: 978–0981129211

  28. 28.

    Islam S (2009) Software development risk management model—a goal driven approach. In: Proceedings of the 7th joint meeting of the European software engineering conference and the ACM SIGSOFT symposium on the foundation of software engineering (ESEC/FSE). ACM Press, New York, pp 5–8

  29. 29.

    Islam S, Houmb S, Mendez Fernandez D, Joarder M (2009) Offshore-outsourced software development risk management model. In: Proceedings of the 12th IEEE international conference on computer and information technology (ICCIT 09), pp 514–519

  30. 30.

    ISO/IEC (2007) ISO/IEC Std. 24744 Software engineering—metamodel for development methodologies. Tech Rep 2007–02-15, International Organization for Standardization

  31. 31.

    Kang K, Cohen S, Hess J, Nowak W, Peterson S (1990) Feature-oriented domain analysis (FODA) feasibility study. Tech Rep CMU/SEI-90-TR-21, Software Engineering Institute, Carnegie Mellon University Pittsburgh, PA

  32. 32.

    Kitchenham B, Pfleeger S (1996) Software quality: the elusive target. IEEE Softw 13(1):12–21

    Article  Google Scholar 

  33. 33.

    Kroll P, Kruchten P (2003) The rational unified process made easy: a practitioner’s guide to the RUP. Addison-Wesley Longman Publishing Co., Inc, ISBN-13: 978–0321166098

  34. 34.

    Kuhrmann M, Mendez Fernandez D, Steenweg R (2013) Systematic software process development—where do we stand today? In: Proceedings of the 9th international conference on software and system process (ICSSP 13), ACM Press

  35. 35.

    van Lamsweerde A (2009) Requirements engineering: from system goals to UML models to software specifications. Wiley, ISBN-13: 978–0470012703

  36. 36.

    List B, Korherr B (2006) An evaluation of conceptual business process modelling languages. In: Proceedings of the 2006 ACM symposium on applied computing (SAC 06), ACM New York, pp 1532–1539

  37. 37.

    Mendez D, Penzenstadler B, Eckhardt J (2013) Amdire online resources. http://www4.in.tum.de/~mendezfe/openspace.shtml

  38. 38.

    Mendez Fernandez D (2011) Requirements engineering: artefact-based customisation. PhD thesis, Technische Universität München, Department of Informatics

  39. 39.

    Mendez Fernandez D, Kuhrmann M (2009) Artefact-based requirements engineering and its integration into a process framework: a customisable model-based approach for business information systems’ Analysis. Tech Rep TUM-I0929, Technische Universität München, http://www.in.tum.de/forschung/pub/reports/2006/TUM-I0618.pdf.gz

  40. 40.

    Mendez Fernandez D, Wagner S (2013) Naming the pain in requirements engineering: design of a global family of surveys and first results from Germany. In: Proceedings of the 17th international conference on evaluation and assessment in software engineering (EASE 2013), ACM Press, pp 183–194

  41. 41.

    Mendez Fernandez D, Penzenstadler B, Kuhrmann M, Broy M (2010) A meta model for artefact-orientation: fundamentals and lessons learned in requirements engineering. In: Petriu D, Rouquette N, Haugen O (eds) Proceedings of the 13th international conference on model driven engineering languages and systems (models). Springer, Berlin, vol 6395, pp 183–197

  42. 42.

    Mendez Fernandez D, Lochmann K, Penzenstadler B, Wagner S (2011) A case study on the application of an artefact-based requirements engineering approach. In: Proceedings of the 15th international conference on evaluation and assessment in software engineering (EASE 2011), Institution of Engineering and Technology (IET), pp 104–113

  43. 43.

    Mendez Fernandez D, Wagner S, Lochmann K, Baumann A, de Carne H (2012) Field study on requirements engineering: investigation of artefacts, project parameters, and execution strategies. Inf Softw Technol 54(2):162–178

    Article  Google Scholar 

  44. 44.

    Mendez Fernandez D, Wagner S (2013) Naming the pain in requirements engineering. Information and software technology currently in review. http://www4.in.tum.de/~mendezfe/openspace/NaPiRE/INFSOF-S-13-00428.pdf

  45. 45.

    Mendez Fernandez D, Wieringa R (2013) Improving requirements engineering by artefact orientation. In: Proceedings of the 14th international conference on product-focused software development and process improvement (PROFES ’13), Springer, vol 108–122

  46. 46.

    Merriam Webster Online Dictionary (2014) Definition: process. http://www.merriam-webster.com/dictionary/process

  47. 47.

    Milne A, Maiden N (2011) Power and politics in requirements engineering: a proposed research agenda. In: Proceedings of 19th international conference on requirements engineering (RE 2011), IEEE Computer Society

  48. 48.

    Nuseibeh B, Easterbrook S (2000) Requirements engineering: a roadmap. In: Proceedings of the conference on the future of software engineering, ACM, New York, pp 35–46

  49. 49.

    OMG (2008) Software and systems process engineering meta-model (SPEM) specification V. 2.0. Technical Standard formal/2008-04-01, Object Management Group

  50. 50.

    Parnas DL, Clements PC (1986) A rational design process: how and why to fake it. IEEE Trans Softw Eng 12(2):251–257

    Article  Google Scholar 

  51. 51.

    Pedreira O, Piattini M, Luaces M, Brisaboa N (2007) A systematic review of software process tailoring. SIGSOFT Softw Eng Notes 32(3):1–6

    Article  Google Scholar 

  52. 52.

    Penzenstadler B, Eckhardt J (2012) A requirements engineering content model for cyber-physical systems. In: 20th international conference on requirements engineering

  53. 53.

    Penzenstadler B, Sikora E, Pohl K (2009) A requirements reference model for model-based requirements engineering in the automotive domain. In: Glinz M, Heymans P (eds) Proceedings of the 15th international working conference on requirements engineering: foundation for software quality (REFSQ 09), Springer, Berlin, vol 5512, pp 212–217

  54. 54.

    Penzenstadler B, Eckhardt J, Mendez Fernandez D (2013a) Two replication studies for evaluating artefact models in RE: results and lessons learnt. In: To appear. Proceedings of the 3rd international workshop on replication in empirical software engineering research (RESER 13)

  55. 55.

    Penzenstadler B, Mendez Fernandez D, Eckhardt J (2013b) Understanding the impact of artefact-based RE—design of a replication study. In: To appear. Proceedings of the 7th international symposium on empirical software engineering and measurement (ESEM 13)

  56. 56.

    Regnell B, Paech B, Aurum A, Wohlin C, Dutoit A, och Dag J (2001) Requirements mean decisions!—research issues for understanding and supporting decision-making in requirements engineering. In: Bengtsson P (ed) Proceedings of the 1st Swedish conference on software engineering research and practise, Bleking Institute of Technology, no. 2001:10 (Research Report) in SERP, pp 49–52

  57. 57.

    Regnell B, Svensson RB, Wnuk K (2008) Can we beat the complexity of very large-scale requirements engineering? In: Proceedings of the 14th international conference on requirements engineering: foundation for software quality. Springer, REFSQ ’08, pp 123–128

  58. 58.

    Ritter F, Schooler LJ (2001) The learning curve. Pergamon, Oxford

    Google Scholar 

  59. 59.

    Rittmann S (2008) A methodology for modeling usage behavior of multi-functional systems. PhD thesis, Technische Universität München, Department of Informatics

  60. 60.

    Robertson J, Robertson S (2007) Volere requirements specification templates—edition 11. http://www.volere.co.uk

  61. 61.

    Rogers EM (1995) Diffusion of innovation, 4th edn. The Free Press, New York

    Google Scholar 

  62. 62.

    Schätz B (2008) Model-based development of software systems: from models to tools. Habilitationsschrift, Technische Universität München, Department of Informatics

  63. 63.

    Schätz B, Fleischmann A, Geisberger E, Pister M (2005) Model-based requirements engineering with AutoRAID. In: Cremers A, Manthey R, Martini P, Steinhage V (eds) Proceedings zum Workshop Modellbasierte Qualitätssicherung (QUAM), Bonner Köllen Verlag, Lecture Notes in Informatics (LNI), pp 511–516

  64. 64.

    Silva M, Oliveira T (2011) Towards detailed software artifact specification with SPEMArti. In: Proceedings of the 7th international conference on software and system process (ICSSP 13)

  65. 65.

    Spence AM (1981) The learning curve and competition. Bell J Econ 12(1):49–70

    Article  Google Scholar 

  66. 66.

    Standish Group International (1995) The Chaos Report. http://net.educause.edu/ir/library/pdf/NCP08083B.pdf. Accessed on 2009/03/15

  67. 67.

    Tell P, Babar M (2012) Activity theory applied to global software engineering: theoretical foundations and implications for tool builders. In: Proceedings of the 7th international conference on global, software engineering, pp 21–30

  68. 68.

    Ter Hofstede A, Verhoef T (1997) On the feasibility of situational method engineering* 1. Inf Syst 22(6/7):401–422. http://linkinghub.elsevier.com/retrieve/pii/S0306437997000240

  69. 69.

    Wiegers K (2003) Software requirements, 2nd edn. Microsoft Press, Redmond, ISBN-13: 978–0735618794

  70. 70.

    Wieringa R (2009) Design science as nested problem solving. In: Proceedings of the 4th international conference on design science research in information systems and technology, ACM, New York

  71. 71.

    Wieringa R, Aycse M (2012) Technical action research as a validation method in information systems design science. In: Proceedings of the 7th international conference on design science research in information systems: advances in theory and practice, pp 220–238

  72. 72.

    Wieringa R (2010) Relevance and problem choice in design science. In: Winter R, Zhao JL, Aier S (eds) Global perspectives on design science research. Springer, pp 61–76

  73. 73.

    Wiesi S (2013) Msc. thesis: Development and evaluation of an artefact-based requirements engineering approach for agile development. Master’s thesis, Technische Universität München, Department of Informatics

  74. 74.

    Zave P (1997) Classification of research efforts in requirements engineering. ACM Comput Surv 29(4):315–321

    Article  Google Scholar 

Download references

Acknowledgments

We would like to thank Manfred Broy, Sebastian Eder, Jonas Eckhardt, Henning Femmer, Saahil Ognawala, Debra Richardson, Ankita Raturi, Kristin Roher, Antonio Vetrò, and the external referees of this article for their support and for fruitful feedback on earlier versions of this article.

Author information

Affiliations

Authors

Corresponding author

Correspondence to Daniel Méndez Fernández.

Appendix: AMDiRE content model

Appendix: AMDiRE content model

The following appendix defines the content model of AMDiRE in detail giving for each content item a definition of the used concepts.

The artefact model is specified using the following notational aspects of UML class diagrams:

  • We denote the hierarchical structuring of the structure model with packages.

  • For the definition of the content model, we use a class diagram.

  • For content items that are crucial for only a specific application domain, but irrelevant for another, we use the stereotype \({\ll} Domain{\gg}\), such as business process models being crucial for the domain of business information systems, but irrelevant for the domain of embedded reactive systems.

Context specification

The context specification is depicted in Fig. 14. It contains the Project Scope, the Constraints and Rules, the Stakeholder Model, the Business Case, the Objectives and Goals, the Domain Model, and the Glossary.

Fig. 14
figure14

The AMDiRE context specification

A description of the content items is provided in Table 6.

Table 6 Content items in the context specification

Requirements specification

Fig. 15
figure15

The AMDiRE requirements specification

The requirements specification is depicted in Fig. 15. It contains the system vision, the usage model, the data model, the service model, the functional hierarchy, the quality requirements, the deployment requirements, the system constraints, the process requirements, and the risk list. A description of the content items is provided in Table 7.

Table 7 Content items in the requirements specification

System specification

The system specification is depicted in Fig. 16. It contains the function model, the component model, the behaviour model, the state model, and the data model. A description of the content items is provided in Table 8.

Fig. 16
figure16

The AMDiRE system specification

Table 8 Content items in the system specification

Rights and permissions

Reprints and Permissions

About this article

Verify currency and authenticity via CrossMark

Cite this article

Méndez Fernández, D., Penzenstadler, B. Artefact-based requirements engineering: the AMDiRE approach. Requirements Eng 20, 405–434 (2015). https://doi.org/10.1007/s00766-014-0206-y

Download citation

Keywords

  • Requirements engineering
  • Artefact orientation
  • Empirical evaluation