Moderator: 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.

Let's sum up. Everyone can say sth. about what impress you the most 
in the workshop and what is your stand for RETR.
Kevin: With a little further instrumentation or tools, I learnt 
what kinds of tools can be applied to some of the use in our company, for
example to configure metadata. 
Hausi: A system engineering rather than a software engineering 
point of view of requirements can draw a boundary on what to be specified 
in RETR.
George: John can you explain what are the requirements from the RE community?
John: In the RE community: (1) software requirements are expressed
by functional/non-functional reqirements, which are late requirements
compare to those early ones. (2) Early requirements arise from an 
organizational context, which then can be refined into late requirements 
(3) After delegations of the responsibility of a requirements to an actor, 
    the system/environment boundary is defined
Hausi: When reversed, communicating the evolving requirements needs 
instrumentation-like (E.g. scripts to extract architecture diagrams 
in Kenny Wong's work on reverse engineering notebooks). From reverse
engineering we saw work on extracting semantics from the vocabulary, then clustering them. 
This technique is not used much for abstract requirements. 
John: To build ontology from the extracted information, you need 
heuristics, assumption such as what names are meaningful.
Kenny: For example, to count variable occurrence in the source code
John: RE educates people to do the right thing in SE, 
the next best thing is to ask reverse engineering to help people 
do it right.
George: Maybe we need design patterns of the reverse engineering to make RETR easier: 
What went wrong? What and where are the changing requirements?
We all understand cost of fixing them in later phases is huge, but it seldom 
happens that people start doing things right at an early stage.
Hausi: To do things right early, we  got to instrument everything
John: Try tradeoffs
Kevin: 70%-80% of my company job is on requirements than coding 
Ying: Requirements is broader than software, e.g. business, and user's 
        point-of-views are also requirements.

Yijun: We can continue the discussions in the next workshop,
    maybe collocated with either RE'06 or WCRE'06. Thanks again for all the 
    participants!


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