Requirements Engineering

, Volume 14, Issue 2, pp 113–128 | Cite as

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

  • Laura Lehtola
  • Marjo KauppinenEmail author
  • Jarno Vähäniitty
  • Marko Komssi
Special Issue-RE'07 Best Papers


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.


Market-driven requirements engineering Roadmapping Long-term product planning Solution planning Solution concept 



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.


  1. 1.
    Boehm B (2003) Value-based software engineering. ACM Softw Eng Notes 28(2):3. doi: 10.1145/638750.638775
  2. 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–130Google Scholar
  3. 3.
    Gorchels L (2000) The product manager’s handbook—the complete product management resource, 2nd edn. NTC Business Books, Illinois, USAGoogle Scholar
  4. 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–49Google Scholar
  5. 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–508Google Scholar
  6. 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 CrossRefGoogle Scholar
  7. 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 CrossRefGoogle Scholar
  8. 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 CrossRefGoogle Scholar
  9. 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–37Google Scholar
  10. 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–124Google Scholar
  11. 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–446Google Scholar
  12. 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 CrossRefMathSciNetGoogle Scholar
  13. 13.
    Phaal R, Farrukh C, Mitchell R, Probert D (2003) Starting-up roadmapping fast. Res Technol Manage 46(2):52–58Google Scholar
  14. 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–374Google Scholar
  15. 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 CrossRefGoogle Scholar
  16. 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, BostonGoogle Scholar
  17. 17.
    Nambisan S (2001) Why service businesses are not product businesses. MIT Sloan Manage Rev 42(4):72–80MathSciNetGoogle Scholar
  18. 18.
    Cusumano M (2008) The changing software business: moving from products to services. IEEE Comput 41(1):20–27MathSciNetGoogle Scholar
  19. 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–142Google Scholar
  20. 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, SwedenGoogle Scholar
  21. 21.
    Chesbrough H, Spohrer JA (2006) A research manifesto for services science. Commun ACM 49(7):35–40. doi: 10.1145/1139922.1139945 CrossRefGoogle Scholar
  22. 22.
    Wiegers K (2003) Software requirements, 2nd edn. Microsoft Press, Redmond, WAGoogle Scholar
  23. 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–166Google Scholar
  24. 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 3Google Scholar
  25. 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–13Google Scholar
  26. 26.
    Grönroos C (2007) Service management and marketing: customer management in service competition, 3rd edn. Wiley, ChichesterGoogle Scholar
  27. 27.
    Hutchings AF, Knox ST (1995) Creating products: customers demand. Commun ACM 38(5):72–80. doi: 10.1145/203356.203370 CrossRefGoogle Scholar
  28. 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–162Google Scholar
  29. 29.
    Avison D, Lau F, Myers M, Nielsen P (1999) Action research. Commun ACM 42(1):94–97. doi: 10.1145/291469.291479 CrossRefGoogle Scholar
  30. 30.
    Stringer ET (1999) Action research, 2nd edn. Sage Publications, Thousand Oaks, CAGoogle Scholar
  31. 31.
    Patton MQ (2002) Qualitative research and evaluation methods, 3rd edn. Sage Publications, Thousand Oaks, CAGoogle Scholar
  32. 32.
    Potts C (1993) Software-engineering research revisited. IEEE Softw 10(5):19–28. doi: 10.1109/52.232392 CrossRefGoogle Scholar
  33. 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–4Google Scholar
  34. 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–325Google Scholar
  35. 35.
    Yin RK (1994) Case study research—design and methods, 2nd edn. Sage Publications, Thousand Oaks, CAGoogle Scholar
  36. 36.
    Webster FE (1994) Executing the new marketing concept. Mark Manage 3(1):8–16MathSciNetGoogle Scholar
  37. 37.
    Kim WC, Mauborgne R (2005) Blue ocean strategy. Harvard Business School Press, BostonGoogle Scholar
  38. 38.
    MacMillan IC, McGrath RG (1997) Discovering new points of differentiation. Harv Bus Rev (Jul/Aug):133–145Google Scholar
  39. 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–51Google Scholar

Copyright information

© Springer-Verlag London Limited 2009

Authors and Affiliations

  • Laura Lehtola
    • 1
  • Marjo Kauppinen
    • 1
    Email author
  • Jarno Vähäniitty
    • 1
  • Marko Komssi
    • 1
  1. 1.Software Business and Engineering InstituteHelsinki University of TechnologyTKKFinland

Personalised recommendations