Requirements Engineering

, Volume 11, Issue 1, pp 79–101 | Cite as

Requirements Abstraction Model

  • Tony GorschekEmail author
  • Claes Wohlin
Original Article


Software requirements arrive in different shapes and forms to development organizations. This is particularly the case in market-driven requirements engineering, where the requirements are on products rather than directed towards projects. This results in challenges related to making different requirements comparable. In particular, this situation was identified in a collaborative effort between academia and industry. A model, with four abstraction levels, was developed as a response to the industrial need. The model allows for placement of requirements on different levels and supports abstraction or break down of requirements to make them comparable to each other. The model was successfully validated in several steps at a company. The results from the industrial validation point to the usefulness of the model. The model will allow companies to ensure comparability between requirements, and hence it generates important input to activities such as prioritization and packaging of requirements before launching a development project.


Market-driven product-centered continuous requirements engineering Requirements abstraction Product management Product strategy 



The work and results presented in this article were done and produced in close and fruitful cooperation between research and industry. The authors would like to thank everyone involved during the SPI work at DHR and especially the members of the SPI work team for their commitment and tireless work.

This work was partly funded by The Knowledge Foundation in Sweden under a research grant for the project “Blekinge—Engineering Software Qualities (BESQ)” (


  1. 1.
    Ruhe G, Greer D (2003) Quantitative studies in software release planning under risk and resource constraints. In: Proceedings of international symposium on empirical software engineering (ISESE), IEEE, Los Alamitos, CA, pp 262–271Google Scholar
  2. 2.
    Butscher SA, Laker M (2000) Market-driven product development. Market Manag 9:48–53Google Scholar
  3. 3.
    Sommerville I (2001) Software engineering. Addison-Wesley, EssexGoogle Scholar
  4. 4.
    Carlshamre P (2002) Release planning in market-driven software product development: provoking an understanding. Requirements Eng 7:139–151CrossRefGoogle Scholar
  5. 5.
    Yeh AC (1992) Requirements engineering support technique (request): a market driven requirements management process. In: Proceedings of the second symposium on assessment of quality software development tools, pp 211–223Google Scholar
  6. 6.
    Carlshamre P, Sandahl K, Lindvall M, Regnell B, Natt och Dag J (2001) An industrial survey of requirements interdependencies in software product release planning. In: Proceedings of fifth IEEE international symposium on requirements engineering, IEEE, Los Alamitos, CA, pp 84–92Google Scholar
  7. 7.
    Dahlstedt Å, Persson A (2003) Requirements interdependencies—moulding the state of research into a research agenda. In: Ninth international workshop on requirements engineering (REFSQ’03), Klagenfurt/Velden, Austria, pp 71–80Google Scholar
  8. 8.
    Regnell B, Host M, Natt och Dag JBP, Hjelm T (2001) An industrial case study on distributed prioritisation in market-driven requirements engineering for packaged software. Requirements Eng 6:51–62CrossRefzbMATHGoogle Scholar
  9. 9.
    Greer D, Ruhe G (2004) Software release planning: an evolutionary and iterative approach. Inf Software Technol 46:243–253CrossRefGoogle Scholar
  10. 10.
    Weber M, Weisbrod J (2003) Requirements engineering in automotive development: experiences and challenges. IEEE Software 20:16–24CrossRefGoogle Scholar
  11. 11.
    Higgins SA, de Laat M, Gieles PMC (2003) Managing requirements for medical IT products. IEEE Software 20:26–34CrossRefGoogle Scholar
  12. 12.
    Potts C (1997) Requirements models in context. In: Proceedings of the third IEEE international symposium on requirements engineering, IEEE, Los Alamitos, CA, pp 102–104Google Scholar
  13. 13.
    Potts C, Hsi I (1997) Abstraction and context in requirements engineering: toward a synthesis. Ann Software Eng 3:23–61CrossRefGoogle Scholar
  14. 14.
    Anton AI (1996) Goal-based requirements analysis. In: Proceedings of the second international conference on requirements engineering, IEEE, Los Alamitos, CA, pp 136–144Google Scholar
  15. 15.
    Kavakli E, Loucopoulos P, Filippidou D (1996) Using scenarios to systematically support goal-directed elaboration for information system requirements. In: Proceedings of IEEE symposium and workshop on engineering of computer-based systems, IEEE, Los Alamitos, CA, pp 308–314Google Scholar
  16. 16.
    Castro J, Kolp M, Mylopoulos J (2002) Towards requirements-driven information systems engineering: the Tropos project. Inf Syst 27:365–389CrossRefzbMATHGoogle Scholar
  17. 17.
    Wiegers KE (1999) Software requirements. Microsoft Press, RedmonGoogle Scholar
  18. 18.
    Lauesen S (2000) Software requirements: styles and techniques. Samfundslitteratur, FredriksbergGoogle Scholar
  19. 19.
    Robertson S, Robertson J (1999) Mastering the requirements process. Addison-Wesley, HarlowGoogle Scholar
  20. 20.
    Gorschek T, Wohlin C (2003) Identification of improvement issues using a lightweight triangulation approach (Eurospi’03). In: European software process improvement conference, Verlag der Technischen Universität, Graz, Austria, pp VI.1–VI.14Google Scholar
  21. 21.
    Gorschek T, Wohlin C (2004) Packaging software process improvement issues—a method and a case study. Software Pract Experience 34(14):1311–1344CrossRefGoogle Scholar
  22. 22.
    Sawyer P, Sommerville I, Viller S (1999) Capturing the benefits of requirements engineering. IEEE Software 16:78–85CrossRefGoogle Scholar
  23. 23.
    Sommerville I, Sawyer P (1999) Requirements engineering: a good practice guide. Wiley, ChichesterGoogle Scholar
  24. 24.
    Pfleeger SL (1998) Software engineering: theory and practice. Prentice-Hall, LondonGoogle Scholar
  25. 25.
    Martin S, Aurum A, Jeffery R, Barbara P (2002) Requirements engineering process models in practice. In: Seventh Australian workshop on requirements engineering (AWRE’02), Melbourne, Australia, pp 141–155Google Scholar
  26. 26.
    Juristo N, Moreno AM, Silva A (2002) Is the European industry moving toward solving requirements engineering problems? IEEE Software 19:70–78CrossRefGoogle Scholar
  27. 27.
    Gorschek T, Svahnberg M, Tejle K (2003) Introduction and application of a lightweight requirements engineering process evaluation method. In: Requirements engineering: foundation for software quality (REFSQ’03), Velden, Austria, pp 101–112Google Scholar
  28. 28.
    Kivisto K (1999) Roles of developers as part of a software process model. In: Proceedings of the 32nd annual Hawaii international conference on systems sciences, IEEE Computer Society, pp 1–19Google Scholar
  29. 29.
    Humphrey WS (2000) Introduction to the team software process. Addison-Wesley, ReadingGoogle Scholar
  30. 30.
    Fritzhanns T, Kudorfer F (2002) Product management assessment—a new approach to optimize the early phases. In: Proceedings of IEEE joint international conference on requirements engineering, IEEE, Los Alamitos, CA, pp 124–134Google Scholar
  31. 31.
    Rakitin SR (2001) Software verification and validation for practitioners and managers. Artech House, BostonGoogle Scholar
  32. 32.
    Lehmann DR, Winer RS (2002) Product management. McGraw-Hill, BostonGoogle Scholar
  33. 33.
    Kotonya G, Sommerville I (1998) Requirements engineering: processes and techniques. Wiley, New YorkGoogle Scholar
  34. 34.
    Robson C (2002) Real world research: a resource for social scientists and practitioner-researchers. Blackwell, OxfordGoogle Scholar

Copyright information

© Springer-Verlag London Limited 2005

Authors and Affiliations

  1. 1.School of EngineeringBlekinge Institute of TechnologyRonnebySweden

Personalised recommendations