Skip to main content
SpringerLink
Log in

Requirements-driven incremental adoption of variability management techniques and tools: an industrial experience report

  • Requirements Engineering in Software Product Lines
  • Published:
Requirements Engineering Aims and scope Submit manuscript

Abstract

In theory, software product line engineering has reached a mature state. In practice though, implementing a variability management approach remains a tough case-by-case challenge for any organization. To tame the complexity of this undertaking, it is inevitable to handle variability from multiple perspectives and to manage variability consistently across artifacts, tools, and workflows. Especially, a solid understanding and management of the requirements to be met by the products is an inevitable prerequisite. In this article, we share experiences from the ongoing incremental adoption of explicit variability management at TRW Automotive’s department for automotive slip control systems—located in Koblenz, Germany. On the technical side, the three key drivers of this adoption effort are (a) domain modeling and scoping, (b) handling of variability in requirements and (c) tighter integration of software engineering focus areas (e.g., domain modeling, requirements engineering, architectural modeling) to make use of variability-related data. In addition to implementation challenges with using and integrating concrete third-party tools, social and workflow-related issues are covered as well. The lessons learned are presented, discussed, and thoroughly compared with the state of the art in research.

This is a preview of subscription content, log in via an institution to check access.

Access this article

Log in via an institution

Price excludes VAT (USA)
Tax calculation will be finalised during checkout.

Instant access to the full article PDF.

Institutional subscriptions

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

Similar content being viewed by others

Notes

  1. This article is an extension of our previously published work [17]. Here, we elaborate in much more detail on the involved processes, risks, and mitigation actions. Moreover, interdependencies between requirements and architectural design are covered, technical details are added, lessons learned are deepened, and transferability of our findings is discussed.

  2. http://www.autosar.org.

  3. Base Software and Performance Software consist of a Core and an Application part. Each part is handled by a different team. The work presented in this article focuses primarily on the Core part of Base Software and a little on its Application part.

  4. Of course, incorrect requirements and architecture designs do have an impact on implementation. As further automation of asset reuse—especially code generation—will be introduced in later adoption phases, failure has an even more instant impact on production.

  5. http://www.pure-systems.com/.

  6. http://www-01.ibm.com/software/awdtools/doors/.

  7. http://www-142.ibm.com/software/products/us/en/ratirhapfami/.

  8. Technically, other variation types {or, alternative} are also supported. Nevertheless, if requirements shall be used for tailoring architecture models, then only {optional, mandatory} shall be used due to a limitation of the current evaluator for product variants in Rhapsody.

  9. At TRW Automotive SCS, the term deployment view is not primarily related to the actual deployment of software onto physical hardware as proposed by the UML. Instead, each deployment view models one concrete instance of the reference architecture (represented by the Core library) for a specific product variant. This includes the deployment to physical hardware (especially micro controllers or cores of multi-core micro controllers), but goes beyond that.

  10. The “excluded” selection state denotes an explicit choice to forbid a feature to be part of the current configuration or any inheriting ones.

  11. A complete restriction expression for each single requirement statement to be represented in Rhapsody is derived by the conjunction of its pvRestriction value and the ones of its parent requirements in DOORS. This enhances understanding variability in Rhapsody and is needed for automated tailoring of the architecture model with the used tools.

  12. http://splc.net/fame.html.

  13. http://www.biglever.com.

