Moderator: This room arrangement makes it possible to do panel 
discussions conveniently at the round table. Everyone is encouraged to speak!  
Here is a summary of what have been discussed. 
* Format clue: below we denote a participant by
the first name and use a colon to lead the opinion statement. The statements 
are not exact as uttered, but should be close to the meaning. Correct me
if I understood it not as intended.

In the new era of connectivity and openness, is there a place for the
use of requirements at run-time? If there is, then RETR is important
because often software does not come with its requirements. Let's focus
on new paradigms for software applications, such as Web Services and
Autonomic Computing.
   Yijun: An element of autonomic system should keep requirements in its knowledge base. 
   Andrea: Web services runtime discovery/composition needs some 
                 description of the requirements
   George: I am doing contracts with DOD. The kind of software we are
                  developing are Net-centric, UDDI-based. Typically involving 
           (1) find a (good) service 
           (2) keep using the service (E.g. enterprise integration, we need to 
	       trust the services that fulfill the requirements and
               keep fulfilling them statically)
   Hai: Dynamic (runtime) information are useful for the behavior of
         software systems. We believe in a hybrid (static/runtime) solution: 
         depends how complete it is required. We shall look for just-enough 
         (minimal) requirements by observing the user's behavior.
   John: The potential use of requirements at run-time should be decided on
   basis of experiments, rather than academic claims. For example,
   in the 60s people researched the possibility of using natural 
   language processing (NLP) techniques to improve the accuracy of
   information retrieval methods (along with keyword search). 
   It turned out that NLP techniques were costly and didn't make 
   retrieval any more accurate.
   George: What's the real problem in understanding a service? 
      Specification information should populate for understanding the service, 
      also known as a Yellow Pages (UDDI). 
   Kenny: It depends also on who is the authority in determining 
      whether the RETR results are good.
   Kevin: What's your opinion on building the trust?
   Alexei: I think it is the reputation of the service provider, and 
      it also depends on the contextual information.
   Kenny: Web Services are not trusted automatically (like hospitals 
      are not trusted by patients automatically). There is also a social 
      problem for building the trust.
   Yijun: Multiple criteria exist for evaluating Web Services, 
      Quality of Services (QoS) that are promised by the provider and perceived
      by the users may have a gap to damage the trust.
   Hausi: Going up the chaining, Web Service will be a core for 
      implementing autonomic systems.
   John: Open-ended (fits-your-needs) service, or close-ended
  (exclusively depends on social relations, specialized) reflect the
  purposes of the systems.
   Alexei: Whether you will keep or replace a component for the new 
      context?
   Nazim: How to compare these alternatives: 
    (1) too much information gathered from instrumentation, is it an overload?
    (2) What if information presents different level of granularity for 
        different person, expert or user?
   Hausi: In the past, we saw the left-hand-side of the horseshoe
       model (reverse engineering) got more attention than the right-hand-side
       (forward reengineering).  What's your opinion about that?
   John: We need to study legacy system to configure its 
   (non-)functionality, to figure out what to be analyzed and what need
   tradeoffs?
   George: I heard about the utility tree to make tradeoffs.
   Hausi: Can you attach an autonomic element without touching the 
      legacy system? 
   John: We need hooks in the legacy system to attach them. 
   Hausi: I believe instrumentation can help us: such as to 
      kill the malfunctioning Web Services, to resolve memory leak C programs,
      to observe the system, making decisions or change to it, etc.  
   Yijun: Time is up for the panel. We can continue the dicussion in
      the wrap-ups. 


Every participant is free to continue elaborate your opinion on the 
topic. We will set up a discussion forum soon.