Pith. sign in

REVIEW 5 major objections 5 minor 53 references

Think Like an Engineer: A Neuro-Symbolic Collaboration Agent for Generative Software Requirements Elicitation and Self-Review

T0 review · 5 major / 5 minor · reviewed 2026-08-06 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

Pith's one-line read Causal-effect graphs turn vague app requests into testable requirements.

desk verdict A real method with a self-referential evaluation: RequireCEG is worth engaging, but the headline numbers should not be trusted yet. read the letter →

arxiv 2507.14969 v1 pith:VVIG4BQD submitted 2025-07-20 cs.SE

Sai Zhang , Zhenchang Xing , Jieshan Chen , Dehai Zhao , Zizhong Zhu , Xiaowang Zhang , Zhiyong Feng , Xiaohong Li This is my paper · ORCID
classification cs.SE
keywords requirementelicitationcausal-effectgraphGherkinneuro-symboliccollaborationfeaturetreeend-usersoftwareengineeringLLMagentsreview
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

The paper's claim is that LLM-generated software requirements fall short because nothing in the generation loop forces causal logic between preconditions and behavior actions. RequireCEG is proposed as a remedy: a neuro-symbolic agent that turns a user's vague narrative into a feature tree, derives causal-effect graphs that link atomic conditions to system responses, repairs those graphs through formal and semantic self-checks, and then uses the healed graphs to review and augment Gherkin scenarios. The paper argues that this loop makes the final requirements more complete, more diverse, and more consistent than what current Gherkin-generation methods produce, citing a 51.88% improvement in functional diversity and an 87% coverage of real functions on five public websites. If these results hold, end users could produce testable acceptance criteria from a single narrative paragraph without a requirements analyst in the loop.

What carries the argument

The load-bearing object is the causal-effect graph (CEG), a symbolic graph whose nodes are atomic preconditions (causes) and behavior actions (effects), linked by Boolean operators (DIR, AND, OR, NOT) and constrained among same-type nodes by EXC, INC, REQ, XOR, and MSK. It carries the argument by acting as a formal oracle the LLM cannot talk its way around: the graph is constructed from the elicited system behaviors, repaired until it passes a format check and an intervention-question semantic check, and then used to review and extend the draft Gherkin scenarios. Supporting that machinery are the feature tree, which scopes software components hierarchically and is the main source of functional diversity, and the generate-check-modify loop that makes the CEG self-healing.

What would settle it

Take a fixed set of applications, collect narratives written directly by non-technical users without any Gherkin knowledge, run RequireCEG on them, and have requirement-engineering experts who are blind to the source rank the outputs against professionally authored Gherkin for business consistency and completeness; if the expert-authored requirements match or beat the generated ones, or if the diversity and consistency scores drop sharply on these genuine narratives, the central claim of practical superiority is refuted.

Watch

Extended reading notes

Core claim

RequireCEG establishes that the missing ingredient in current LLM-based requirement elicitation is explicit causal reasoning about what must hold before a behavior is allowed to happen. Given only a natural-language narrative, the agent first elicits a feature tree to scope software components and describes each behavior from both the user-operation and system-response perspectives. It then decomposes those behaviors into atomic conditions (causes) and effects, builds a causal-effect graph using Boolean operators such as DIR, AND, OR, and NOT together with constraints like EXC, INC, REQ, XOR, and MSK, and runs a self-healing loop: a formal syntax check on the graph expressions, followed by a semantic check in which each condition is set false and the LLM must reason about whether the requirement still justifies the effect. The healed graph is then used to review the draft Gherkin, repairing logical mismatches between Given-When-Then clauses and adding scenarios that cover missing causal branches. The paper reports that this architecture outperforms six baseline methods on requirement quality, functional-diversity entropy, and internal and business consistency, and that in a human field study on five live websites, 87% of the generated features corresponded to real functions on the sites.

Load-bearing premise

The evaluation depends on treating large-language-model summaries of existing Gherkin files as if they were real end-user narratives, and on trusting an automated LLM judge's numeric ratings of quality, diversity, and consistency.

Editorial extensions

