logseq/pages/@MODELS_2025_paper_85.md

tags:: [[#zotero]]
title:: @MODELS_2025_paper_85
item-type:: [[document]]
original-title:: MODELS_2025_paper_85
language:: en
links:: [Local library](zotero://select/library/items/NISUMPS4), [Web library](https://www.zotero.org/users/1039502/items/NISUMPS4)

- ### Attachments
	- [PDF](zotero://select/library/items/443HYUW3) {{zotero-imported-file 443HYUW3, "MODELS_2025_paper_85.pdf"}}
- ### Notes
	- I'm reviewing a research paper and I took the following notes:
	  
	  # Annotazioni 
	   (22/5/2025, 16:21:55)
	  
	  - “Requirement Extraction” (“MODELS_2025_paper_85”, p. 1) #a28ae5
	  
	  - “Use Case Modeling” (“MODELS_2025_paper_85”, p. 1) #a28ae5
	  
	  - “from User Stories” (“MODELS_2025_paper_85”, p. 1) #a28ae5
	  
	  - “Early-stage software modeling plays a crucial role in capturing stakeholders’ intentions and ensuring that the system aligns with user requirements.” (“MODELS_2025_paper_85”, p. 1) #5fb236
	  
	  - “transitioning from the natural language of user stories to structured artifacts, such as UML use case diagrams and full use case descriptions, remains challenging for analysts—especially for novices—due to its time-consuming, tedious, and susceptible to errors.” (“MODELS_2025_paper_85”, p. 1) #a28ae5
	  
	  - “Story2Spec, a DeepSeek-based tool that classifies user stories into requirements according to the FURPS model (functional, usability, performance, reliability, and supportability).” (“MODELS_2025_paper_85”, p. 1) #a28ae5
	  
	  - “it generates use case diagrams following UML syntax language and use cases descriptions based on a predefined template.” (“MODELS_2025_paper_85”, p. 1) #5fb236
	  
	  - “Story2Spec tool generates consistent and interpretable use case diagrams with clear and detailed use case descriptions” (“MODELS_2025_paper_85”, p. 1) #5fb236
	  
	  - “the proposed tool can significantly support the specification phase and, thus, mitigate the burden on analysts when identifying software artifacts” (“MODELS_2025_paper_85”, p. 1) #5fb236
	  
	  - “A clear definition of user needs and system interactions and behavior paves the way for understandable and well-structured UML diagrams, which can positively impact communication among stakeholders, users, and developers” (“MODELS_2025_paper_85”, p. 1) #5fb236
	  
	  - “Several studies indicate that including UML in agile methods significantly enhances the consistency and comprehensibility of software designs, thus decreasing the uncertainty and misconceptions throughout the project life cycle.” (“MODELS_2025_paper_85”, p. 1) #5fb236
	  
	  - “In agile development, developers rely on user stories and succinct descriptions of software requirements to understand the system’s different functionalities.” (“MODELS_2025_paper_85”, p. 1) #5fb236
	  
	  - “User stories basically boost cross-team clarity by clearly identifying the target users and the significance of functions, often proposing a delivery timeline for delivery according to priority.” (“MODELS_2025_paper_85”, p. 1) #5fb236
	  
	  - “Nevertheless, it can pose new challenges if the user stories are not written properly or are misinterpreted due to their complexity and ambiguity, leading to increased workload, delays, and unmet user expectations [4].” (“MODELS_2025_paper_85”, p. 1) #5fb236
	  
	  - “As a <actor/user> I want <goal/action> so that <reason/value>.” (“MODELS_2025_paper_85”, p. 1) #5fb236
	  
	  - “time ,” (“MODELS_2025_paper_85”, p. 1) #ff6666
	  
	  - “In this context, we introduce our tool, Story2Spec, powered by Deepseek, which automatically extracts requirements following the FURPS model [14]. This model is particularly beneficial for handling user stories because of their informal and varied nature.” (“MODELS_2025_paper_85”, p. 1) #a28ae5
	  
	  - “Classifies user stories into requirements according to the FURPS model (functional, usability, performance, reliability, and supportability).” (“MODELS_2025_paper_85”, p. 2) #5fb236
	  
	  - “Generates use case diagrams based on the extracted software requirements following the UML syntax language.” (“MODELS_2025_paper_85”, p. 2) #5fb236
	  
	  - “Generate a complete description of the use cases based on a predefined template.” (“MODELS_2025_paper_85”, p. 2) #5fb236
	  
	  - “A within-subjects study involving 12 software engineering analysts was conducted to assess the efficiency and usability of the Story2Spec tool compared to the baseline ChatGPT.” (“MODELS_2025_paper_85”, p. 2) #5fb236
	  
	  - “[10] developed an NLP-based approach that integrates ontological modeling and Prolog rules to convert user stories into structured UML diagrams, including class, use case, and package diagrams.” (“MODELS_2025_paper_85”, p. 2) #5fb236
	  
	  - “However, the model may struggle with user stories that are ambiguous or poorly organized, which could necessitate additional refinement or even human intervention.” (“MODELS_2025_paper_85”, p. 2) #5fb236
	  
	  - “[15] utilized machine learning and NLP techniques to generate UML use case diagrams.” (“MODELS_2025_paper_85”, p. 2) #ffd400
	  *The subject of a sentence cannot be a bibliographic reference. This issue occurs many times in the related work section.*
	  
	  - “ChatGPT requires high computational resources and encounters difficulties in appropriately interpreting domainspecific terms without further customized training or modification.” (“MODELS_2025_paper_85”, p. 2) #5fb236
	  
	  - “. [17] presented a method based on Stanford CoreNLP to generate a sequence diagram and a collaborative diagram from natural language requirements” (“MODELS_2025_paper_85”, p. 2) #5fb236
	  
	  - “Despite the progress made in deriving UML from user stories, the critical step of extracting detailed requirements is often overlooked [8], [9], [20], despite its importance.” (“MODELS_2025_paper_85”, p. 3) #a28ae5
	  
	  - “This section describes the motivation example that drives our study as shown in 1” (“MODELS_2025_paper_85”, p. 3) #ff6666
	  *... shown in *Fig.* 1.*
	  
	  - “rdadmap project” (“MODELS_2025_paper_85”, p. 3) #ffd400
	  *What is it about? Can you introduce it?*
	  
	  - “analysts and experts usually extract these artifacts manually, which poses some challenges.” (“MODELS_2025_paper_85”, p. 3) #5fb236
	  
	  - “Such manual work could be susceptible to human error, like overlooking some vital information or miscategorizing the requirements since these can differ from one analyst to another.” (“MODELS_2025_paper_85”, p. 3) #5fb236
	  
	  - “Shifting toward automation can resolve the issues encountered with the manual approach.” (“MODELS_2025_paper_85”, p. 3) #5fb236
	  
	  - “Story2Spec, which acts as a supportive solution for developers and analysts.” (“MODELS_2025_paper_85”, p. 3) #ffd400
	  *Why developers directly? The tool is supposed to extract requirements, right? Requirements are not taken as input directly from developers.*
	  
	  - “Furthermore, our tool offers scalability over time since it can used for different projects of any size.” (“MODELS_2025_paper_85”, p. 3) #ff6666
	  *Many grammatical errors.*
	  
	  - “1) Requirements classification, which aims to categorize requirements into functional, usability, performance, reliability, supportability, and others according to the FURPS model;” (“MODELS_2025_paper_85”, p. 3) #2ea8e5
	  
	  - “2) Use case diagram generation: in this step, the deep seekbased model generates a UML use case diagram based on the input requirements;” (“MODELS_2025_paper_85”, p. 3) #2ea8e5
	  
	  - “3) Use cases description Generation: each use case identified in the diagram will be systematically expanded into a comprehensive textual description including preconditions, postconditions, and flow of activities.” (“MODELS_2025_paper_85”, p. 3) #2ea8e5
	  
	  - “Deriving requirements from user stories is an essential phase in the software development lifecycle, guaranteeing that user needs are comprehensively understood and converted into executable activities” (“MODELS_2025_paper_85”, p. 3) #5fb236
	  
	  - “as shown in 2” (“MODELS_2025_paper_85”, p. 3) #ff6666
	  *as shown in Fig. 2*
	  
	  - “shown in 3(I” (“MODELS_2025_paper_85”, p. 3) #ff6666
	  
	  - “Fig. 2. User Requirement Classification Interface (Interface A)” (“MODELS_2025_paper_85”, p. 4) #ffd400
	  *It's not needed to consume page space to include a figure showing a file upload form.*
	  
	  - “B. Use case diagram generation” (“MODELS_2025_paper_85”, p. 4) #ffd400
	  *The generation processes need to be properly presented. For instance, it is not clear the links from the use cases given in Fig. 4 and the classified user stories given in Fig.2 . A clear mapping description needs to be given. Also the need for the user stories classification has to be clearly motivated.*
	  
	  - “V. EVALUATION” (“MODELS_2025_paper_85”, p. 5) #ffd400
	  *I suggest adding a dedicated subsections to present the metrics that have been used for the evaluation (i.e., precision, recall, F1-score, etc)*
	  
	  - “To validate our work, we conducted a within-subjects study with 12 software engineering experts.” (“MODELS_2025_paper_85”, p. 5) #5fb236
	  
	  - “as shown in I .” (“MODELS_2025_paper_85”, p. 5) #ff6666
	  *as shown in Table I*
	  
	  - “We analyzed 10 projects that included 877 user stories.” (“MODELS_2025_paper_85”, p. 5) #ffd400
	  *How are these projects selected.*
	  
	  - “Each expert was requested to evaluate the generated use case diagram based on the following evaluation question by rating them on a 5-point Likert scale (1 = Not at all, 2 = Slightly, 3 = Moderately, 4 = Mostly, 5 = Completely).” (“MODELS_2025_paper_85”, p. 5) #ffd400
	  *In my opinion, in the whole evaluation process also artifacts produced by humans and mixed with the automated ones need to be considered.  As it is the evaluation permits to evaluate the correctness of the considered artifacts, but not the completeness. The generation step from user stories can neglect some use stories making the generated use cases uncomplete.  This is why it is necessary to include also manually created use cases.*
	  
	  - “by answering the following questions” (“MODELS_2025_paper_85”, p. 5) #ffd400
	  *Add an explici reference to Table III that includes the questions that need to be answered.*
	  
	  - “To answer this question, the participants answer the questionnaire, which contains five questions ranging from (QE14 to QE18) by rating using the following scale: 1 = Strongly Disagree, 2 = Disagree, 3 = Neutral, 4 = Agree, 5 = Strongly Agree.” (“MODELS_2025_paper_85”, p. 6) #ffd400
	  *Add a reference to Table IV.*
	  
	  - “We evaluated six projects (P1-P6), with two projects assessed by each of the 12 experts. Each evaluation includes responses to seven questions (QE1–QE7). We calculate the mean (M) and standard deviation (SD) for the six projects for each evaluation question.” (“MODELS_2025_paper_85”, p. 6) #5fb236
	  
	  - “VII .” (“MODELS_2025_paper_85”, p. 6) #ff6666
	  *Table VII.*
	  
	  - “We studied the efficiency of our story2spec tool compared to ChatGPT’s performance as shown in VII . It identifies actors and uses cases (QE1, QE2) for specific projects like projects 1 and 3. Some standard deviation values are high, which indicates that some generated diagrams might be incomplete or difficult to interpret. Additionally, ChatGPT faces some difficulties in providing the include/extend relationships between use cases due to a lack of deep knowledge about UML structure.” (“MODELS_2025_paper_85”, p. 6) #ffd400
	  *It is not clear if experts were aware or not of the language models that generated the artifacts under analysis. In other words, the experts were aware that were evaluating the use cases generated by ChatGPT or Story2Spec? This can be a potential bias. It is important to keep this aspect hidden.*
	  
	  - “in VIII.” (“MODELS_2025_paper_85”, p. 7) #ff6666
	  *in Table VIII*
	  
	  - “in IX” (“MODELS_2025_paper_85”, p. 7) #ff6666
	  *in Table IX*
	  
	  - “chatGPT” (“MODELS_2025_paper_85”, p. 7) #ff6666
	  *ChatGPT. Please check carefully the paper to fix errors like this one.*
	  
	  - “In this section, the 12 participants evaluate the usage of our tool story2spec and the baseline ChatGPT in terms of time, ease of use, and workload reduction, as shown in X. Each participant rates the evaluation questions on a 5-point Likert scale.” (“MODELS_2025_paper_85”, p. 7) #ff6666
	  *Typo and rephrase.*
	  
	  - “This study introduces Story2Spec, a DeepSeek-based tool for helping analysts transform natural language user stories into structured UML diagram modeling. It initially classifies user stories into requirements according to the FURPS model (functional, usability, performance, reliability, and supportability). Next, it produces use case diagrams following the UML syntax and generates case descriptions based on predefined. To evaluate the performance of our tool, we conducted a withinsubjects study involving 12 software engineering experts with varying levels of experience. We compared our results with the baseline ChatGPT. The findings indicate that the Story2Spec tool is able to create clear and consistent use case diagrams and use case descriptions that comply with UML standards. Furthermore, the story2spec tool proves to be efficient in saving time and reducing the workload of the analysts. In future work, we aim to explore other UML diagrams, such as the class and sequence diagrams.” (“MODELS_2025_paper_85”, p. 8) #5fb236
	  
	  Consider that those that are tagged with #5fb236 are just highlights, those that are tagged with #e56eee and #a28ae5 are important sentences. Please pay attention instead to the notes that are tagged with #ffd400. Those that are tagged with #ff6666 are typos or errors. Could you please draft a review by organizing it as follows: SUMMARY: Just a few sentences to summarize the work. COMMENTS: Organize the notes, especially those that contain issues or typos. Moreover, list the strengths and weaknesses of the work (no more than 3 items each). At the end, list 3 questions for the authors that might be involved in a rebuttal phase.