Building Formal Requirements Models for Reliable Software

  • Axel van Lamsweerde
Conference paper
Part of the Lecture Notes in Computer Science book series (LNCS, volume 2043)


Requirements engineering (RE) is concerned with the elicitation of the goals to be achieved by the system envisioned, the operationalization of such goals into specifications of services and constraints, and the assignment of responsibilities for the resulting requirements to agents such as humans, devices, and software. Getting high-quality requirements is difficult and critical. Recent surveys have confirmed the growing recognition of RE as an area of primary concern in software engineering research and practice.

The paper first briefly introduces RE by discussing its main motivations, objectives, activities, and challenges. The role of rich models as a common interface to all RE processes is emphasized. We review various techniques available to date for system modeling, from semi-formal to formal, and discuss their relative strengths and weaknesses when applied during the RE stage of the software lifecycle.

The paper then discusses some recent efforts to overcome such problems through RE-specific techniques for goal-oriented elaboration of requirements, multiparadigm specification, the integration of non-functional requirements, the anticipation of abnormal agent behaviors, and the management of conflicting requirements.


Requirement Engineering Reliable Software Requirement Engineer Responsibility Assignment Domain Property 
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.


Unable to display preview. Download preview PDF.

Unable to display preview. Download preview PDF.


  1. [BART99]
    Bay Area Rapid Transit District, Advance Automated Train Control System, Case Study Description. Sandia National Labs,
  2. [Bel76]
    T.E. Bell and T.A. Thayer, “Software Requirements: Are They Really a Problem?”, Proc. ICSE-2: 2 nd Intrnational Conference on Software Enginering, San Francisco, 1976, 61–68.Google Scholar
  3. [Boe81]
    B.W. Boehm, Software Engineering Economics. Prentice-Hall, 1981.Google Scholar
  4. [Bro87]
    F.P. Brooks “No Silver Bullet: Essence and Accidents of Software Engineering”. IEEE Computer, Vol. 20No. 4, April 1987, pp. 10–19.MathSciNetGoogle Scholar
  5. [Dar93]
    A. Dardenne, A. van Lamsweerde and S. Fickas, “Goal-Directed Requirements Acquisition”, Science of Computer Programming, Vol. 20, 1993, 3–50.zbMATHCrossRefGoogle Scholar
  6. [Dar96]
    R. Darimont and A. van Lamsweerde, “Formal Refinement Patterns for Goal-Driven Requirements Elaboration”, Proc. FSE’4–Fourth ACM SIGSOFT Symposium on the Foundations of Software Engineering, San Francisco, October 1996, 179–190.Google Scholar
  7. [Eas94]
    S. Easterbrook, “Resolving Requirements Conflicts with Computer-Supported Negotiation”. In Requirements Engineering: Social and Technical Issues, M. Jirotka and J. Goguen (Eds.), Academic Press, 1994, 41–65.Google Scholar
  8. [ESI96]
    European Software Institute, “European User Survey Analysis”, Report USV_EUR 2.1, ESPITI Project, January 1996.Google Scholar
  9. [Heit96]
    C. Heitmeyer, R. Jeffords and B. Labaw, “Automated Consistency Checking of Requirements Specificatons”, ACM Transactions on Software Engineering and Methodology Vol. 5No. 3, July 1996, 231–261.CrossRefGoogle Scholar
  10. [Hun98]
    A. Hunter and B. Nuseibeh, “Managing Inconsistent Specifications: Reasoning, Analysis and Action”, ACM Transactions on Software Engineering and Methodology, Vol. 7No. 4. October 1998, 335–367.CrossRefGoogle Scholar
  11. [Jac95]
    M. Jackson, Software Requirements & Specifications–A Lexicon of Practice, Principles and Pejudices. ACM Press, Addison-Wesley, 1995.Google Scholar
  12. [Koy92]
    R. Koymans, Specifying message passing and time-critical systems with temporal logic, LNCS 651, Springer-Verlag, 1992.zbMATHGoogle Scholar
  13. [Lam98a]
    A. van Lamsweerde, R. Darimont and E. Letier, “Managing Conflicts in Goal-Driven Requirements Engineering”, IEEE Trans. on Sofware. Engineering, Special Issue on Inconsistency Management in Software Development, November 1998.Google Scholar
  14. [Lam98b]
    A. van Lamsweerde and L. Willemet, “Inferring Declarative Requirements Specifications from Operational Scenarios”, IEEE Trans. on Sofware. Engineering, Special Issue on Scenario Management, December 1998, 1089–1114.Google Scholar
  15. [Lam2Ka]
    A. van Lamsweerde, “Requirements Engineering in the Year 00: A Research Perspective”, Keynote paper, Proc. ICSE’2000–22 nd Intl. Conference on Software Engineering, IEEE Press, June 2000.Google Scholar
  16. [Lam2Kb]
    A. van Lamsweerde, “Formal Specification: a Roadmap”. In The Future of Software Engineering, A. Finkelstein (ed.), ACM Press, 2000.Google Scholar
  17. [Lam2Kc]
    A. van Lamsweerde and E. Letier, “Handling Obstacles in Goal-Oriented Requirements Engineering”, IEEE Transactions on Software Engineering, Special Issue on Exception Handling, October 2000.Google Scholar
  18. [Let2K]
    þE. Letier and A. van Lamsweerde, “KAOS in Action: the BART System”. IFIP WG2.9 meeting, Flims,
  19. [Let01]
    E. Letier, Reasoning About Agents in Goal-Oriented Requirements Engineering. PhD Thesis, University of Louvain, 2001.Google Scholar
  20. [Lev95]
    N. Leveson, Safeware–System Safety and Computers. Addison-Wesley, 1995.Google Scholar
  21. [Man92]
    Z. Manna and A. Pnueli, The Temporal Logic of Reactive and Concurrent Systems, Springer-Verlag, 1992.Google Scholar
  22. [Mas97]
    P. Massonet and A. van Lamsweerde, “Analogical Reuse of Requirements Frameworks”, Proc. RE-97–3rd Int. Symp. on Requirements Engineering, Annapolis, 1997, 26–37.Google Scholar
  23. [Mey85]
    B. Meyer, “On Formalism in Specifications”, IEEE Software, Vol. 2No. 1, January 1985, 6–26.CrossRefGoogle Scholar
  24. [Myl92]
    Mylopoulos, J., Chung, L., Nixon, B., “Representing and Using Nonfunctional Requirements: A Process-Oriented Approach”, IEEE Trans. on Sofware. Engineering, Vol. 18No. 6, June 1992, pp. 483–497.CrossRefGoogle Scholar
  25. [Myl99]
    J. Mylopoulos, L. Chung and E. Yu, “From Object-Oriented to Goal-Oriented Requirements Analysis”, Communications of the ACM, Vol. 42No. 1, January 1999, 31–37.CrossRefGoogle Scholar
  26. [Nus94]
    B. Nuseibeh, J. Kramer and A. Finkelstein, “A Framework for Expressing the Relationships Between Multiple Views in Requirements Specifications”, IEEE Transactions on Software Engineering, Vol. 20No. 10, October 1994, 760–773.CrossRefGoogle Scholar
  27. [Owr95]
    S. Owre, J. Rushby, and N. Shankar, “Formal Verification for Fault-Tolerant Architectures: Prolegomena to the Design of PVS”, IEEE Transactions on Software Engineering Vol. 21No. 2, Feb. 95, 107–125.Google Scholar
  28. [Par95]
    D.L. Parnas and J. Madey, “Functional Documents for Computer Systems”, Science of Computer Programming, Vol. 25, 1995, 41–61.CrossRefGoogle Scholar
  29. [Pot96]
    B. Potter, J. Sinclair and D. Till, An Introduction to Formal Specification and Z. Second edition, Prentice Hall, 1996.Google Scholar
  30. [Rum99]
    J. Rumbaugh, I. Jacobson and G Booch, The Unified Modeling Language Reference Manual. Addison-Wesley, Object Technology Series, 1999.Google Scholar
  31. [Sta95]
    The Standish Group, “Software Chaos”,
  32. [Yue87]
    K. Yue, “What Does It Mean to Say that a Specification is Complete?”, Proc. IWSSD-4, Fourth International Workshop on Software Specification and Design, IEEE, 1987.Google Scholar

Copyright information

© Springer-Verlag Berlin Heidelberg 2001

Authors and Affiliations

  • Axel van Lamsweerde
    • 1
  1. 1.Département d’Ingénierie InformatiqueUniversité catholique de LouvainLouvain-la-NeuveBelgium

Personalised recommendations