If this is right

  • A non-technical user's single narrative paragraph can be converted, end to end and without human intervention, into a multi-feature set of executable Gherkin acceptance criteria.
  • Because the CEG records every precondition-action link, a failed test in the subsequently generated application can be traced back to a specific requirement node, making AI-generated software auditable.
  • The self-healing check means the symbolic graph, not just the LLM, is what guarantees consistency, so the approach can be pushed to larger, multi-component applications.
  • The feature-tree elicitation stage is what carries the diversity gains; removing it cuts functional diversity by more than 61%, so scoping and satisfaction modeling are not optional extras.
  • The reviewed Gherkin scenarios are ready for Behavior-Driven Development tooling, closing the loop between end-user requirements and Cucumber-style executable specifications.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • Because the narratives in RGPair were generated from Feature files rather than collected from users, a natural next experiment is to re-run the pipeline on verbatim user requests from app reviews or support tickets and measure whether the diversity and consistency gains persist on genuinely noisy input.
  • The same precondition-action discipline could transfer to other artifacts: API contract validation, UI acceptance criteria, or automated test-case generation, since enforcing causal consistency is a generic problem, not specific to Gherkin.
  • The reported 51.88% diversity gain could be more sharply attributed by applying per-category significance tests across the five FURPS classes, rather than relying on the aggregate entropy score alone.
  • A cheaper ablation than changing the whole pipeline would be to swap the base LLM for an open-weight model in the same agent chaining; if the gains persist, the CEG architecture rather than a particular model is the source of the improvement.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

5 major / 5 minor

Summary. This paper proposes RequireCEG, a neuro-symbolic agent that uses feature trees and causal-effect graphs (CEGs) to elicit software requirements from natural language narratives and generate reviewed Gherkin scenarios. The central claim is that RequireCEG improves requirement quality (INVEST), functional diversity (FURPS entropy), and consistency over six baselines, supported by a new RGPair benchmark (40 GitHub projects, 413 Feature files), an ablation study, and a field study on five public websites reporting 87% coverage. The paper is clearly written and makes available code and data.

Significance. The neuro-symbolic combination of LLM reasoning with symbolic CEG review is a timely and plausible design; the feature-tree elicitation is a sensible mechanism to expand functional scope. The RGPair benchmark, if properly validated, would be a useful resource for the EUSE community. The paper's empirical claims, however, are currently grounded in a closed-loop evaluation: inputs are synthetic summaries of target Feature files (Section 4.2.1), all main metrics are LLM-as-a-judge (Section 5.2.2), and the human field study covers only five low-complexity websites with three participants. These threats need to be addressed before the quantitative claims can be accepted.

major comments (5)
  1. [Section 4.2.1] The RGPair narratives are generated by prompting ChatGPT to “Summarize the feature content as a user narrative based on the Gherkin Features” from the very Feature files that serve as ground truth. The evaluation never compares the generated Gherkin against the original Feature files, so the task is reconstruction of a known artifact rather than elicitation from an authentic stakeholder. The central claim of improving elicitation from genuine end-user narratives is therefore not supported. Please add an evaluation on authentic user narratives (Mini-RG has only 12 instances, Section 4.2.2) or, at minimum, a direct functional-overlap comparison between generated Gherkin and the original Feature files to demonstrate that the synthetic narratives preserve the target information.
  2. [Section 5.2.2] The INVEST scores, Fundiv classification, and consistency scores are all produced by LLM-as-a-judge using GPT-4.1-mini, with no human agreement or validation statistics reported for these metrics. Since RequireCEG itself is built on GPT-4o-mini (Section 4.3), the same model family as the judge, self-preference and output-format artifacts can inflate the reported improvements. Please provide a human-annotated evaluation on a random subset of the generated requirements (e.g., 20–30 projects) with inter-rater agreement, or use a judge from a different model family, to demonstrate that the metric scores are not artifacts of the evaluation setup.
  3. [Section 5.2.3, Table 7] The Fundiv entropy metric is not corrected for the number of features or for the intentional spread across FURPS categories induced by the feature tree. RequireCEG outputs F@Num=16.925 while the second-best method has F@Num=4.25, and Section 3.2 explicitly designs features across satisfaction categories. The reported 51.88% diversity gain is therefore partly a structural consequence of generating more features in more categories, not a measure of intrinsic requirement quality. Please report diversity at matched feature counts or a normalized entropy (e.g., per-feature or per-category) to support the diversity claim.
  4. [Section 6 and Abstract] The abstract's “87% coverage rate” refers to Cover@Our (proportion of generated features that match some real website function), while Table 10 shows the average Cover@Real_Func is about 70% (the proportion of actual website functions covered). The abstract and the Field Study Findings should state both metrics explicitly; as written, “coverage rate” is misleadingly presented as completeness relative to real functions. Please clarify this distinction in the abstract and the discussion.
  5. [Section 6.1.3] The human evaluation uses only five low-complexity AI-related websites and three graduate students, with no statistical significance tests reported. While Cohen's kappa > 0.82 is reported, the small scale and the homogeneity of participants limit the generalizability of the field-study claims, which are nevertheless used in the abstract's headline number. A larger or more diverse participant pool, or at least a clear statement of this limitation in the abstract, would be needed to support the current strength of the claim.
