Advertisement

From Conceptual Modeling to Requirements Engineering

  • Colette Rolland
Part of the Lecture Notes in Computer Science book series (LNCS, volume 4215)

Abstract

A number of studies show [1][2][3][4] that systems fail due to an inadequate or insufficient understanding of the requirements they seek to address. Further, the amount of effort needed to fix these systems has been found to be very high [5]. To correct this situation, it is necessary to address the issue of requirements elicitation, validation, and specification in a relatively more focussed manner. The expectation is that as a result of this, more acceptable systems will be developed in the future. The field of requirements engineering has emerged to meet this expectation.

Keywords

Requirement Engineering Software Product Line Requirement Engineer Requirement Elicitation System Life Cycle 
These keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.

Preview

Unable to display preview. Download preview PDF.

Unable to display preview. Download preview PDF.

References

  1. 1.
    Standish Group, Chaos. Standish Group Internal Report (1995)Google Scholar
  2. 2.
    European Software Institute, European User Survey Analysis, Report USV_EUR 2.1, ESPITI Project (1996)Google Scholar
  3. 3.
    McGraw, K., Harbison, K.: User Centered Requirements, The Scenario-Based Engineering Process. Lawrence Erlbaum Associates Publishers, Mahwah (1997)Google Scholar
  4. 4.
    META Group, Research on Requirements Realization and Relevance, report (2003)Google Scholar
  5. 5.
    Johnson, J.: Chaos: the Dollar Drain of IT project Failures. Application Development Trends, 41–47 (1995)Google Scholar
  6. 6.
    Hammer, T.F., Huffman, L.L., Rosenberg, L.H.: Doing requirements right the first time. Crosstalk - The Journal of Defense Software Engineering, 20–25 (December 1998)Google Scholar
  7. 7.
    Ramesh, B., Jarke, M.: Toward Reference Models for Requirements Traceability. IEEE Transactions on Software Engineering 27(1), 58–93 (2001)CrossRefGoogle Scholar
  8. 8.
    Finkelstein, A., Kramer, J., Goedicke, M.: ViewPoint Oriented Software Development. In: Proc. Conf. Le Génie Logiciel et ses Applications, Toulouse, pp. 337–351 (1990)Google Scholar
  9. 9.
    Bleistein, S., Cox, K., Verner, J.: Validating Strategic Alignment of Organisational IT Requirements using Goal Modeling and Problem Diagrams. Journal of Systems and Software 79(3), 362–378 (2006)CrossRefGoogle Scholar
  10. 10.
    Etien, A., Salinesi, C.: Managing Requirements in a Co-evolution Context. In: Proceedings of the IEEE International Conference on Requirements Engineering, Paris, France, pp. 125–134 (2005)Google Scholar
  11. 11.
    Ross, D.T., Schoman, K.E.: Structured Analysis for Requirements Definition. IEEE Transactions on Software Engineering 3(1), 6–15 (1977)CrossRefGoogle Scholar
  12. 12.
    Jarke, M., Pohl, K.: Establishing Visions in Context: Towards a Model of Requirements Processes. In: Proc. 12th Intl. Conf. Information Systems, Orlando (1993)Google Scholar
  13. 13.
    Rolland, C., Salinesi, C.: Modeling goals and reasoning with them. In: Aurum, A., Wohlin, C. (eds.) Engineering and Managing Requirements. TBP 2005, ch. 9. Springer, Heidelberg (2005)Google Scholar
  14. 14.
    Potts, C., Takahashi, K., Antòn, A.I.: Inquiry-based requirements analysis. IEEE Software 11(2), 21–32 (1994)CrossRefGoogle Scholar
  15. 15.
    Rolland, C., Souveyet, C., Ben Achour, C.: Guiding goal modelling using scenarios. IEEE Transactions on Software Engineering, Special Issue on Scenario Management 24(12), 1055–1071 (1998)Google Scholar
  16. 16.
    Dardenne, A., Lamsweerde, A.v., Fickas, S.: Goal-directed Requirements Acquisition. Science of Computer Programming, vol. 20, pp. 3–50. Elsevier, Amsterdam (1993)Google Scholar
  17. 17.
    Dubois, E., Yu, E., Pettot, M.: From early to late formal requirements: a process-control case study. In: Proc. IWSSD 1998 – 9th International Workshop on software Specification and design, pp. 34–42. IEEE Computer Society Press, Los Alamitos (1998)CrossRefGoogle Scholar
  18. 18.
    Anton, A.I., Potts, C., Takahanshi, K.: Inquiry Based Requirements Analysis. In: IEEE Conference on Requirements Engineering (1994)Google Scholar
  19. 19.
    Kaindl, H.: A design process based on a model combining scenarios with goals and functions. IEEE Trans. on Systems, Man and Cybernetic 30(5), 537–551 (2000)CrossRefGoogle Scholar
  20. 20.
    Lamsweerde, A.v.: Goal-oriented requirements engineering: a guided tour. In: RE 2001 International Joint Conference on Requirements Engineering, Toronto, pp. 249–263. IEEE, Los Alamitos (2001)Google Scholar
  21. 21.
    Loucopoulos, P.: The f3 (from fuzzy to formal) view on requirements engineering. Ingénierie des systèmes d’information 2(6), 639–655 (1994)Google Scholar
  22. 22.
    Rolland, C., Grosz, G., Kla, R.: Experience with goal-scenario coupling in Requirements engineering. In: Proceedings of the Fourth IEEE International Symposium on Requirements Engineering, Limerik, Ireland, pp. 74–84 (1999)Google Scholar
  23. 23.
    Hui, B., Liaskos, S., Mylopoulos, J.: Requirements Analysis for Customizable Software: A Goals-Skills-Preferences Framework. In: IEEE Conference on Requirements Engineering, Monterey Bay, USA, pp. 117–126 (2003)Google Scholar
  24. 24.
    Yue, K.: What does it mean to say that a specification is complete? In: Proc. IWSSD-4. Four International Workshop on Software Specification and Design, Monterrey, USA (1987)Google Scholar
  25. 25.
    Ramesh, B., Powers, T., Stubbs, C., Edwards, M.: Implementing requirements traceability: a case study. In: Proceedings of the 2nd Symposium on Requirements Engineering (RE 1995), UK, pp. 89–95 (1995)Google Scholar
  26. 26.
    Pohl, K.: Process centred requirements engineering. J. Wiley and Sons Ltd., Chichester (1996)Google Scholar
  27. 27.
    Bubenko, J., Rolland, C., Loucopoulos, P., De Antonellis, V.: Facilitating ‘fuzzy to formal’ requirements modelling. In: IEEE 1st Conference on Requirements Engineering, ICRE 1994, pp. 154–158 (1994)Google Scholar
  28. 28.
    Sommerville, I., Sawyer, P.: Requirements engineering. Worldwide Series in Computer Science. Wiley, Chichester (1997)MATHGoogle Scholar
  29. 29.
    Mostow, J.: Towards better models of the design process. AI Magazine 6, 44–57 (1985)Google Scholar
  30. 30.
    Hoh, P.: Multi-Criteria Preference Analysis for Systematic Requirements Negotiation. In: 26th Annual International Computer Software and Applications Conference, Oxford, England, p. 887 (2002)Google Scholar
  31. 31.
    Boehm, B., Bose, P., Horowitz, E., Ming-June, L.: Software requirements as negotiated win conditions. In: 1st International Conference on Requirements Engineering, USA, pp. 74–83 (1994)Google Scholar
  32. 32.
    Karlsson, J., Olsson, S., Ryan, K.: Improved Practical Support for Large-scale Requirements Prioritizing. Journal of Requirements Engineering, 51–60 (1997)Google Scholar
  33. 33.
    Moisiadis, F.: The Fundamentals of Prioritising Requirements Systems Engineering. In: Test & Evaluation Conference, Sydney, Australia (2002)Google Scholar
  34. 34.
    Nuseibeh, B., Kramer, J., Finkelstein, A.: A framework for expressing the relationships between multiple views in requirements specification. IEEE Transactions on Software Engineering 20, 760–773 (1994)CrossRefGoogle Scholar
  35. 35.
    Lamsweerde, A.v., Letier, E.: Handling obstacles in goal-oriented requirements engineering. IEEE Transactions on Software Engineering, Special Issue on Exception Handling 26(10), 978–1005 (2000)Google Scholar
  36. 36.
    Robinson, W.N., Volcov, S.: Conflict Oriented Requirements Restructuring. Working Paper CIS-96-15 (1996)Google Scholar
  37. 37.
    Robinson, W.N., Volkov, S.: Supporting the Negotiation Life-Cycle. Communications of the ACM, 95–102 (1998)Google Scholar
  38. 38.
    Easterbrook, S.M.: Resolving Requirements Conflicts with Computer-Supported Negotiation. In: Jirotka, M., Goguen, J. (eds.) Requirements Engineering: Social and Technical Issues, pp. 41–65. Academic Press, London (1994)Google Scholar
  39. 39.
    Svahnberg: On the notion of variability in Software Product Lines. In: Working IEEE/IFIP Conference on Software architecture, pp. 45–54 (2001)Google Scholar
  40. 40.
    Bosch: Variability issues in Software Product Lines. In: 4th International Workshop on Product Family Engineering (PEE-4), Bilbao, Spain, pp. 13–21 (2001)Google Scholar
  41. 41.
    Van Gurp, J.: Variability in Software Systems, the key to Software Reuse. Licentiate Thesis, University of Groningen, Sweden (2000)Google Scholar
  42. 42.
    Bachmann: Managing variability in software architecture. ACM Press, NY (2001)Google Scholar
  43. 43.
    Halmans, J.: Communicating the variability of a software product family to customers. Software and System Modeling. Springer, Heidelberg (2003)Google Scholar
  44. 44.
    Rolland, C., Prakash, N.: Bridging the gap between Organizational needs and ERP functionality. Requirements Engineering journal 5 (2000)Google Scholar
  45. 45.
    Rolland, C., Salinesi, C., Etien, A.: Eliciting Gaps in Requirements Change. Requirements Engineering Journal 9, 1–15 (2004)CrossRefGoogle Scholar
  46. 46.
    Rolland, C.: Modeling Multi-facetted Purposes of Artifact. In: SOMET Int. Conference. IOS Press, Tokyo (2005)Google Scholar

Copyright information

© Springer-Verlag Berlin Heidelberg 2006

Authors and Affiliations

  • Colette Rolland
    • 1
  1. 1.Université Paris1 Panthéon SorbonneParis

Personalised recommendations