CS2125 Paper Review Form - Winter 2018

Reviewer: Or Aharoni

Paper Title: Detection of Conflicting Functional Requirements in a Use Case-Driven Approach

Author(s): Jan Hendrik Hausmann, Reiko Heckel, and Gabi Taentzer

1) Is the paper technically correct?
 [x] Yes
 [ ] Mostly (minor flaws, but mostly solid)
 [ ] No

2) Originality
 [ ] Very good (very novel, trailblazing work)
 [x] Good 
 [ ] Marginal (very incremental)
 [ ] Poor (little or nothing that is new)

3) Technical Depth
 [ ] Very good (comparable to best conference papers)
 [x] Good (comparable to typical conference papers)
 [ ] Marginal depth
 [ ] Little or no depth

4) Impact/Significance
 [ ] Very significant
 [x] Significant
 [ ] Marginal significance.
 [ ] Little or no significance.

5) Presentation
 [ ] Very well written
 [x] Generally well written
 [ ] Readable
 [ ] Needs considerable work
 [ ] Unacceptably bad

6) Overall Rating
 [ ] Strong accept (award quality)
 [x] Accept (high quality - would argue for acceptance)
 [ ] Weak Accept (borderline, but lean towards acceptance)
 [ ] Weak Reject (not sure why this paper was published)


7) Summary of the paper's main contribution and rationale for your recommendation. (1-2 paragraphs)

The authors of the paper came to provide a solution within UML to present how classes interact with 
each other and presenting the views of different users. The paper gave a scenario of writing a 
software program of shopping in a store. The authors for describe that in most cases someone will 
create classes with modules that describe the different roles in the process like a Clerk class and 
a Client class. Both of these class have a method that comes to solve the process of transferring 
ownership of products, “Sell Goods” and “Buy Goods” respectable. Each from the view of the class, 
which is good. The issue that the authors come to solve is how do these two methods interact with 
one another and provide the intended result of transferring the goods, including creating a proper 
bill and payment process. 
   
The authors provided some tool of how to percent objects, like Clients and Clerks, interact with 
each other and if there are dependencies between them. In the example that was given in the paper: 
a client taking ownership of a product depends on paying a bill which depends on the Clerk creating 
a bill which depends on the Client picking and presenting the product(s) to the clerk. The authors 
came to solve the issue of how to present dependencies of modules to one another and how they 
interact with one another. This includes dependencies in different objects.

The authors mentioned that the modeler needs to understand the formal and causal dependences and 
links of objects in the application. The authors used notations similar to Petri nets to present 
the interaction of between the objects. By doing this gives developers a visual descriptions of the 
steps need to be taken a proper module diagram.  


8) List 1-3 strengths of the paper.  (1-2 sentences each,identified as S1, S2, S3.)

S1: The paper came to solve an important issue when of being able to describe how objects interact
and depend on each other. The authors provided a solution of how to describe the connections between
the different objects. Figures 13 and 14 where used to explain how a proper explanation should be. 

9) List 1-3 weaknesses of the paper (1-2 sentences each,
identified as W1, W2, W3.)

W1: A weakness that the paper had is that it took a long way to explain logical data and UML 
Component Diagrams that could have been used. In both of these diagram modules there is possibility 
of describing both the technical and business needs of a solution not just the technical aspect. 
The authors were trying to show that there is a need to show the business aspect as well as the 
technical aspect but went a long way to explain it.