References

  1. Aiken C, Keller S (2009) The irrational side of change management. McKinsey Q 2:101–109

    Google Scholar 

  2. Alves V, Niu N, Alves C, Valença G (2010) Requirements engineering for software product lines: a systematic literature review. Inf Softw Technol 52(8):806–820

    Article  Google Scholar 

  3. APIS IT GmbH (2008) AIAG FMEA, 4th edn

  4. Asadi M, Bagheri E, Mohabbati B, Gašević D (2012) Requirements engineering in feature oriented software product lines: an initial analytical study. In: Proceedings of the 16th international software product line conference, vol 2, SPLC ’12. ACM, New York, NY, USA, pp 36–44

  5. Automotive SIG: Automotive SPICE: process assessment model (2010)

  6. Automotive SIG: Automotive SPICE: process reference model (2010)

  7. Bachmann F, Bass L (2001) Managing variability in software architectures. In: Proceedings of the 2001 symposium on software reusability: putting software reuse in context, SSR ’01. ACM, New York, NY, USA, pp 126–132

  8. Bayer J, Flege O, Knauber P, Laqua R, Muthig D, Schmid K, Widen T, DeBaud JM (1999) PuLSE: a methodology to develop software product lines. In: Proceedings of the 1999 symposium on software reusability, SSR ’99. ACM, New York, NY, USA, pp 122–131

  9. Bosch J (2002) Maturity and evolution in software product lines: approaches, artefacts and organization. In: Proceedings of the second international conference on software product lines, SPLC ’02. London, UK, pp 257–271

  10. Bosch J (2004) On the development of software product family components. Lect Notes Comput Sci 3154:169–173

    Google Scholar 

  11. Brewer MB (2000) Research design and issues of validity. In: Reis HT, Judd CM (eds) Handbook of research methods in social and personality psychology, chap 1. Cambridge University Press, Cambridge

  12. Bühne S, Lauenroth K, Pohl K (2005) Modelling requirements variability across product lines. In: Proceedings 13th IEEE international conference on requirements engineering, RE ’05. IEEE, pp 41–52

  13. Chrissis MB, Konrad M, Shrum S (2011) CMMI for development: guidelines for process integration and product improvement, third edn. SEI series in software engineering. Addison-Wesley Professional, Reading

  14. Classen A, Heymans P, Laney RC, Nuseibeh B, Tun TT (2007) On the structure of problem variability: from feature diagrams to problem frames. In: Pohl K, Heymans P, Kang KC, Metzger A (eds) First international workshop on variability modelling of software-intensive systems, Lero Technical Report, vol 2007-01, pp 109–117

  15. Clements P, Northrop L (2001) Software product lines: practices and patterns. In: SEI series in software engineering, 3rd edn. Addison-Wesley Professional, Reading

  16. Clements PC, Jones LG, McGregor JD, Northrop LM (2006) Getting there from here: a roadmap for software product line adoption. Commun ACM 49(12):33–36

    Article  Google Scholar 

  17. Derakhshanmanesh M, Fox J, Ebert J (2012) Adopting feature-centric reuse of requirements assets: an industrial experience report. In: Proceedings of the 16th international software product line conference, vol 2, SPLC ’12. ACM, New York, NY, USA, pp 2–9

  18. Doppler K, Lauterburg C (2002) Change management. Den Unternehmenswandel gestalten. Campus Fachbuch

  19. Eriksson M, Börstler J, Borg K (2005) The PLUSS approach—domain modeling with features, use cases and use case realizations. In: Obbink H, Pohl K (eds) Software product lines, lecture notes in computer science, vol 3714. Springer, Berlin, pp 33–44

    Google Scholar 

  20. Galster M, Avgeriou P (2011) Handling variability in software architecture: problems and implications. In: Proceedings of the 2011 ninth working IEEE/IFIP conference on software architecture, WICSA ’11. IEEE Computer Society, Washington, DC, USA, pp 171–180

  21. Galster M, Avgeriou P (2011) The notion of variability in software architecture: results from a preliminary exploratory study. In: Proceedings of the 5th workshop on variability modeling of software-intensive systems, VaMoS ’11. ACM, New York, NY, USA, pp 59–67

  22. Griss ML, Favaro J, d’Alessandro M (1998) Integrating feature modeling with the RSEB. In: Proceedings of the 5th international conference on software reuse, ICSR ’98. IEEE Computer Society, Washington, DC, USA, pp 76–85

  23. Hetrick WA, Krueger CW, Moore JG (2006) Incremental return on incremental investment: engenio’s transition to software product line practice. Companion to the 21st ACM SIGPLAN conference on object-oriented programming systems languages and applications, OOPSLA ’06, pp 798–804

  24. IEEE Recommended Practice for Software Requirements Specifications (1998) Technical report. New York, NY, USA

  25. ISO—International Organization for Standardization: 26262-6:2011(E) Annex D: road vehicles—functional safety—part 6: product development at the software level (2011)

  26. Jackson M (1995) Software requirements and specifications: a lexicon of practice, principles and prejudices. ACM Press/Addison-Wesley, New York, NY

    Google Scholar 

  27. Jackson M (2001) Problem frames: analyzing and structuring software development problems. Addison-Wesley, Boston, MA

    Google Scholar 

  28. Jacobson I, Griss M, Jonsson P (1997) Software reuse: architecture, process and organization for business success. ACM Press/Addison-Wesley, New York, NY

    Google Scholar 

  29. Kang KC, Cohen SG, Hess JA, Novak WE, Peterson AS (1990) Feature-oriented domain analysis (FODA) feasibility study. Technical report, CMU/SEI-90-TR-21, Software Engineering Institute, Carnegie Mellon University

  30. Knauss E, Lübke D, Flohr T (2006) Learning to tailor documentation of software requirements. In: Proceedings of the international workshop on learning software organizations and requirements engineering. Hannover, Germany, pp 39–46

  31. Kotter JP (1996) Leading change. Harvard Business Review Press, Cambridge

    Google Scholar 

  32. Kovačević J, Aférez M, Kulesza U, Moreira A, Araújo J, Amaral V, Ramos Alves, Vander Rashid A, Chitchyan R (2007) AMPLE: aspect-oriented, model-driven, product line engineering (AMPLE: Deliverable D1.1). Technical report. http://ample.holos.pt/gest_cnt_upload/editor/File/public/DeliverableD1.1.pdf. (Visited: June 5th, 2013)

  33. Krueger CW, Jackson K (2009) Requirements engineering for systems and software product lines. Technical report, IBM Corporation

  34. Kuvaja P, Similä J, Hanhela H (2011) Software product line adoption—guidelines from a case study, pp 143–157

  35. van Lamsweerde A (2009) Requirements engineering: from system goals to UML models to software specifications. Wiley, New York

    Google Scholar 

  36. Lee K, Kang KC, Lee J (2002) Concepts and guidelines of feature modeling for product line software engineering. Softw Reuse Methods Tech Tools 2319:62–77

    Article  Google Scholar 

  37. Maßen T, Lichter H (2004) RequiLine: a requirements engineering tool for software product lines. In: Linden F (eds) Software product-family engineering, lecture notes in computer science, vol 3014. Springer, Berlin, pp 168–180

    Google Scholar 

  38. McFeeley B (1996) IDEAL: A user’s guide for software process improvement. Technical report. February, Carnegie Mellon University, Pittsburgh, PA

  39. Neiva DFS, De Almeida ES, Meira SRDL (2009) An experimental study on requirements engineering for software product lines. Proceedings of the 35th euromicro conference on software engineering and advanced applications, pp 251–254

  40. Northrop LM (2004) Software product line adoption roadmap. Technical report. CMU/SEI-2004-TR-022, Software Engineering Institute, Carnegie Mellon University

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

  42. Padmanabhan P, Lutz RR (2005) Tool-Supported Verification of Product Line Requirements. Autom Softw Eng 12(4):447–465

    Google Scholar 

  43. Pohl K, Böckle G, van der Linden FJ (2005) Software product line engineering: foundations, principles and techniques. Springer, Berlin

    Book  Google Scholar 

  44. Rupp C (2007) Requirements-engineering und-Management. Hanser Fachbuchverlag, Munich

    Google Scholar 

  45. Schmid K, Krennrich K, Eisenbarth M (2006) Requirements management for product lines: extending professional tools. In: Proceedings of the 10th international software product line conference, SPLC ’06, pp 113–122

  46. Shaker P, Atlee JM, Wang S (2012) A feature-oriented requirements modelling language. In: Proceedings of the 20th IEEE international requirements engineering conference, RE ’12, pp 151–160

  47. Sochos P, Riebisch M, Philippow I (2006) The feature-architecture mapping (FArM) method for feature-oriented development of software product lines. In: Proceedings of the 13th annual IEEE international symposium and workshop on engineering of computer based systems, ECBS ’06. IEEE Computer Society, Washington, DC, USA, pp 308–318

  48. Staples M, Hill D (2004) Experiences adopting software product line development without a product line architecture. In: Proceedings of the 11th Asia-Pacific software engineering conference, APSEC ’04. IEEE Computer Society, Washington, DC, USA, pp 176–183

  49. Thurimella AK, Janzen D (2011) metadoc feature modeler: a plug-in for IBM rational DOORS. In: Proceedings of the 15th international software product line conference, SPLC ’11, pp 313–322

  50. van der Linden FJ, Schmid K, Rommes E (2010) Software product lines in action: the best industrial practice in product line engineering. Springer, Berlin

    Google Scholar 

