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.

* After Kevin and Elliot's invited talks about past experience, everyone agrees, no doubt about the industrial need for a RETR solution. * Elliot's talk brings up this question, are we reinventing the wheel? Back in the 80's, there are quite many CASE tools in the market, but it is extremely hard to pursuade practitioners to press the Analysze button. What's going wrong? Elliot: To make reverse engineering tool (or CASE tools in general) adopted, we need to synchronize the forward engineered results with the requirements immediately. * What is the target of RETR? After Hai and Ying's presentations, we are a little bit lost: Hai's talking about abstract object states and test case generation, Ying was talking about business data and policies. In the afternoon we may hear more about goals and quality concerns. George: But wait a minute, what'is the right form of requirements since we are talking about them as the target of RETR? Hai: Requirements in the abstract object state work are useful to generate test cases. Test cases can be regarded as requirements. The problem we are solving is how to reduce the number of reverse engineered requirements so that they become understandable. Kenny: People talking about extreme programming and test-driven development. There is quite some agreement on test cases or use cases being requirements... Everyone agrees that requirements is something close to the business party, user or other stakeholders. They are well before the design and architecture, but to obtain them from the implementation, one has to go through some intermediate steps, and that is what makes the problem more interesting... * We need an industrial case study. George: Playing with toy examples such as open-source code is not necessarily convincing, what about the real needs in industry? In our organization, there are quite many practical projects to be RETR too. Which one is easier? To revamp the requirements from source code, or to dig them out from the metadata? * What can be the source of RETR? How can business policies be gathered from only the implementations if they are lost? Kenny: what's the difference between the if-then-else and the business policies? How to tell a condition is relevant to business or not? Ying: That's why we chose the 3-tier architecture to study because the business logic may tell us what is relevant to business. Kenny: Source code are not complete to be considered as the source of RETR, but they are the most reliable ones Yijun: In RE'05, we did some initial work on recovering the purposes of programmers or the reflected purposes of other stakeholders from the comments of the code. Matin Fowler's refactoring book says "a comment signal a semantic gap" between the code and the understanding. That's where we can find some of the requirements lost from the executable code. Another possibility is to generalize the idea of literate programming to maintain the traceability between requirements and code from the very beginning. Nazim: We need multiple stakeholders, not just the users, but also programmers, maintainers, etc. Also we need to be aware requirements are not always from the very beginning, it may arise during the development process. Thus we should establish the traceability among requirements and design decisions. By the end of the day, it is possible to trace back the changes all the way to the business partners. I will give a talk tomorrow at WICSA'05 on the subject. * How to adapt to the changing requirements, changing people, constraints alike? Nazim's point brings up another discussion on the changes or evolutions. How can we identify the lost changes if we do not have the code, people around? This come back to Elliot's earlier talk, we need to immediately RETR after any change to the implementation. Other topics briefly discussed, but not having time to explore much further: * Reengineering because the technology shifts to new fashion Kevin: We are moving into Web, C#, .NET, everytime there is a big shift in technology, one needs to consider interoperability of existing systems with the outside world. Sometimes you have to move on along with the technology shift. * Requirements from the application areas, not only the platforms Ying: You may have the same business requirements implemented differently in different platforms. * New tech makes new requirements feasible That's the topic in the afternoon, isn't it?
Every participant is free to continue submitting your opinion on the topic. We will set up a discussion forum soon.