minor comments (5)
  1. [Table 8] The column header “F@Sec” should be “F@Sce” for consistency with the notation used earlier in Section 5.1.2.
  2. [Section 6.1.2] The equation for Cover@Real_Func is incomplete: “Total number of pub-website (4)” should presumably read “Total number of pub-website functions.”
  3. [Section 4.3] The “Gherkin Example prompt template” applied to baselines is mentioned but not described; if it is identical to the template used in RequireCEG's Draft Gherkin Generator, please state this and include the prompt in an appendix to support the fairness of the comparisons.
  4. [Section 7] The Discussion repeats “About 87% of the generated features align with real website functions” without noting that this is Cover@Our and that Cover@Real_Func is about 70%; please add the clarification in the same paragraph.
  5. [Table 5] The MetaGPT(PRD) row reports no Acc@Syn value (“/”); please specify why or provide the value, since all other baselines report this metric.

Circularity Check

1 steps flagged · score 4.0 of 10

Headline gains rest on a self-defined benchmark: RGPair narratives are ChatGPT summaries of the target Gherkin Feature files, so the evaluation measures reconstruction from a lossy summary rather than elicitation from independent user narratives.

  1. self definitional [Section 4.2.1 (Dataset Construction) and Section 5.1.2.c (RQ Experimental Setup)]
    "To overcome this limitation, we employed ChatGPT to generate a concise project-level summary narrative based on the content of Feature files. ... Summarize the feature content as a user narrative based on the 'Gherkin Features' ... In the RGPair dataset, we use the value with the key 'narrative' as input."

    RGPair's input narratives are generated by summarizing the very Gherkin Feature files that constitute the target output. The paper claims to derive Gherkin requirements from user narratives, but in RGPair the 'user narrative' is definitionally a compressed version of the target Gherkin. Evaluation on RGPair therefore measures how well RequireCEG and the baselines reconstruct the original Feature files from their own summaries, not how well they elicit requirements from independent end users. The headline quality and diversity improvements are computed on this self-referential benchmark, so the RGPair-based gains are partly forced by the dataset construction rather than by genuine narrative-to-Gherkin transformation.

full rationale

The method's internal pipeline (feature tree -> CEG construction -> CEG-based Gherkin review) is not equation-level circular: no parameters are fitted to the test outputs, and the ablation studies isolate the contribution of each module. The main circularity is in the evaluation loop. RGPair narratives are produced by prompting ChatGPT to summarize the Gherkin Feature files used as target artifacts, and the reported quality, diversity, and consistency scores come from LLM judges (GPT-4.1-mini for INVEST and consistency, a few-shot LLM for FURPS classification) rather than from independent ground-truth matching. This makes the abstract's 87% coverage and 51.88% diversity gain partly self-referential: the input is derived from the output, and the judges share the same model family as the generator (GPT-4o-mini). Some independent evidence exists: Mini-RG uses authentic paired narratives from an external fine-tuning dataset, and the field study uses three human evaluators with Cohen's kappa > 0.82. However, the field study's Cover@Real_Func averages about 70%, below the abstract's Cover@Our of 87%, which tempers the headline claim. No load-bearing self-citation or imported uniqueness theorem was found; the AgileGen [53] citation is used as a baseline and motivation, not as the justification for RequireCEG's validity.

Assumptions & free parameters 0 free parameters · 4 assumptions · 0 invented entities

The central claim depends on several domain assumptions about LLM reliability and benchmark validity; no new ontological entities are introduced. The self-healing CEG and feature-tree pipeline are processes built from existing representations such as Gherkin, CEG, and feature trees.

