The original CFP is given below.
Integration and interoperation have become the critical issues in engineering multi-stakeholder distributed systems (MSDS) like the Internet electronic mail system, networks of web services, modern telephone networks, and the Internet itself. MSDS require rethinking requirements engineering and validation, because they do not admit globally consistent high level requirements, requiring instead a personalized and time-dependent view of requirements, and because single stakeholders are largely ignorant of the detailed operation of nodes outside their sphere of control, making validation problematic.
Target audience. This workshop is intended to bring together researchers and practitioners in the fields of
Goals and structure. Our goals for the workshop are both to improve awareness of how open systems create novel problems for requirements engineering and to begin to explore potential solutions. To help focus the discussion, we have selected some open system scenarios (see full call for participation) and encourage each presentation to discuss how its ideas address or relate to the problems illustrated in the scenarios. The format of the presentations will include extra time for audience discussion of each presentation, hopefully allowing the group both to better understand each set of ideas and to relate them to other presentations and to the workshop themes.
A minimum two-page abstract should be submitted via e-mail to either of the workshop co-chairs in pdf (preferred) or ascii text format. Please see The Call For Proposals (CFP) for more information.
Workshop papers due: June 27, 2003 Notification to authors: July 18, 2003 Camera-ready: August 4, 2003 Workshop date: September 8, 2003Note that for workshop presentation choices, the committee will give preference to papers that address one or more of the topics/examples below (or those closely related).
The workshop will be part of the larger 2003 International Requirements Engineering Conference - see the conference web page at http://conferences.computer.org/RE/.
Integration and interoperation have become the critical issues in engineering multi-stakeholder distributed systems (MSDS) like the Internet electronic mail system, networks of web services, modern telephone networks, and the Internet itself. Consistent, well defined protocols and other low level requirements enable these systems to function, but higher level requirements placed by diverse users are often ephemeral and typically inconsistent when viewed together. Thus, for the field of requirements engineering to deal with open MSDSs at all, we need to shift our thinking from systems having consistent, global requirements to those in which requirements can be user-relative and ephemeral.
Beyond that issue, however, lurks a second major challenge dubbed the "ignorance problem": since the nodes of an MSDS are controlled by stakeholders with different goals, priorities, and capabilities, just knowing what they all do is a challenge. For example, email features and functionality have grown so complex that merely knowing a host serves TCP port 25 (SMTP) does not give enough information to know whether one's email message will be handled correctly. Current web services provide the means to discover method signatures. However, formal service standards have yet to be defined.
This workshop is intended to bring together researchers and practitioners in requirements engineering, component-based design (including Enterprise Application Integration (EAI)), verification and validation, and related fields to discuss the challenges of designing and using open systems in which requirements are ephemeral and user-relative, and in which it is difficult or impossible to know the behaviors of all the parts of the system.
We list some examples to help with the focus of the workshop. Ideally, a submission would explicitly explain how their approach, tool, idea, etc, would handle similar examples.
This example is drawn from a real project (contact fickas@cs.uoregon.edu for more details). User A wishes to get a ride to the doctor from user B. User A decides to send an email request to B asking for the ride. In slightly more formal terms, A's requirement is a yes or no answer from B to the ride request, in time to do A some good. The requirement is ephemeral: it endures for this ride request only, and may never come up again. The requirement is personal: it is A's requirement and contextualized to the components in place, at the request moment, to get a question to and reply from B.
It is an open system problem in that neither the Internet connectivity of A and B, the communication channel (the SMTP servers and post-office server) between A and B, nor the email client of A and B are under the control of all parties. In particular, A and/or B can be disconnected, email servers on either A's or B's side may filter email under administrative policy, the actual email clients themselves can filter email. Further, from A's point of view, B (the human) is part of the environment: B can ignore the request. In summary, the ride-request requirement can fail in many ways and it is impractical to attempt to guarantee success.
The questions this example raise in terms of the workshop are as follows:
This example comprises four stakeholders:
IT decides to improve everyone's life (on average) by connecting the corporate web proxy to AWS. Soon after that decision, C notices he or she is no longer receiving the latest news from U2M. This example has several relevant characteristics for the workshop:
Note that it is difficult to know without detailed debugging knowledge what causes the problem. Here are some alternative hypotheses. (1) AWS's contract has fine print explaining that it does not guarantee freshness of its pages, (2) AWS's contract is purposely inaccurate or unclear on this point. This would be an example of deception in MSDSs (see Example 3 below). (3) AWS's implementation is buggy, old, or incorrectly configured so that it does not honor "no-cache" header information. Note that AWS's service would still be acceptable for all users who don't access time critical sites. (4) U2M's implementation is buggy or incorrectly configured, so that it does not produce "no-cache" headers with its pages. Note that in this case, U2M would still work perfectly well for all clients who do not use caching. (5) IT failed to read or correctly interpret the AWS contract. (6) IT failed to realize that some of its users required freshness. (7) C failed to communicate to IT that it needed access to a time critical web site, even though IT surveyed its users on this point at some time previously. (Or maybe C's needs changed since the survey.)
Requirements and validation tools must deal with all these issues, since it is not reasonable to assume every node is implemented well or even in compliance with published standards; it is not reasonable to assume all requirements are accurately known, or that all stakeholders are honest; and it is not reasonable to assume that contracts (e.g. published interfaces) are correct, complete, and unambiguous. Clearly, a stakeholder needs ways to discover actual behavioral details, and to monitor plans as they execute for failures. How can we support these needs?
The previous two examples have shown the problems when well-intentioned components/stakeholders must be brought together to meet a personal requirement. But components in either example could have hidden goals. For instance, an SMTP server could be monitoring the email that it processes for marketing opportunities, harvesting email addresses for further bulk mailing. The AWS component could be monitoring visited pages and making the information available, for a price, to those interested in the surfing habits of the IT corporation. Ideally, we would like to be able to have a clear-box view into the behavior of the components, thus making hidden goals transparent. Barring that, are there other means of reasoning about deception in open systems? Are there ways to discourage it? Can we borrow reasoning methods from other fields that deal with potentially dishonest agents, e.g., game theory?
Workshop papers due: June 27, 2003 Notification to authors: July 18, 2003 Camera-ready: 8/4/03 Workshop date: September 8, 2003Note that for workshop presentation choices, the committee will give preference to papers that address one or more of the topics/examples below (or those closely related).
Workshop co-chairs: