Computer Science - Research and Development

, Volume 29, Issue 1, pp 21–43 | Cite as

Guiding requirements engineering for software-intensive embedded systems in the automotive industry

The REMsES approach
  • Peter Braun
  • Manfred Broy
  • Frank Houdek
  • Matthias Kirchmayr
  • Mark Müller
  • Birgit Penzenstadler
  • Klaus Pohl
  • Thorsten Weyer
Regular Paper

Abstract

Over the past decade, a dramatic increase of functionality, quantity, size, and complexity of software-intensive embedded systems in the automotive industry can be observed. In particular, the growing complexity drives current requirements engineering practices to the limits. In close cooperation between partners from industry and academia, the recently completed REMsES (Requirements Engineering and Management for software-intensive Embedded Systems) project has developed a guideline to support requirements engineering processes in the automotive industry. The guideline enables the requirements engineers to cope with the challenges that arise due to quantity, size and complexity of software-intensive systems. This article presents the major results of the project, namely, the fundamental principles of the approach, the guideline itself, the tool support, and the major findings obtained during the evaluation of the approach.

Keywords

Software engineering Requirements Specifications Methodologies Tools 

Preview

Unable to display preview. Download preview PDF.

Unable to display preview. Download preview PDF.

References

  1. 1.
    Balarin F, Passerone R, Pinto A, Sangiovanni-Vincentelli A (2005) A formal approach to system level design: metamodels and unified design environments. In: Proceedings of the 3rd ACM and IEEE int conf on formal methods and models for Co-Design. ACM Press, New York, pp 155–163 Google Scholar
  2. 2.
    Broy M (2006a) Challenges in automotive software engineering. In: Osterweil LJ, Rombach HD, Soffa ML (eds) Proceedings of the 28th int conf on software engineering. ACM Press, New York, pp 33–42 Google Scholar
  3. 3.
    Broy M (2006b) The ‘grand challenge’ in informatics: engineering software-intensive systems. IEEE Comput 39(10):72–80 CrossRefGoogle Scholar
  4. 4.
    Broy M, Geisberger E, Kazmeier J, Rudorfer A, Beetz K (2007) Ein Requirements-Engineering-Referenzmodell. Informatik-Spektrum 30:127–142 CrossRefGoogle Scholar
  5. 5.
    Bundesministerium des Inneren (2009) V-Modell XT. http://www.cio.bund.de/DE/IT-Methoden/V-Modell_XT/v-modell_xt_node.html
  6. 6.
    Cao J, Crews JM, Deokar A, Burgoon JK, Nunamaker JF (2006) Interactions between system evaluation and theory testing—a demonstration of the power of a multifaceted approach to information systems research. J Manag Inf Syst 22(4):207–235 Google Scholar
  7. 7.
    Chrissis MB, Konrad M, Shrum S (2006) CMMI: guidelines for process integration and product improvement. The SEI series in software engineering. Addison-Wesley, Reading Google Scholar
  8. 8.
    Cockburn A (2000) Writing effective use cases. Addison-Wesley/Longman, Boston Google Scholar
  9. 9.
    Damm W, Votintseva A, Metzner A, Josko B, Peikenkamp T, Böde E (2005) Boosting re-use of embedded automotive applications through rich components. In: Proceedings of foundations of interface technologies. Elsevier, Amsterdam. Electronic Notes in Theoretical Computer Science Google Scholar
  10. 10.
    Dannenberg J, Kleinhans C (2004) The coming age of collaboration in the automotive industry. Mercer Manage J 18:88–94 Google Scholar
  11. 11.
    Dardenne A, van Lamsweerde A, Fickas S (1993) Goal-directed requirements acquisition. Sci Comput Program 30(1/2):232–282 Google Scholar
  12. 12.
    Davis AM (1993) Software requirements: objects, functions, and states. Prentice Hall, Upper Saddle River MATHGoogle Scholar
  13. 13.
    Falkenberg ED, Hesse W, Lindgreen P, Nilsson BE, Jan Oei JL, Rolland C, Stamper RK, van Assche FJM, VerriJn-Stuart AA, Voss K (1998) A framework for information system concepts—the Frisco report. Tech. rep., International Federation for Information Processing (IFIP), Luxemburg Google Scholar
  14. 14.
    Finkelstein A, Gabbay D, Hunter A, Kramer J, Nuseibeh B (1994) Inconsistency handling in multi-perspective specifications. IEEE Trans Softw Eng 20(8):569–578 CrossRefGoogle Scholar
  15. 15.
    Freund U, Braun P, Romberg J, Bauer A, Mai P, Ziegenbein D (2006) Automode—a transformation based approach for the model-based design of embedded automotive software. In: Proceedings of the 3rd European congress on embedded real time software. SIA, Toulouse Google Scholar
  16. 16.
    Gause D, Weinberg G (1989) Exploring requirements—quality before design. Dorset House, New York MATHGoogle Scholar
  17. 17.
    Ghezzi C, Jazayeri M, Mandrioli D (1991) Fundamentals of software engineering. Prentice Hall, Englewood MATHGoogle Scholar
  18. 18.
    Gorschek T, Wohlin C (2006) Requirements abstraction model. Requir Eng 11(1):79–101 CrossRefGoogle Scholar
  19. 19.
    Grimm K (2003) Software technology in an automotive company—major challenges. In: Proceedings of the 25th int conf on software engineering. IEEE Computer Society, Washington, pp 498–503 Google Scholar
  20. 20.
    Grünbauer J (2008) Feature Interactions auf Nutzungsebene. Softwaretechnik-Trends (1). Gesellschaft für Informatik, Bonn Google Scholar
  21. 21.
    Hammond J, Rawlings R, Hall A (2001) Will it work? In: Proceedings of the 5th IEEE int symp on requirements engineering. IEEE Computer Society, Washington, pp 102–109 Google Scholar
  22. 22.
    Hardung B, Kölzow T, Krüger A (2004) Reuse of software in distributed embedded automotive systems. In: Proceedings of the 4th ACM int conf on embedded software. ACM, New York, pp 203–210 CrossRefGoogle Scholar
  23. 23.
    Harel D (1987) Statecharts—a visual formalism for complex systems. Sci Comput Program 8:231–274 CrossRefMATHMathSciNetGoogle Scholar
  24. 24.
    Heinecke H, Schnelle KP, Fennel H, Bortolazzi J, Lundh L, Leflour J, Maté JL, Nishikawa K, Scharnhorst T (2004) Automotive open system architecture—an industry-wide initiative to manage the complexity of emerging automotive E/E architectures. Convergence Transportation Electronics Association, pp 325–332 Google Scholar
  25. 25.
    Institute of Electric and Electronic Engineers (1998a) Guide for developing system requirements specifications (ANSI/IEEE Std 1233-1998) Google Scholar
  26. 26.
    Institute of Electric and Electronic Engineers (1998b) Guide for information technology—system definition—concept of operations (IEEE Std 1362-1998) Google Scholar
  27. 27.
    Institute of Electric and Electronic Engineers (1998c) Recommended practice for software requirements specifications (IEEE Std 830-1998) Google Scholar
  28. 28.
    International Organization for Standardization (2006) Information technology—process assessment. Part 5. An exemplar process assessment model (ISO/IEC Std 15504-5:2006) Google Scholar
  29. 29.
    Jackson M (1995a) Software requirements and specifications: a lexicon of practice, principles and prejudices. ACM Press/Addison-Wesley, New York Google Scholar
  30. 30.
    Jackson M (1995b) The world and the machine. In: Proceedings of the 17th int conf on software engineering. ACM, New York, pp 283–292 Google Scholar
  31. 31.
    Jackson M (2001) Problem analysis and structure. In: Hoare T, Broy MRS (eds) Engineering theories of software construction. IOS Press, Amsterdam, pp 3–20 Google Scholar
  32. 32.
    Jacobson I, Christerson M, Jonsson P, Oevergaard G (1992) Object oriented software engineering—a use case driven approach. Addison-Wesley, Reading MATHGoogle Scholar
  33. 33.
    Kruchten P (2000) The rational unified process: an introduction. Addison-Wesley/Longman, Boston Google Scholar
  34. 34.
    van Lamsweerde A (2001) Goal-oriented requirements engineering: a guided tour. In: Proceedings of the 5th IEEE int symp on requirements engineering. IEEE Computer Society, Washington, p 249 Google Scholar
  35. 35.
    van Lamsweerde A (2008) Requirements engineering: from craft to discipline. In: Proceeding of the 16th ACM SIGSOFT int symp on foundations of software engineering. ACM, New York, pp 238–249 CrossRefGoogle Scholar
  36. 36.
    van Lamsweerde A, Dardenne A, Delcourt B, Dubisy F (1991) The KAOS project—knowledge acquisition in automated specifications of software. In: Proceedings of AAAI spring symposium series. American Association for Artificial Intelligence, Standford, pp 69–82 Google Scholar
  37. 37.
    Leuser J, Porta N, Bolz A, Raschke A (2009) Empirical validation of a requirements engineering process guide. In: 13th int conf on evaluation and assessment in software engineering Google Scholar
  38. 38.
    Lonn H, Saxena T, Nolin M, Torngren M (2004) FAR EAST: Modeling an automotive software architecture using the EAST ADL. In: Proceedings of the 1st int ICSE workshop on software engineering for automotive systems. IEEE Computer Society, Washington Google Scholar
  39. 39.
    Medvidovic N, Taylor R (2000) A classification and comparison framework for software architecture description languages. IEEE Trans Softw Eng 26(1):70–93 CrossRefGoogle Scholar
  40. 40.
    Menzel I (2009) Functional versus use-case based requirements specification: an experiment. Technical report, Robert Bosch GmbH, Stuttgart Google Scholar
  41. 41.
    Nuseibeh B (2001) Weaving together requirements and architectures. IEEE Comput 34(3):115–119 CrossRefGoogle Scholar
  42. 42.
    Paech B, von Knethen A, Doerr J, Bayer J, Kerkow D, Kolb R, Trendowicz A, Punter T, Dutoit A (ICSE 2003) An experience-based approach for integrating architecture and requirements engineering. In: 2nd int software requirements to architectures workshop Google Scholar
  43. 43.
    Parnas DL, Madey J (1995) Functional documents for computer systems. Sci Comput Program 25(1):41–61 CrossRefGoogle Scholar
  44. 44.
    Pohl K, Sikora E (2007) Structuring the co-design of requirements and architecture. In: Proceedings of the 13th int working conference requirements engineering-foundation for software quality. LNCS, vol 4542. Springer, Heidelberg, pp 48–62 CrossRefGoogle Scholar
  45. 45.
    Potts C (1995) Using schematic scenarios to understand user needs. In: Proceedings of the ACM symposium on designing interactive systems. ACM, New York, pp 247–266 Google Scholar
  46. 46.
    Pretschner A, Broy M, Kruger I, Stauner T (2007) Software engineering for automotive systems: a roadmap. In: Proceeding of future of software engineering. IEEE Computer Society, Washington, pp 285–303 Google Scholar
  47. 47.
    Rinke T, Weyer T (2007) Defining reference models for modelling qualities—how requirements engineering techniques can help. In: Proceedings of the 13th int working conference requirements engineering-foundation for software quality. LNCS, vol 4542. Springer, Heidelberg, pp 335–340 CrossRefGoogle Scholar
  48. 48.
    Robertson S, Robertson J (1999) Mastering the requirements process. Addison-Wesley, Reading Google Scholar
  49. 49.
    Ross DT, Schoman KE (1977) Structured analysis for requirements definition. IEEE Trans Sofw Eng 3(1):6–15 CrossRefGoogle Scholar
  50. 50.
    SPICE User Group (2008a) Automotive SPICE—process assessment model (PAM). http://www.automotivespice.com/
  51. 51.
    SPICE User Group (2008b) Automotive SPICE—Process reference model (PRM). http://www.automotivespice.com/
  52. 52.
    Swartout W, Balzer R (1982) On the inevitable interwining of specification and implementation. Commun ACM 25(7):438–440 CrossRefGoogle Scholar
  53. 53.
    Walls JG, Widmeyer GR, Sawy AE (1992) Building an information system design theory for vigilant eis. Inf Syst Res 3(1):36–59 CrossRefGoogle Scholar
  54. 54.
    Weber M, Weisbrod J (2003) Requirements engineering in automotive development: experiences and challenges. IEEE Softw 20(1):16–24 CrossRefGoogle Scholar
  55. 55.
    Weyer T, Pohl K (2008) Eine Referenzstrukturierung zur modellbasierten Kontextanalyse im Requirements Engineering softwareintensiver eingebetteter Systeme. In: Kühne T, Steimann F (eds) Tagungsband zur ‘Modellierung 2008’. LNI, vol 127. Gesellschaft für Informatik, Bonn, pp 181–196 Google Scholar
  56. 56.
    Wieringa RJ (2002) Design methods for software systems: yourdon, statemate and UML. Kaufmann, San Francisco Google Scholar
  57. 57.
    Zave P, Jackson M (1997) Four dark corners of requirements engineering. ACM Trans Softw Eng Methodol 6(1):1–30 CrossRefGoogle Scholar

Copyright information

© Springer-Verlag 2010

Authors and Affiliations

  • Peter Braun
    • 1
  • Manfred Broy
    • 2
  • Frank Houdek
    • 3
  • Matthias Kirchmayr
    • 3
  • Mark Müller
    • 4
  • Birgit Penzenstadler
    • 2
  • Klaus Pohl
    • 5
  • Thorsten Weyer
    • 5
  1. 1.Validas AGMünchenGermany
  2. 2.Technische Universität MünchenGarchingGermany
  3. 3.Daimler AGUlmGermany
  4. 4.Robert Bosch GmbHStuttgartGermany
  5. 5.Universität Duisburg-EssenEssenGermany

Personalised recommendations