Download references

Author information

Authors and Affiliations

  1. Institute for Software Technology, University of Koblenz–Landau, Universitätsstraße 1, 56070, Koblenz, Germany

    Mahdi Derakhshanmanesh & Jürgen Ebert

  2. Lucas Varity GmbH, TRW Automotive, Carl-Spaeter-Straße 8, 56070, Koblenz, Germany

    Joachim Fox

Authors
  1. Mahdi Derakhshanmanesh
    View author publications

    You can also search for this author in PubMed Google Scholar

  2. Joachim Fox
    View author publications

    You can also search for this author in PubMed Google Scholar

  3. Jürgen Ebert
    View author publications

    You can also search for this author in PubMed Google Scholar

Corresponding author

Correspondence to Mahdi Derakhshanmanesh.

Rights and permissions

Reprints and permissions

About this article

Cite this article

Derakhshanmanesh, M., Fox, J. & Ebert, J. Requirements-driven incremental adoption of variability management techniques and tools: an industrial experience report. Requirements Eng 19, 333–354 (2014). https://doi.org/10.1007/s00766-013-0185-4

Download citation

  • Received:

  • Accepted:

  • Published:

  • Issue Date:

  • DOI: https://doi.org/10.1007/s00766-013-0185-4

Keywords

Search

Navigation