Leaving Inconsistency

Two descriptions are inconsistent if there is no way to satisfy them altogether. Inconsistencies may arise under many circumstances in the software lifecycle. They are often inevitable, for instance, when the descriptions are produced or evolve independently from each other. Sometimes they may even be desirable, for instance, to allow further elicitation of requirements descriptions being acquired from multiple stakeholders.

[1]  Philippe Massonet,et al.  Goal-directed elaboration of requirements for a meeting scheduler: problems and lessons learnt , 1995, Proceedings of 1995 IEEE International Symposium on Requirements Engineering (RE'95).

[2]  Martin S. Feather,et al.  Requirements monitoring in dynamic environments , 1995, Proceedings of 1995 IEEE International Symposium on Requirements Engineering (RE'95).

[3]  Axel van Lamsweerde,et al.  Divergent views in goal-driven requirements engineering , 1996, ISAW/Viewpoints@FSE.

[4]  Stephen Fickas,et al.  Knowledge Representation and Reasoning in the Design of Composite Systems , 1992, IEEE Trans. Software Eng..

[5]  Stephen Fickas,et al.  Goal-Directed Requirements Acquisition , 1993, Sci. Comput. Program..

[6]  Axel van Lamsweerde,et al.  Formal refinement patterns for goal-driven requirements elaboration , 1996, SIGSOFT '96.

[7]  Colin Potts,et al.  Using schematic scenarios to understand user needs , 1995, Symposium on Designing Interactive Systems.

[8]  Richard Waldinger,et al.  Achieving several goals simultaneously , 1977 .

[9]  Carlo Ghezzi,et al.  A framework for formalizing inconsistencies and deviations in human-centered systems , 1996, TSEM.

[10]  Peter Neumann,et al.  Safeware: System Safety and Computers , 1995, SOEN.