41 lines
3.4 KiB
Markdown
41 lines
3.4 KiB
Markdown
type:: [[REVIEWS]]
|
|
tags::
|
|
year:: 2025
|
|
venue:: [[MODELS]]
|
|
full-title:: Story2Spec: A DeepSeek-Powered Tool for Requirement Extraction and Use Case Modeling from User Stories
|
|
date-start:: [[22-05-2025]] - 16:26
|
|
date-submitted::
|
|
external-links::
|
|
status:: [[DONE]]
|
|
deadline-submission::
|
|
file:: [[@MODELS_2025_paper_85]]
|
|
parent::
|
|
todoist:: https://app.todoist.com/app/task/story2-spec-a-deep-seek-powered-tool-for-requirement-extraction-and-use-case-mod-6Xh6hh3H7Q58hcWg
|
|
|
|
- ### [[Highlights]]
|
|
- ### [[Comments]]
|
|
- Summary of the paper: The paper presents Story2Spec, a DeepSeek-based tool to automate the extraction of software requirements from user stories and transform them into use case descriptions. In particular, the tool starts with the classification of requirements using the FURPS model, generates use case diagrams, and produces textual use case descriptions. An evaluation involving 12 experts was conducted to assess the accuracy of Story2Spec and to compare it with ChatGPT in terms of performance and usability.
|
|
- Strengths:
|
|
- Relevant and interesting topic
|
|
- A structured workflow has been followed
|
|
- Weaknesses:
|
|
- Several issues reducing readability of the work
|
|
- Potential evaluation bias: It is unclear how the evaluated artifacts were generated, whether the evaluators knew the tool used, and how project selection was performed.
|
|
- Detailed comments:
|
|
- The paper is interesting for the venue even though it has several issues related to the presentation and the performed evaluation compromising the quality of the work. In particular:
|
|
- The tool is said to support developers, but since it works on user stories, it should primarily support analysts. Please clarify the target user of the proposed approach.
|
|
- A detailed explanation of how stories map to elements in use case diagrams (e.g., Fig. 4) is missing.
|
|
- Why is user story classification using FURPS essential for use case generation? A clearer justification is needed.
|
|
- Concerning the evaluation:
|
|
- Project selection criteria for the analyzed projects are not discussed.
|
|
- It is unclear whether human-generated artifacts were included in the comparison.
|
|
- There is a potential evaluation bias if participants knew which tool generated each artifact. This must be clarified and ideally avoided.
|
|
- I suggest adding a dedicated section to explain the metrics (e.g., precision, recall) used in the evaluation.
|
|
- References to tables containing obtained results (e.g., Table III, IV) should be explicitly included in the text.
|
|
- Avoid using figures (e.g., a file upload interface) that do not add technical value or insight to the discussion.
|
|
- Many references to figures and tables are incorrect or inconsistent (e.g., “as shown in I”, “in IX”), and several grammatical errors and typos are present throughout the text. A thorough proofread is essential.
|
|
- The rdadmap project is not properly introduced or contextualized. Please explain its relevance in the proposed approach.
|
|
- Questions for the authors
|
|
- Q1: How are the classified user stories mapped to specific use cases in the generated UML diagrams? Can you provide a detailed example or mapping rule?
|
|
- Q2: Were the evaluators aware of the origin (ChatGPT vs. Story2Spec) of the artifacts they assessed? If yes, how do you control for bias?
|
|
- Q3: How are the projects and user stories selected for evaluation? Were they drawn from a particular domain? |