assumptions (4)
  • domain assumption LLM-based ReasoningIQ provides reliable binary answers about whether the system behavior requirement logically derives intervention questions.
    The whole self-healing semantic check (Section 3.3.3) assumes the LLM can correctly judge its own generated CEG expressions.
  • domain assumption GPT-4.1-mini as a judge produces valid scores for INVEST, functional diversity, and consistency.
    Sections 5.2.2 and 5.2.3 use this automated judge without human validation or correlation analysis.
  • ad hoc to paper RGPair narratives generated by ChatGPT from Feature files are representative of real end-user requirement descriptions.
    Section 4.2.1 constructs the benchmark in this reverse manner, which may bias the task toward LLM-style inputs.
  • domain assumption Pub-website dataset selections are representative and low-complexity websites yield meaningful coverage rates.
    Section 6.1.1 explicitly selects low-complexity AI websites, which may inflate the reported coverage.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Think Like an Engineer: A Neuro-Symbolic Collaboration Agent for Generative Software Requirements Elicitation and Self-Review." pith.science (2026). https://pith.science/paper/VVIG4BQD

@misc{pith2026250714969,
  author       = {Pith},
  title        = {Pith review of: Think Like an Engineer: A Neuro-Symbolic Collaboration Agent for Generative Software Requirements Elicitation and Self-Review},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/VVIG4BQD}},
  note         = {Machine review of arXiv:2507.14969}
}
read the original abstract

The vision of End-User Software Engineering (EUSE) is to empower non-professional users with full control over the software development lifecycle. It aims to enable users to drive generative software development using only natural language requirements. However, since end-users often lack knowledge of software engineering, their requirement descriptions are frequently ambiguous, raising significant challenges to generative software development. Although existing approaches utilize structured languages like Gherkin to clarify user narratives, they still struggle to express the causal logic between preconditions and behavior actions. This paper introduces RequireCEG, a requirement elicitation and self-review agent that embeds causal-effect graphs (CEGs) in a neuro-symbolic collaboration architecture. RequireCEG first uses a feature tree to analyze user narratives hierarchically, clearly defining the scope of software components and their system behavior requirements. Next, it constructs the self-healing CEGs based on the elicited requirements, capturing the causal relationships between atomic preconditions and behavioral actions. Finally, the constructed CEGs are used to review and optimize Gherkin scenarios, ensuring consistency between the generated Gherkin requirements and the system behavior requirements elicited from user narratives. To evaluate our method, we created the RGPair benchmark dataset and conducted extensive experiments. It achieves an 87% coverage rate and raises diversity by 51.88%.

Figures

Figures reproduced from arXiv: 2507.14969 by the authors.

