Living With Inconsistency

Workshop Chair & Contact:

Workshop Vice-Chairs:

Workshop Focus:

Traditional work on inconsistency in Requirements Engineering has viewed consistency as a virtue and inconsistency as a bug. The notion of an inconsistent specification has generated methods and models for detecting and removing inconsistency as early as possible. In this workshop, we take a broader view. We are interested in the Requirements Engineering of systems that may need to, or may even want to live with inconsistency. There are three key sources of such inconsistency that we wish to consider at the workshop:

• Viewpoint inconsistency brought about by multiple stakeholders with differing requirements. If these are not completely resolved at design time, how should the resulting system handle such inconsistencies if and when they arise at run time?
• Process enactment inconsistency brought about by a mismatch between a software process model and its enactment in the real world.
• Runtime inconsistency brought about by inconsistent views of the environment. Causes can be either an inaccurate modeling of the environment during the RE process, or by an environment that changes once a system is in place.

We believe that, for a large number of systems, each of these three types of inconsistency will be inevitable and impossible to avoid. Instead, mechanisms must be devised to live with them and mitigate their negative impact. We are particularly interested in bridging the largest gap of all, that between requirements time reasoning, and run-time actions.

The research areas that arise out of our view of inconsistency are as follows:

• Designing for inconsistency - e.g., languages for capturing differing viewpoints, languages for capturing process enactment inconsistency, languages for stating breakable environmental assumptions.
• Detecting inconsistency - e.g., monitoring for inconsistent requirements among a group of stakeholders, monitoring for enactment-time process inconsistencies, monitoring for run-time requirements failures.
• Responding to inconsistency - e.g., negotiating among stakeholders to form a consistent set of requirements, dynamically recasting a process model to reflect inconsistent enactment, redesigning a system (possibly in situ) to meet a new set of environment needs.
• Cost/benefit analysis - what effort should be put into finding and removing inconsistencies prior to enactment/production versus the effort of handling inconsistencies on the fly when (if ever) they arise in the enacted process or delivered system?

Workshop Format & Submission

We plan an intensive 1-day workshop. To encourage interaction, there will be maximum of 20 participants.

We encourage those with an interest in any of these research areas to submit a short position paper by Monday March 17th 1997 (St Patrick's Day) to Fickas (address below). Electronic submission, in the form of a plain text or postscript file, preferred.

Prof. Stephen Fickas
Dept. of Computer Science
University of Oregon Eugene
Oregon 97403
USA

email: fickas@cs.uoregon.edu
tel: +1 541 346 3964

Also of interest: