Skip to main content
Log in

Linking business and requirements engineering: is solution planning a missing activity in software product companies?

  • Special Issue-RE'07 Best Papers
  • Published:
Requirements Engineering Aims and scope Submit manuscript

Abstract

A strong link between strategy and product development is important, since companies need to select requirements for forthcoming releases. However, in practice, connecting requirements engineering (RE) and business planning is far from trivial. This paper describes the lessons learned from four software product companies that have recognized the need for more business-oriented long-term planning. The study was conducted using the action research approach. We identified five practices that seem to strengthen the link between business decisions and RE. These are (1) explicating the planning levels and time horizons; (2) separating the planning of products’ business goals from R&D resource allocation; (3) planning open-endedly with a pre-defined rhythm; (4) emphasizing whole-product thinking; and (5) making solution planning visible. To support whole-product thinking and solution planning, we suggest that companies create solution concepts. The purpose of the solution concept is to provide a big picture of the solution and guide RE activities.

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

Access this article

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

Instant access to the full article PDF.

Fig. 1
Fig. 2
Fig. 3
Fig. 4
Fig. 5

Similar content being viewed by others

References

  1. Boehm B (2003) Value-based software engineering. ACM Softw Eng Notes 28(2):3. doi:10.1145/638750.638775

  2. Penny DA (2002) An estimation-based management framework for enhancive maintenance in commercial software products. In: Proceedings of the IEEE international conference on software maintenance (ICSM’02), pp 122–130

  3. Gorchels L (2000) The product manager’s handbook—the complete product management resource, 2nd edn. NTC Business Books, Illinois, USA

    Google Scholar 

  4. Karlsson L, Dahlstedt Å Natt och Dag J, Regnell B, Persson A (2002) Challenges in market-driven requirements engineering—an industrial interview study. In: Proceedings of the Eighth International Workshop on Requirements Engineering: Foundations for Software Quality (REFSQ’2002), pp 37–49

  5. Lehtola L, Kauppinen M, Kujala S (2004) Requirements prioritization challenges in practice. In: Proceedings of 5th International Conference on Product Focused Software Process Improvement (PROFESS 2004), pp 497–508

  6. Carlshamre P (2002) Release planning in market-driven software product development—provoking an understanding. Requir Eng J 7(3):139–151. doi:10.1007/s007660200010

    Article  Google Scholar 

  7. Regnell B, Beremark P, Ekhlund O (1998) A market-driven requirements engineering process: results from an industrial process improvement programme. Requir Eng J 3(2):121–129. doi:10.1007/BF02919972

    Article  Google Scholar 

  8. Lehtola L, Kauppinen M (2006) Suitability of requirements prioritization methods for market-driven software product development. Softw Process Improv Pract 11(1):7–19. doi:10.1002/spip.249

    Article  Google Scholar 

  9. Rautiainen K, Vuornos L, Lassenius C (2003) An experience in combining flexibility and control in a small company’s software product development process. In: Proceedings of the ACM-IEEE International Symposium on Empirical Software Engineering (ISESE 2003), pp 28–37

  10. Ebert C (2005) Requirements before the requirements: understanding the upstream impacts. In: Proceedings of 13th IEEE international conference on requirements engineering, IEEE Computer Society Press, pp 117–124

  11. Lehtola L, Kauppinen M, Kujala S (2005) Linking business view to requirements engineering: long-term product planning by roadmapping. In: Proceedings of 13th IEEE international conference on requirements engineering, IEEE Computer Society Press, pp 439–446

  12. Kappel T (2001) Perspectives on roadmaps: how organizations talk about the future. J Prod Innov Manage 18:39–50. doi:10.1016/S0737-6782(00)00066-7

    Article  MathSciNet  Google Scholar 

  13. Phaal R, Farrukh C, Mitchell R, Probert D (2003) Starting-up roadmapping fast. Res Technol Manage 46(2):52–58

    Google Scholar 

  14. Phaal R, Farrukh CJP, Probert D (2001) Characterisation of technology roadmaps: purpose and format. In: Proceedings of the Portland International Conference on Management of Engineering and Technology (PICMET'01), pp 367–374

  15. Carmel E, Sawyer S (1998) Packaged software development teams: what makes them different? Inf Technol People 11(1):7–19. doi:10.1108/09593849810204503

    Article  Google Scholar 

  16. Hoch D, Roeding C, Purkert G, Lindner S (1999) Secrets of software success: management insights from 100 software firms around the world. Harvard Business School Press, Boston

    Google Scholar 

  17. Nambisan S (2001) Why service businesses are not product businesses. MIT Sloan Manage Rev 42(4):72–80

    MathSciNet  Google Scholar 

  18. Cusumano M (2008) The changing software business: moving from products to services. IEEE Comput 41(1):20–27

    MathSciNet  Google Scholar 

  19. Sawyer P (2000) Packaged software: challenges for RE. In: Proceedings of the sixth International workshop on Requirements Engineering: Foundation of Software Quality (REFSQ’00), pp 137–142

  20. Carlshamre P (2001) Usability perspective on requirements engineering—from methodology to product development, Ph D Dissertation No. 726, Department of Computer and Information Science, Linköping University, Sweden

  21. Chesbrough H, Spohrer JA (2006) A research manifesto for services science. Commun ACM 49(7):35–40. doi:10.1145/1139922.1139945

    Article  Google Scholar 

  22. Wiegers K (2003) Software requirements, 2nd edn. Microsoft Press, Redmond, WA

    Google Scholar 

  23. Ruhe G, Eberlein A, Pfahl D (2002) Quantitative WinWin—a new method for decision support in requirements negotiation. In proceedings of the 14th International Conference on Software Engineering and Knowledge Engineering (SEKE’02), pp 159–166

  24. Rautiainen K, Lassenius C (eds) (2004) Pacing software product development: a framework and practical implementation guidelines. Helsinki University of Technology Software Business and Engineering Institute Technical Reports 3

  25. Vähäniitty J, Lassenius C, Rautiainen K (2002) An approach to product roadmapping in small software product businesses. In Conference Notes of Quality Connection—7th European Conference on Software Quality, pp 12–13

  26. Grönroos C (2007) Service management and marketing: customer management in service competition, 3rd edn. Wiley, Chichester

    Google Scholar 

  27. Hutchings AF, Knox ST (1995) Creating products: customers demand. Commun ACM 38(5):72–80. doi:10.1145/203356.203370

    Article  Google Scholar 

  28. Lehtola L, Kauppinen M, Vähäniitty J (2007) Strengthening the link from business decisions to requirements engineering: long-term product planning in software product companies. In: Proceedings of the 15th IEEE International Requirements Engineering Conference (RE’07), IEEE Computer Society Press, pp 153–162

  29. Avison D, Lau F, Myers M, Nielsen P (1999) Action research. Commun ACM 42(1):94–97. doi:10.1145/291469.291479

    Article  Google Scholar 

  30. Stringer ET (1999) Action research, 2nd edn. Sage Publications, Thousand Oaks, CA

    Google Scholar 

  31. Patton MQ (2002) Qualitative research and evaluation methods, 3rd edn. Sage Publications, Thousand Oaks, CA

    Google Scholar 

  32. Potts C (1993) Software-engineering research revisited. IEEE Softw 10(5):19–28. doi:10.1109/52.232392

    Article  Google Scholar 

  33. Vähäniitty J (2005) A tentative framework for connecting long-term business and product planning with iterative & incremental software product development. In: Proceedings of the 7th International Workshop on Economic-Driven Software Engineering Research (EDSER-7) at ICSE 2005, pp 1–4

  34. Berander P, Wohlin C (2003) Identification of key factors in software process management—a case study. In: Proceedings of the 2003 International Symposium on Empirical Software Engineering (ISESE’03), IEEE Computer Society, pp 316–325

  35. Yin RK (1994) Case study research—design and methods, 2nd edn. Sage Publications, Thousand Oaks, CA

    Google Scholar 

  36. Webster FE (1994) Executing the new marketing concept. Mark Manage 3(1):8–16

    MathSciNet  Google Scholar 

  37. Kim WC, Mauborgne R (2005) Blue ocean strategy. Harvard Business School Press, Boston

    Google Scholar 

  38. MacMillan IC, McGrath RG (1997) Discovering new points of differentiation. Harv Bus Rev (Jul/Aug):133–145

  39. Kauppinen M, Kujala S, Aaltio T, Lehtola L (2002) Introducing requirements engineering: how to make a cultural change happen in practice. In: Proceedings of the IEEE Joint International Requirements Engineering Conference (RE’02), IEEE Computer Society Press, pp 43–51

Download references

Acknowledgments

This study was funded by the Finnish Funding Agency for Technology and Innovation (Tekes) and the participating companies. The authors warmly thank the participating companies for their cooperation and willingness to share their experiences and data.

Author information

Authors and Affiliations

Authors

Corresponding author

Correspondence to Marjo Kauppinen.

Rights and permissions

Reprints and permissions

About this article

Cite this article

Lehtola, L., Kauppinen, M., Vähäniitty, J. et al. Linking business and requirements engineering: is solution planning a missing activity in software product companies?. Requirements Eng 14, 113–128 (2009). https://doi.org/10.1007/s00766-009-0078-8

Download citation

  • Received:

  • Accepted:

  • Published:

  • Issue Date:

  • DOI: https://doi.org/10.1007/s00766-009-0078-8

Keywords

Navigation