Figure 1
Figure 1. Using the "Time Travel Adventure" requirement as an example, the problem-statement diagram shows that the Gherkin [PITH_FULL_IMAGE:figures/full_fig_p002_1.png] view at source ↗
Figure 2
Figure 2. Using the Time Travel Adventure application as a case study, we demonstrate how unclear requirements impact downstream [PITH_FULL_IMAGE:figures/full_fig_p005_2.png] view at source ↗
Figure 3
Figure 3. Challenges in Applying BDD (Behavior-Driven Development) & Human aspects on the performance of individuals in [PITH_FULL_IMAGE:figures/full_fig_p007_3.png] view at source ↗
Figures from the paper (14 more)
Figure 4
Figure 4. Figure 4: Illustration of Logical relationship Operators and Constraint Symbols in Causal-Effect Graphs. [PITH_FULL_IMAGE:figures/full_fig_p009_4.png]
Figure 5
Figure 5. Figure 5: Feature Tree Grouping and Example for "Time Travel Adventure App" [PITH_FULL_IMAGE:figures/full_fig_p011_5.png]
Figure 6
Figure 6. Figure 6: RequireCEG Overview Diagram. This is a Causal-Effect Graphs (CEGs)-driven multi-agent framework that takes a user [PITH_FULL_IMAGE:figures/full_fig_p012_6.png]
Figure 7
Figure 7. Figure 7: Gherkin keyword Statistics Across Methods. The vertical axis uses a logarithmic scale, and the horizontal axis represents [PITH_FULL_IMAGE:figures/full_fig_p022_7.png]
Figure 8
Figure 8. Figure 8: Stacked bar chart and radar chart showing the detailed ratings of different methods across the INVEST principle. [PITH_FULL_IMAGE:figures/full_fig_p025_8.png]
Figure 9
Figure 9. Figure 9: Comparison of the number of features across different methods by category. The horizontal axis represents functional categories [PITH_FULL_IMAGE:figures/full_fig_p025_9.png]
Figure 10
Figure 10. Figure 10: Comparison of rating distributions across different state-of-the-art (SOTA) methods on consistency metrics. [PITH_FULL_IMAGE:figures/full_fig_p026_10.png]
Figure 11
Figure 11. Figure 11: Gherkin keyword Statistics Generated by Ablation Methods. The vertical axis uses a logarithmic scale, and the horizontal [PITH_FULL_IMAGE:figures/full_fig_p028_11.png]
Figure 12
Figure 12. Figure 12: Stacked Bar Chart of INVEST Ratings for Ablation Methods. [PITH_FULL_IMAGE:figures/full_fig_p029_12.png]
Figure 13
Figure 13. Figure 13: Comparison of Feature Counts by FURPS Categories for Ablation Methods. [PITH_FULL_IMAGE:figures/full_fig_p029_13.png]
Figure 14
Figure 14. Figure 14: Comparison of Rating Distributions on Consistency Metrics for Ablation Methods. [PITH_FULL_IMAGE:figures/full_fig_p029_14.png]
Figure 15
Figure 15. Figure 15: Visualization of the outputs at different stages of the RequireCEG method using the "microservices-patterns/ftgo-application" [PITH_FULL_IMAGE:figures/full_fig_p030_15.png]
Figure 16
Figure 16. Figure 16: Illustrative examples of using the Causal-Effect Graph (CEG) to review and correct three common types of missing elements [PITH_FULL_IMAGE:figures/full_fig_p031_16.png]
Figure 17
Figure 17. Figure 17: A detailed visualization of the human evaluation is shown for the projects "Lyrebird Health" and "STORM." Green indicates [PITH_FULL_IMAGE:figures/full_fig_p034_17.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

53 extracted references · 35 canonical work pages

  1. [1]

    Josh Achiam, Steven Adler, Sandhini Agarwal, Lama Ahmad, Ilge Akkaya, Florencia Leoni Aleman, Diogo Almeida, Janko Altenschmidt, Sam Altman, Shyamal Anadkat, et al. 2023. Gpt-4 technical report. arXiv preprint arXiv:2303.08774 (2023)

    arXiv 2023

  2. [2]

    Gilbert Adu. 2024. Artificial Intelligence in Software Testing: Test scenario and case generation with an AI model (gpt-3.5-turbo) using Prompt engineering, Fine-tuning and Retrieval augmented generation techniques . Master’s thesis. Itä-Suomen yliopisto

    work page 2024

  3. [3]

    Emily Judith Arteaga Garcia, João Felipe Nicolaci Pimentel, Zixuan Feng, Marco Gerosa, Igor Steinmacher, and Anita Sarma. 2024. How to Support ML End-User Programmers through a Conversational Agent. InProceedings of the IEEE/ACM 46th International Conference on Software Engineering(Lisbon, Portugal) (ICSE ’24). Association for Computing Machinery, New Yor...

    arXiv 2024

  4. [4]

    Barbara Rita Barricelli, Fabio Cassano, Daniela Fogli, and Antonio Piccinno. 2019. End-user development, end-user programming and end-user software engineering: A systematic mapping study. Journal of Systems and Software 149 (2019), 101–137

    work page 2019

  5. [5]

    Beatty and A

    J. Beatty and A. Chen. 2012. Visual Models for Software Requirements . Microsoft Press. https://books.google.com.au/books?id=9hdaiCMmMiQC

    work page 2012

  6. [6]

    Severin Bergsmann, Alexander Schmidt, Stefan Fischer, and Rudolf Ramler. 2024. First Experiments on Automated Execution of Gherkin Test Specifications with Collaborating LLM Agents. In Proceedings of the 15th ACM International Workshop on Automating Test Case Design, Selection and Evaluation. 12–15

    work page 2024

  7. [7]

    Margaret Burnett, Curtis Cook, and Gregg Rothermel. 2004. End-user software engineering. Commun. ACM 47, 9 (2004), 53–58

    work page 2004

  8. [8]

    Margaret M Burnett and Brad A Myers. 2014. Future of end-user software engineering: beyond the silos. InFuture of Software Engineering Proceedings. 201–211

    work page 2014

Show all 53 references
  1. [9]

    Adwait Chandorkar, Nitish Patkar, Andrea Di Sorbo, and Oscar Nierstrasz. 2022. An exploratory study on the usage of gherkin features in open-source projects. In 2022 IEEE International Conference on Software Analysis, Evolution and Reengineering (SANER) . IEEE, 1159–1166

    2022

  2. [10]

    Stefan van den Eijkel. 2024. Exploring the INVEST Model in Agile Software Development: An In-Depth Analysis . Master’s thesis

    2024

  3. [11]

    Derar Eleyan, Abed Othman, and Amna Eleyan. 2020. Enhancing software comments readability using flesch reading ease score. Information 11, 9 (2020), 430

    2020

  4. [12]

    William R Elmendorf. 1970. Automated design of program test libraries. IBM Technial Report TR 00.2089 (1970)

    1970

  5. [13]

    Muhammad Shoaib Farooq, Uzma Omer, Amna Ramzan, Mansoor Ahmad Rasheed, and Zabihullah Atal. 2023. Behavior driven development: A systematic literature review. IEEE Access (2023)

    2023

  6. [14]

    Jiawei Gu, Xuhui Jiang, Zhichao Shi, Hexiang Tan, Xuehao Zhai, Chengjin Xu, Wei Li, Yinghan Shen, Shengjie Ma, Honghao Liu, et al. 2024. A survey on llm-as-a-judge. arXiv preprint arXiv:2411.15594 (2024)

    2024 arXiv

  7. [15]

    Sirui Hong, Xiawu Zheng, Jonathan Chen, Yuheng Cheng, Jinlin Wang, Ceyao Zhang, Zili Wang, Steven Ka Shing Yau, Zijuan Lin, Liyang Zhou, et al. 2023. Metagpt: Meta programming for multi-agent collaborative framework. arXiv preprint arXiv:2308.00352 (2023)

    2023 arXiv

  8. [16]

    Kseniia Horina and Karatanov Oleksandr. 2023. Advantages of Automated Testing of Medical Applications and Information Systems Using Gherkin and Behavior-Driven Development. In Conference on Integrated Computer Technologies in Mechanical Engineering–Synergetic Engineering . Spr...

    2023

  9. [17]

    Xinyi Hou, Yanjie Zhao, Yue Liu, Zhou Yang, Kailong Wang, Li Li, Xiapu Luo, David Lo, John Grundy, and Haoyu Wang. 2024. Large Language Models for Software Engineering: A Systematic Literature Review. ACM Trans. Softw. Eng. Methodol. 33, 8, Article 220 (Dec. 2024), 79 pages. h...

    2024 doi

  10. [18]

    Woo Sung Jang and R Young Chul Kim. 2022. Automatic cause–effect graph tool with informal Korean requirement specifications. Applied Sciences 12, 18 (2022), 9310

    2022

  11. [19]

    Haoxiang Jia, Robbie Morris, He Ye, Federica Sarro, and Sergey Mechtaev. 2025. Automated Repair of Ambiguous Natural Language Requirements. arXiv preprint arXiv:2505.07270 (2025)

    2025

  12. [20]

    Karl Wiegers Joy Beatty. [n. d.]. Using Feature Trees to Depict Scope . https://www.modernanalyst.com/Resources/Articles/tabid/115/ID/6061/Using- Feature-Trees-to-Depict-Scope.aspx (2022)

    2022

  13. [21]

    Noriaki Kano, Nobuhiku Seraku, Fumio Takahashi, and Shinichi Tsuji. 1984. Attractive quality and must-be quality. (1984)

    1984

  14. [22]

    Shanthi Karpurapu, Sravanthy Myneni, Unnati Nettur, Likhit Sagar Gajja, Dave Burke, Tom Stiehm, and Jeffery Payne. 2024. Comprehensive Evaluation and Insights into the Use of Large Language Models in the Automation of Behavior-Driven Development Acceptance Test Formulation. IE...

    2024

  15. [23]

    Amy J Ko, Robin Abraham, Laura Beckwith, Alan Blackwell, Margaret Burnett, Martin Erwig, Chris Scaffidi, Joseph Lawrance, Henry Lieberman, Brad Myers, et al. 2011. The state of the art in end-user software engineering. ACM Computing Surveys (CSUR) 43, 3 (2011), 1–44

    2011

  16. [24]

    Madhava Krishna, Bhagesh Gaur, Arsh Verma, and Pankaj Jalote. 2024. Using LLMs in software requirements specifications: an empirical evaluation. In 2024 IEEE 32nd International Requirements Engineering Conference (RE) . IEEE, 475–483

    2024

  17. [25]

    Ehlimana Krupalija, Emir Cogo, Šeila Bećirović, Irfan Prazina, and Ingmar Bešić. 2022. Cause-effect Graphing Technique: A Survey of Available Approaches and Algorithms. In 2022 IEEE/ACIS 23rd International Conference on Software Engineering, Artificial Intelligence, Networking...

    2022

  18. [26]

    Ehlimana Krupalija, Emir Cogo, Šeila Bećirović, Irfan Prazina, Damir Pozderac, and Ingmar Bešić. 2023. CEGSet: Collection of standardized cause-effect graph specifications. In2023 12th Mediterranean Conference on Embedded Computing (MECO). 1–4. https://doi.org/10.1109/MECO5858...

    2023

  19. [27]

    Ehlimana Krupalija, Emir Cogo, Damir Pozderac, Aya Ali Al Zayat, and Ingmar Bešić. 2023. Usage of machine learning methods for cause-effect graph feasibility prediction. In Machine Learning and Artificial Intelligence . IOS Press, 126–131

    2023

  20. [28]

    Ehlimana Krupalija, Emir Cogo, Damir Pozderac, Samir Omanović, Almir Karabegović, Razija Turčinhodžić Mulahasanović, and Ingmar Bešić. 2024. ETF-RI-CEG-Advanced: A graphical desktop tool for black-box testing by using cause–effect graphs. SoftwareX 25 (2024), 101625

    2024

  21. [29]

    Phillip A Laplante and Mohamad Kassab. 2022. Requirements engineering for software and systems . Auerbach Publications. https://doi.org/10.1201/ 9781003129509

    2022

  22. [30]

    Qianou Ma, Weirui Peng, Chenyang Yang, Hua Shen, Kenneth Koedinger, and Tongshuang Wu. 2025. What Should We Engineer in Prompts? Training Humans in Requirement-Driven LLM Use. ACM Trans. Comput.-Hum. Interact. (April 2025). https://doi.org/10.1145/3731756 Just Accepted

    2025 doi

  23. [31]

    Nuno Marques, Rodrigo Rocha Silva, and Jorge Bernardino. 2024. Using ChatGPT in Software Requirements Engineering: A Comprehensive Review. Future Internet 16, 6 (2024), 180

    2024

  24. [32]

    Fangwen Mu, Lin Shi, Song Wang, Zhuohao Yu, Binquan Zhang, ChenXue Wang, Shichao Liu, and Qing Wang. 2024. ClarifyGPT: A Framework for Enhancing LLM-Based Code Generation via Requirements Clarification. Proc. ACM Softw. Eng. 1, FSE, Article 103 (July 2024), 23 pages. https://d...

    2024 doi

  25. [33]

    Bonnie A Nardi. 1993. A small matter of programming: perspectives on end user computing . MIT press

    1993

  26. [34]

    Minh Huynh Nguyen, Thang Phan Chau, Phong X Nguyen, and Nghi DQ Bui. 2024. AgileCoder: Dynamic Collaborative Agents for Software Development based on Agile Methodology. arXiv preprint arXiv:2406.11912 (2024)

    2024 arXiv

  27. [35]

    Linda Northrop, Peter Feiler, Richard P Gabriel, John Goodenough, Rick Linger, Tom Longstaff, Rick Kazman, Mark Klein, Douglas Schmidt, Kevin Sullivan, et al. 2006. Ultra-large-scale systems: The software challenge of the future. (2006)

    2006

  28. [36]

    Saeed Parsa. 2023. Acceptance testing and behavior driven development (BDD). In Software Testing Automation: Testability Evaluation, Refactoring, Test Data Generation and Fault Localization . Springer, 79–158

    2023

  29. [37]

    Safriya Murni Puspita, Alvina Waihda Ardhani, Dea Ayu Retnaningrum, Afreza Restu Firmansyah, and Dwi Rolliawati. 2024. ANALYSIS OF SOFTWARE QUALITY USING THE FURPS+ MODEL. JURTEKSI (Jurnal Teknologi dan Sistem Informasi) 11, 1 (2024), 131–138

    2024

  30. [38]

    Chen Qian, Yufan Dang, Jiahao Li, Wei Liu, Zihao Xie, Yifei Wang, Weize Chen, Cheng Yang, Xin Cong, Xiaoyin Che, et al. 2023. Experiential co-learning of software-developing agents. arXiv preprint arXiv:2312.17025 (2023)

    2023 arXiv

  31. [39]

    Chen Qian, Wei Liu, Hongzhang Liu, Nuo Chen, Yufan Dang, Jiahao Li, Cheng Yang, Weize Chen, Yusheng Su, Xin Cong, et al. 2024. Chatdev: Communicative agents for software development. In Proceedings of the 62nd Annual Meeting of the Association for Computational Linguistics (Vo...

    2024

  32. [40]

    Chen Qian, Wei Liu, Hongzhang Liu, Nuo Chen, Yufan Dang, Jiahao Li, Cheng Yang, Weize Chen, Yusheng Su, Xin Cong, Juyuan Xu, Dahai Li, Zhiyuan Liu, and Maosong Sun. 2024. ChatDev: Communicative Agents for Software Development. In Proceedings of the 62nd Annual Meeting of the A...

    2024 doi

  33. [41]

    Chen Qian, Zihao Xie, Yifei Wang, Wei Liu, Yufan Dang, Zhuoyun Du, Weize Chen, Cheng Yang, Zhiyuan Liu, and Maosong Sun. 2024. Scaling large-language-model-based multi-agent collaboration. arXiv preprint arXiv:2406.07155 (2024)

    2024 arXiv

  34. [42]

    Gordon, Neil D

    Diana Robinson, Christian Cabrera, Andrew D. Gordon, Neil D. Lawrence, and Lars Mennen. 2024. Requirements are All You Need: The Final Frontier for End-User Software Engineering. ACM Trans. Softw. Eng. Methodol. (Dec. 2024). https://doi.org/10.1145/3708524 Just Accepted

    2024 doi

  35. [43]

    SHEXMO SANTOS, Michel dos Santos Soares, and Fabio Gomes Rocha. [n. d.]. Perception of Professionals Regarding the Adoption of Behavior-Driven Development (Bdd): A Descriptive and Statistical Study Through a Survey. A vailable at SSRN 4933832 ([n. d.])

  36. [44]

    Claude E Shannon. 1948. A mathematical theory of communication. The Bell system technical journal 27, 3 (1948), 379–423

    1948

  37. [45]

    Axel Van Lamsweerde. 2000. Requirements engineering in the year 00: A research perspective. In Proceedings of the 22nd international conference on Software engineering. 5–19

    2000

  38. [46]

    Andreas Vogelsang, Alexander Korn, Giovanna Broccia, Alessio Ferrari, Jannik Fischbach, and Chetan Arora. 2025. On the Impact of Requirements Smells in Prompts: The Case of Automated Traceability. arXiv preprint arXiv:2501.04810 (2025)

    2025 arXiv

  39. [47]

    Jason Wei, Xuezhi Wang, Dale Schuurmans, Maarten Bosma, Fei Xia, Ed Chi, Quoc V Le, Denny Zhou, et al. 2022. Chain-of-thought prompting elicits reasoning in large language models. Advances in neural information processing systems 35 (2022), 24824–24837

    2022

  40. [48]

    Jules White, Sam Hays, Quchen Fu, Jesse Spencer-Smith, and Douglas C Schmidt. 2024. Chatgpt prompt patterns for improving code quality, refactoring, requirements elicitation, and software design. In Generative AI for Effective Software Development . Springer, 71–108

    2024

  41. [49]

    Karl E Wiegers and Joy Beatty. 2013. Software requirements. Pearson Education

    2013

  42. [50]

    Jie JW Wu, Manav Chaudhary, Davit Abrahamyan, Arhaan Khaku, Anjiang Wei, and Fatemeh H Fard. 2025. ClarifyCoder: Clarification-Aware Fine-Tuning for Programmatic Problem Solving. arXiv preprint arXiv:2504.16331 (2025)

    2025

  43. [51]

    Qingyun Wu, Gagan Bansal, Jieyu Zhang, Yiran Wu, Beibin Li, Erkang Zhu, Li Jiang, Xiaoyun Zhang, Shaokun Zhang, Jiale Liu, et al. 2023. Autogen: Enabling next-gen llm applications via multi-agent conversation. arXiv preprint arXiv:2308.08155 (2023)

    2023 arXiv

  44. [52]

    Zhenchang Xing, Yang Liu, Zhuo Cheng, Qing Huang, Dehai Zhao, Daniel SUN, and Chenhua Liu. 2025. When Prompt Engineering Meets Software Engineering: CNL-P as Natural and Robust" APIs”for Human-AI Interaction. In The Thirteenth International Conference on Learning Representations

    2025

  45. [53]

    Sai Zhang, Zhenchang Xing, Ronghui Guo, Fangzhou Xu, Lei Chen, Zhaoyuan Zhang, Xiaowang Zhang, Zhiyong Feng, and Zhiqiang Zhuang. 2025. Empowering Agile-Based Generative Software Development through Human-AI Teamwork. ACM Trans. Softw. Eng. Methodol. 34, 6, Article 156 (July 2...

    2025 doi

Pith tools

Reviewed August 6, 2026 · model on record in the stance chip above.