Pith. sign in

REVIEW 4 major objections 4 minor 3 cited by

iReDev: A Knowledge-Driven Multi-Agent Framework for Intelligent Requirements Development

T0 review · 4 major / 4 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 This paper claims that injecting human expert knowledge into six role-playing agents, coordinated through an event-driven artifact pool and human-in-the-loop checkpoints, produces higher-quality user requirements lists, use-case models…

desk verdict A well-built framework with an evaluation whose ground truth was written by the framework's author—worth reviewing, but the outperformance claim needs better evidence. read the letter →

arxiv 2507.13081 v1 pith:7HVJU5RJ submitted 2025-07-17 cs.SE

Dongming Jin , Weisong Sun , Jiangping Huang , Peng Liang , Jifeng Xuan , Yang Liu , Zhi Jin This is my paper
classification cs.SE
keywords requirementsdevelopmentmulti-agentsystemslargelanguagemodelschain-of-thoughtpromptingevent-drivenartifactpoolhuman-in-the-loopsoftwarespecificationusecasemodeling
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 tries to establish that the requirements development phase—elicitation, analysis, specification, and validation—can be automated by a multi-agent framework called iReDev without losing the quality a human requirements engineer would provide. Six specialized agents (interviewer, end-user, deployer, analyst, archivist, reviewer) each carry injected expert knowledge, communicate indirectly through a shared artifact pool, and pause at key checkpoints for human feedback. On ten small-to-medium systems, iReDev reports higher diversity scores for user requirements lists, higher F1, BLEU, and BertScore for use-case models, and higher BLEU, BertScore, and G-Eval scores for software requirements specifications than zero-shot prompting, MetaGPT, and Elicitron. If the claim holds, it matters because requirements development is the current bottleneck in automated software production, and this framework offers a concrete architecture for removing it.

What carries the argument

The load-bearing mechanism is the knowledge-driven agent combined with the event-driven artifact pool. A knowledge-driven agent is an LLM-based role whose prompts include explicit expert knowledge—domain terminology, elicitation and modeling methodologies, standards such as ISO/IEC/IEEE 29148 and IEEE 830, artifact templates, and reasoning strategies like 5W1H and MoSCoW—so that the model follows an internal chain of thought before deciding or acting. The artifact pool is a blackboard-style shared workspace in which each artifact carries content, role, state, sender, and receiver properties; an addition or update broadcasts a meta-event that activates the monitors of relevant agents, which then choose their next action. This replaces linear dialogue or waterfall handoffs with loosely coupled event-driven coordination, enabling parallel work, incremental updates, rollback, and quick responses to new requirements. The human-in-the-loop checkpoints attach to the same pool, letting stakeholders inject corrections that downstream agents observe.

What would settle it

Have several requirements engineers who have never seen iReDev independently construct the reference user requirements lists, use-case models, and SRS for the same ten systems, then rerun the evaluation; if iReDev's average F1 on use-case models and G-Eval scores fall to baseline levels against this independent ground truth, the central claim is refuted. A quick diagnostic is to check whether the manually built reference SRS shares template language with iReDev's IEEE 830-style output, which would inflate BLEU and BertScore artificially.

Watch

Extended reading notes

Core claim

The central discovery, stated on the paper's own terms, is that a knowledge-driven multi-agent architecture can unify all four activities of requirements development and beat previously proposed approaches on every artifact type evaluated. Each of the six agents is built from modules for profile, monitor, thinking, memory, action, and knowledge, with expert knowledge drawn from professional books, project cases, and experts and injected as chain-of-thought reasoning so the model thinks through a task before acting. Agents do not hold free-form dialogues with one another; they publish artifacts to a shared pool, and any write or update emits an event that triggers whichever agents monitor that artifact. Human stakeholders review the user requirements list, the requirements model, and the SRS, and their feedback is written back into the pool, forming a machine-generation, human-adjudication, machine-correction loop. Across the ten evaluated systems, the paper reports average CHV 0.47 and MDC 0.62 for user requirements lists, average F1 0.389 for use-case models, and average BLEU 0.120, BertScore 0.616, and G-Eval scores of 4.2 (completeness), 4.0 (correctness), and 4.1 (cohesiveness) for the SRS.

Load-bearing premise

The evaluation's ground truth—the reference user requirements lists, use-case models, and software requirements specifications for the ten systems—was manually constructed by the first author, who also designed the framework, and only one external requirements engineering practitioner double-reviewed it; if those references are shaped by the framework's expected outputs, the reported quality advantages would not survive comparison against independent references.

Editorial extensions

If this is right

  • Requirements development can be separated from code generation and given its own automated pipeline: a rough idea like 'I need a bookkeeping assistant website' can be expanded into a prioritized user requirements list, use-case models, and a structured SRS.
  • Event-driven communication over shared artifacts avoids the cascading hallucination problem of chained dialogue agents, because an agent only sees the artifact it monitors rather than the full conversational history.
  • Simulated stakeholders with injected domain and role knowledge can stand in for real interviews during elicitation, producing requirement lists that are more diverse and evenly distributed than single-prompt generation.
  • Human-in-the-loop checkpoints at three artifacts mean the framework can run autonomously when no feedback is given, yet still incorporate expert and client corrections when stakeholders are available.
  • Because the same framework produces intermediate artifacts with traceability, such as interview records, environment lists, and system requirements lists, the final SRS can be audited back to original stakeholder statements.

Reading between the lines

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

  • The same six-agent-plus-artifact-pool shape could be transferred to other document-heavy engineering tasks, such as test planning, architecture documentation, or regulatory compliance, wherever artifacts are revised incrementally rather than written in one pass.
  • If the measured gains come mainly from the injected knowledge rather than the multi-agent coordination, a lighter version with one LLM following the same knowledge-guided chain of thought might capture part of the benefit at lower cost; the paper does not separate these two factors.
  • The strongest reported margin is on use-case model F1, which suggests the most decisive test of the framework is model extraction rather than text generation; future work could stress this with larger or safety-critical systems.
  • Automating the knowledge extraction step, which the paper lists as its first future direction, would turn the framework from a hand-curated prototype into a self-improving system, and would be the natural next experiment to run.
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

4 major / 4 minor

Summary. The paper proposes iReDev, a knowledge-driven multi-agent framework for requirements development, consisting of six agents (interviewer, end-user, deployer, analyst, archivist, and reviewer) coordinated through a shared artifact pool with event-driven communication and a human-in-the-loop mechanism. The authors evaluate iReDev on ten software systems against zero-shot GPT-4, MetaGPT, and Elicitron, using CHV/MDC for user requirements lists, F1/BLEU/BertScore for use-case diagrams, and BLEU/BertScore/G-Eval for SRS documents. They report that iReDev consistently outperforms the baselines across all three artifact types and conclude that the framework demonstrates the feasibility of knowledge-driven multi-agent requirements development. The ground-truth references for RQ2 and RQ3 were manually constructed by the first author and double-reviewed by one external practitioner, as stated in Sections 5.2 and 7.2.

Significance. If the empirical claims hold under independent evaluation, iReDev would be a meaningful contribution to automated requirements engineering: the framework design is clearly specified, the knowledge map in Table 1 is broad and grounded in established standards, and the artifact-pool communication mechanism is a plausible alternative to dialogue chaining. The paper is also transparent about its limitations and provides generated artifacts via a public link, which supports reproducibility. The main issue is that the core empirical claim is currently conditional: RQ2 and RQ3 are measured against references written by the framework's designer, and all scores are single-run point estimates. These concerns can be addressed, but until then the significance is not fully established.

major comments (4)
  1. [5.2/7.2] Section 5.2 states that 'the first author manually constructs these corresponding artifacts for each software system' because no reference artifacts exist, and Section 7.2 concedes that these annotations 'are somewhat subjective' with the only mitigation being a single external practitioner's double-review. Since RQ2's F1/BLEU/BertScore and RQ3's BLEU/BertScore/G-Eval are all computed against these author-built references, the reported gains (e.g., Table 4 F1 0.389 vs. 0.109; Table 5 BLEU 0.120 vs. 0.080) are not protected against confirmation bias: the reference may encode exactly the elements iReDev was prompted to produce. One external reviewer does not constitute an independently constructed gold standard. The authors should either obtain references built independently (e.g., by multiple practitioners blind to the framework), add a human evaluation of the artifacts conducted without the author-built references, or substantially weaken the RQ2/RQ3 claims.
  2. [5.5/6] Section 5.5 reports a single configuration (temperature 0.3, top-p 1.0) and no repeated runs, and Tables 3-5 present point estimates without variance or significance tests. The 'consistent robustness' analysis in RQ1 and the categorical conclusion in Section 8 are therefore stronger than the data support. The authors should run multiple seeds or LLM invocations and report distributions or a statistical comparison (e.g., a paired test across systems) before claiming consistent outperformance.
  3. [5.3/7.2] RQ1 uses CHV and MDC, which are embedding-diversity measures; they do not measure whether the requirements are correct, relevant, or aligned with stakeholder value. The paper itself acknowledges in Section 7.2 that 'high diversity does not guarantee that truly relevant needs are captured,' so the RQ1 analysis and the conclusion's reference to 'quality of user requirement lists' overstate what this metric can show. Either add a correctness-oriented evaluation for the user requirements lists or reframe the RQ1 conclusion as a diversity result.
  4. [4.4/7.1] Section 4.4 introduces the human-in-the-loop mechanism as a core contribution, and Section 8 describes iReDev as a framework 'with human-in-the-loop support,' but Section 7.1 states that 'we report fully automated collaboration to establish the baseline.' No experiment varies HITL on/off or measures its effect, so the contribution's effectiveness is unsupported by the evaluation. An ablation comparing automated-only with HITL-enabled runs, or a clear statement that HITL is not evaluated, is needed.
minor comments (4)
  1. [Throughout] There are typographical errors that should be corrected, including 'Knowldge-driven' in Section 4.1, 'BLUE' in the RQ2/RQ3 setups, 'experimetnal' in Section 6, and 'reality projects' in the Table 2 caption.
  2. [Figure 3] Figure 3 gives the standard as 'ISO/IEC/IEEE 29418', while the text and Table 1 refer to 'ISO/IEC/IEEE 29148'; this inconsistency should be fixed.
  3. [5.3] The G-Eval protocol is underspecified; the paper should report the judge prompt, model, and decoding settings, since G-Eval results are known to be sensitive to these choices.
  4. [7.1] The case study uses a different system (an insurance management system) from the ten evaluation systems in Table 2; please clarify whether it is intended as an additional qualitative demonstration and how it relates to RQ1-RQ3.

Circularity Check

1 steps flagged · score 3.0 of 10

RQ2/RQ3 evaluation uses gold artifacts hand-written by the framework's first author, so the reported F1/BLEU/BertScore/G-Eval gains partly measure alignment with the designer's own expectations rather than an independent standard.

  1. other [Section 5.2 (Evaluated Systems); Section 5.3 (Metrics); RQ2/RQ3 analyses in Section 6; acknowledged in Section 7.2]
    "To obtain ground truth for simple evaluation, the first author manually constructs these corresponding artifacts for each software system. ... This indicates that iReDev is more accurate in identifying and generating correct use case elements, such as actors and use cases, when compared to the ground truth."

    RQ2's F1 and RQ3's BLEU/BertScore/G-Eval scores are overlap/completeness measures against the Section 5.2 reference artifacts. Those references were hand-written by the same first author who designed iReDev's knowledge-driven prompts. The reported advantage (e.g., average F1 0.389 vs. 0.109 over MetaGPT) therefore measures how well iReDev reproduces the author's own expectations of actors, use cases, and SRS content, and it is not protected against confirmation bias. The external practitioner double-review in Section 7.2 only checks the author-created artifacts; it does not independently reconstruct the gold standard. This is not an equation-level equivalence, but it makes the central RQ2/RQ3 comparisons partially self-referential.

full rationale

There is no mathematical derivation in the paper whose inputs equal its outputs, and the self-citations (e.g., MARE) are used as related-work context rather than load-bearing justification. The main concern is evaluation dependency: Section 5.2 states that no reference user requirements lists, requirements models, or SRSs exist for the ten systems, so the first author manually constructs them; Section 5.3 then defines requirements-model F1/BLEU/BertScore and SRS BLEU/BertScore/G-Eval Completeness against those same artifacts. Since the first author also designed iReDev and its knowledge prompts, the gold standard embodies that author's expectations, making the RQ2 and RQ3 comparisons partially self-referential. Section 7.2 explicitly acknowledges that the annotations 'are somewhat subjective' and that only one external practitioner double-reviewed them; this mitigates but does not remove the dependency, because the external review does not provide an independently constructed gold standard. RQ1's CHV/MDC metrics are reference-free and less affected. Because the issue is a load-bearing evaluation confound rather than a derivation-level circularity, a score of 3 is appropriate.

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

No fitted numerical parameters appear in the paper; the central design component is the handcrafted knowledge and prompt content. The axioms are domain assumptions about the validity of the authored ground truth, the meaningfulness of the chosen metrics, the correctness of the extracted knowledge, and the representativeness of a single run. No new physical or conceptual entities are postulated; the six agents are software components of the proposed system, not explanatory entities introduced to cover a gap.

free parameters (1)
  • Handcrafted knowledge and prompt content for six agents
    Manually extracted from books, projects, and experts (Sections 3.2, 4.2); the specific wording of each agent's system prompt is a designed component that the experimental outcome depends on, analogous to a fitted parameter. No numerical parameters are fit to data; temperature=0.3 and top_p=1.0 are standard stability settings (Section 5.5).
assumptions (4)
  • domain assumption The first author's manually constructed reference artifacts (URL, use-case model, SRS) for the ten systems are valid ground truth.
    Evaluation in Sections 5.3-6 compares iReDev outputs against these references; an external practitioner double-reviewed them (Section 5.2) but did not independently produce them.
  • domain assumption Diversity metrics CHV and MDC operationalize user-requirements quality.
    Used in RQ1 (Section 5.3); the paper itself notes in Section 7.2 that high diversity does not guarantee truly relevant needs are captured.
  • domain assumption The manually extracted knowledge from authoritative literature, projects, and experts is accurate and beneficial.
    Central to the knowledge-driven agent design (Section 3.2); if this knowledge is wrong or irrelevant, the reported advantage over baselines would be unsupported.
  • domain assumption A single evaluation run per system with GPT-4-turbo at temperature 0.3 is representative of framework performance.
    No repeated runs or statistical tests are reported (Section 5.5); the conclusions rest on point estimates.

how reviews work

0 comments
Cite this review

Pith. "Pith review of iReDev: A Knowledge-Driven Multi-Agent Framework for Intelligent Requirements Development." pith.science (2026). https://pith.science/paper/7HVJU5RJ

@misc{pith2026250713081,
  author       = {Pith},
  title        = {Pith review of: iReDev: A Knowledge-Driven Multi-Agent Framework for Intelligent Requirements Development},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/7HVJU5RJ}},
  note         = {Machine review of arXiv:2507.13081}
}
read the original abstract

Requirements development is a critical phase as it is responsible for providing a clear understanding of what stakeholders need. It involves collaboration among stakeholders to extract explicit requirements and address potential conflicts, which is time-consuming and labor-intensive. Recently, multi-agent systems for software development have attracted much attention. However, existing research provides limited support for requirements development and overlooks the injection of human knowledge into agents and the human-agent collaboration. % To address these issues, this paper proposes a knowledge-driven multi-agent framework for intelligent requirement development, named iReDev. iReDev features: iReDev consists of six knowledge-driven agents to support the entire requirements development. They collaboratively perform various tasks to produce a software requirements specification. iReDev focuses on integrating human knowledge for agents, enabling them to simulate real-world stakeholders. iReDev uses an event-driven communication mechanism based on an artifact pool. Agents continuously monitor the pool and autonomously trigger the next action based on its changes, enabling iReDev to handle new requirements quickly. iReDev introduces a human-in-the-loop mechanism to support human-agent collaboration, ensuring that the generated artifacts align with the expectations of stakeholders. We evaluated the generated artifacts and results show that iReDev outperforms existing baselines in multiple aspects. We further envision three key directions and hope this work can facilitate the development of intelligent requirements development.

Figures

Figures reproduced from arXiv: 2507.13081 by the authors.

Figure 1
Figure 1. Overview of Knowledge-Driven Agent apply proven methodologies and adhere to industry standards when performing requirements development tasks. Knowledge from Existing Requirements Projects. Extracting knowledge from existing requirements projects begins by gathering a comprehensive dataset of open-source or publicly available requirements development projects. They can provide insights about common devel￾opment patt… view at source ↗
Figure 2
Figure 2. An overview of the knowledge-driven multi-agent framework for intelligent requirement development. [PITH_FULL_IMAGE:figures/full_fig_p011_2.png] view at source ↗
Figure 3
Figure 3. Profile Prompt of the Interviewer agent shape how goals and constraints are articulated. The pain-point layer stores recurrent frustrations (e.g., slow response times), enabling the agent to inject concrete cases. The quality-expectation layer enumerates non-functional concerns, e.g., performance and data privacy requirements. (4) Predefined Actions. ❶ Respond: provides goals, pain points, illustrative scenarios, an… view at source ↗
Figures from the paper (1 more)
Figure 4
Figure 4. Figure 4: The artifacts generated by iReDev on the insurance management system. Results [PITH_FULL_IMAGE:figures/full_fig_p019_4.png]

Discussion (0). Sign in to comment.

Forward citations

Cited by 3 Pith papers

Reviewed papers in the Pith corpus that reference this work. Sorted by Pith novelty score. Full citation record

  1. Semantic-Enhanced Automatic Refinement of Architecture Recovery Results Using LLMs

    cs.SE 2026-07 conditional novelty 6.0 of 10

    SemRef refines existing architecture-recovery outputs with LLMs and dependency analysis, reducing distance to ground truth by 17.72–43.35% RDP across five metrics on 90 recoveries.

  2. QUARE: Quality-Aware Requirements Analysis through Multi-Agent Dialectical Negotiation

    cs.SE 2026-03 conditional novelty 6.0 of 10

    Quality-specialized LLM agents that dialectically negotiate cross-quality conflicts produce more balanced, standards-compliant KAOS requirements than task- or knowledge-decomposed multi-agent RE baselines.

  3. UserTrace: User-Level Requirements Generation and Traceability Recovery from Software Project Repositories

    cs.SE 2025-09 conditional novelty 6.0 of 10

    UserTrace generates user-level requirements from code repositories and recovers live trace links from requirements to implementation, with evaluations suggesting gains over summarization and traceability baselines.

Reference graph

Works this paper leans on

58 extracted references · 46 canonical work pages · cited by 3 Pith papers

  1. [1]

    [n. d.]. The generated requirements artifacts in our case study. https://anonymous.4open.science/r/TOSEM-iReqDev

    work page

  2. [2]

    IEEE Guide for Software Requirements Specifications

    1984. IEEE Guide for Software Requirements Specifications. IEEE Std 830-1984 (1984), 1–26

    work page 1984

  3. [3]

    Zahra Shakeri Hossein Abad, Vincenzo Gervasi, Didar Zowghi, and Ken Barker. 2018. Elica: An automated tool for dynamic extraction of requirements relevant information. In 5th International Workshop on Artificial Intelligence for Requirements Engineering. IEEE, 8–14

    work page 2018

  4. [4]

    Chetan Arora, John Grundy, and Mohamed Abdelrazek. 2024. Advancing requirements engineering through generative ai: Assessing the role of llms. In Generative AI for Effective Software Development . 129–148

    work page 2024

  5. [5]

    Mohammadmehdi Ataei, Hyunmin Cheong, Daniele Grandi, Ye Wang, Nigel Morris, and Alexander Tessier. 2024. Elic- itron: An LLM agent-based simulation framework for design requirements elicitation. arXiv preprint arXiv:2404.16045 (2024)

    arXiv 2024

  6. [6]

    TA AWARE and TPS DOCUMENTATION. 1984. IEEE Guide for Software Requirements Specifications. (1984)

    work page 1984

  7. [7]

    Tom Brown, Benjamin Mann, Nick Ryder, Melanie Subbiah, Jared D Kaplan, Prafulla Dhariwal, Arvind Neelakantan, Pranav Shyam, Girish Sastry, Amanda Askell, et al. 2020. Language models are few-shot learners. Advances in neural information processing systems 33 (2020), 1877–1901

    2020

  8. [8]

    John M Carroll, Mary Beth Rosson, George Chin, and Jürgen Koenemann. 1998. Requirements development in scenario-based design. IEEE transactions on software engineering 24, 12 (1998), 1156–1170

    work page 1998

Show all 58 references
  1. [9]

    Marsha Chechik and John Gannon. 2001. Automatic analysis of consistency between requirements and designs. IEEE transactions on Software Engineering 27, 7 (2001), 651–672

    2001

  2. [10]

    Boqi Chen, Kua Chen, Shabnam Hassani, Yujing Yang, Daniel Amyot, Lysanne Lessard, Gunter Mussbacher, Mehrdad Sabetzadeh, and Dániel Varró. 2023. On the use of GPT-4 for creating goal models: an exploratory study. In 2023 IEEE 31st International Requirements Engineering Confere...

    2023

  3. [11]

    Kua Chen, Yujing Yang, Boqi Chen, José Antonio Hernández López, Gunter Mussbacher, and Dániel Varró. 2023. Automated domain modeling with large language models: A comparative study. In 2023 ACM/IEEE 26th International Conference on Model Driven Engineering Languages and System...

    2023

  4. [12]

    Betty HC Cheng and Joanne M Atlee. 2007. Research directions in requirements engineering. Future of software engineering (2007), 285–303

    2007

  5. [13]

    Alessandro Cimatti, Marco Roveri, Angelo Susi, and Stefano Tonetta. 2013. Validation of requirements for hybrid systems: A formal approach. ACM Transactions on Software Engineering and Methodology 21, 4 (2013), 1–34

    2013

  6. [14]

    Iain D Craig. 1988. Blackboard systems. Artificial Intelligence Review 2, 2 (1988), 103–118

    1988

  7. [15]

    Norman Daoust. 2012. UML Requirements Modeling For Business Analysts . Technics Publications, LLC

    2012

  8. [16]

    Nilesh Dhulshette, Sapan Shah, and Vinay Kulkarni. 2025. Hierarchical Repository-Level Code Summarization for Business Applications Using Local LLMs. arXiv preprint arXiv:2501.07857 (2025)

    2025 arXiv

  9. [17]

    Saad Ezzini, Sallam Abualhaija, Chetan Arora, and Mehrdad Sabetzadeh. 2022. Automated handling of anaphoric ambiguity in requirements: a multi-solution study. In Proceedings of the 44th international conference on software engineering. 187–199. ACM Trans. Softw. Eng. Methodol....

    2022

  10. [18]

    Alessandro Fantechi, Stefania Gnesi, Lucia Passaro, and Laura Semini. 2023. Inconsistency detection in natural language requirements using chatgpt: a preliminary evaluation. In 31st International Requirements Engineering Conference . IEEE, 335–340

    2023

  11. [19]

    Nick Feng, Lina Marsso, Sinem Getir Yaman, Isobel Standen, Yesugen Baatartogtokh, Reem Ayad, Victoria Oldemburgo De Mello, Beverley Townsend, Hanne Bartels, Ana Cavalcanti, et al. 2024. Normative requirements operationalization with large language models. In 2024 IEEE 32nd Int...

    2024

  12. [20]

    Alessio Ferrari, Sallam Abualhaijal, and Chetan Arora. 2024. Model generation with LLMs: From requirements to UML sequence diagrams. In 2024 IEEE 32nd International Requirements Engineering Conference Workshops (REW) . IEEE, 291–300

    2024

  13. [21]

    Donald Firesmith. 2005. Quality Requirements Checklist. J. Object Technol. 4, 9 (2005), 31–38

    2005

  14. [22]

    Eva Freund. 2012. IEEE Standard for System, Software, and Hardware Verification and Validation. Software quality professional 15, 1 (2012), 43

    2012

  15. [23]

    Binnur Görer and Fatma Başak Aydemir. 2023. Generating requirements elicitation interview scripts with large language models. In IEEE 31st International Requirements Engineering Conference Workshops . 44–51

    2023

  16. [24]

    Robert Kraig Helmeczi, Mucahit Cevik, and Savas Yıldırım. 2023. Few-shot learning for sentence pair classification and its applications in software engineering. arXiv preprint arXiv:2306.08058 (2023)

    2023 arXiv

  17. [25]

    Sirui Hong, Mingchen Zhuge, Jonathan Chen, Xiawu Zheng, Yuheng Cheng, Jinlin Wang, Ceyao Zhang, Zili Wang, Steven Ka Shing Yau, Zijuan Lin, Liyang Zhou, Chenyu Ran, Lingfeng Xiao, Chenglin Wu, and Jürgen Schmidhuber. 2024. MetaGPT: Meta Programming for A Multi-Agent Collaborat...

    2024

  18. [26]

    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 Transactions on Software Engineering and Methodology 33, 8 (2024), 1–79

    2024

  19. [27]

    Samantha I Infeld, David Goggin, Kevin Vipavetz, and Trevor Grondin. 2018. A SysML model template for NASA concurrent engineering studies. In 2018 AIAA Space and Astronautics Forum and Exposition . 5392

    2018

  20. [28]

    ISO ISO et al. 2018. Road vehicles–Functional safety–Part: Product development at the software level. International Organization for Standardization, Geneva, Switzerland,.(Cited on page.) (2018)

    2018

  21. [29]

    Michael Jackson and Pamela Zave. 1995. Deriving specifications from requirements: an example. In Proceedings of the 17th international conference on Software engineering . 15–24

    1995

  22. [30]

    Juyong Jiang, Fan Wang, Jiasi Shen, Sungju Kim, and Sunghun Kim. 2024. A survey on large language models for code generation. arXiv preprint arXiv:2406.00515 (2024)

    2024 arXiv

  23. [31]

    Dongming Jin, Zhi Jin, Xiaohong Chen, and Chunhui Wang. 2024. MARE: Multi-Agents Collaboration Framework for Requirements Engineering. arXiv preprint arXiv:2405.03256 (2024)

    2024 arXiv

  24. [32]

    Dongming Jin, Shengxin Zhao, Zhi Jin, Xiaohong Chen, Chunhui Wang, Zheng Fang, and Hongbin Xiao. 2024. An evaluation of requirements modeling for cyber-physical systems via llms. arXiv preprint arXiv:2408.02450 (2024)

    2024 arXiv

  25. [33]

    Stephen J Kapurch. 2010. NASA systems engineering handbook . Diane Publishing

    2010

  26. [34]

    Keren Kenzi, Pnina Soffer, and Irit Hadar. 2010. The role of domain knowledge in requirements elicitation: An exploratory study. (2010)

    2010

  27. [35]

    Javed Ali Khan, Shamaila Qayyum, and Hafsa Shareef Dar. 2025. Large Language Model for Requirements Engineering: A Systematic Literature Review. (2025)

    2025

  28. [36]

    Nek Dil Khan, Javed Ali Khan, Jianqiang Li, Tahir Ullah, and Qing Zhao. 2025. Leveraging Large Language Model ChatGPT for enhanced understanding of end-user emotions in social media feedbacks.Expert Systems with Applications 261 (2025), 125524

    2025

  29. [37]

    Iat Tou Leong and Raul Barbosa. 2023. Translating natural language requirements to formal specifications: a study on gpt and symbolic nlp. In 53rd Annual IEEE/IFIP International Conference on Dependable Systems and Networks Workshops. 259–262

    2023

  30. [38]

    Liunian Harold Li, Jack Hessel, Youngjae Yu, Xiang Ren, Kai-Wei Chang, and Yejin Choi. 2023. Symbolic chain-of- thought distillation: Small models can also" think" step-by-step. arXiv preprint arXiv:2306.14050 (2023)

    2023 arXiv

  31. [39]

    Soo Ling Lim and Anthony Finkelstein. 2011. StakeRare: using social networks and collaborative filtering for large-scale requirements elicitation. IEEE transactions on software engineering 38, 3 (2011), 707–735

    2011

  32. [40]

    Yang Liu, Dan Iter, Yichong Xu, Shuohang Wang, Ruochen Xu, and Chenguang Zhu. 2023. G-eval: NLG evaluation using gpt-4 with better human alignment. arXiv preprint arXiv:2303.16634 (2023)

    2023 arXiv

  33. [41]

    Sebastian Lubos, Alexander Felfernig, Thi Ngoc Trang Tran, Damian Garber, Merfat El Mansi, Seda Polat Erdeniz, and Viet-Man Le. 2024. Leveragingx llms for the quality assurance of software requirements. In IEEE 32nd International Requirements Engineering Conference (RE) . 389–397

    2024

  34. [42]

    Rainer Lutze and Klemens Waldhör. 2024. Generating specifications from requirements documents for smart devices using large language models (llms). In International Conference on Human-Computer Interaction . 94–108. ACM Trans. Softw. Eng. Methodol., Vol. 1, No. 1, Article . Pu...

    2024

  35. [43]

    Stephan Merz. 2008. The specification language TLA+. Logics of specification languages (2008), 401–451

    2008

  36. [44]

    Bashar Nuseibeh and Steve Easterbrook. 2000. Requirements engineering: a roadmap. In Proceedings of the Conference on the Future of Software Engineering . 35–46

    2000

  37. [45]

    Richard Paul and Linda Elder. 2019. The thinker’s guide to Socratic questioning . Rowman & Littlefield

    2019

  38. [46]

    Chen Qian, Wei Liu, Hongzhang Liu, Nuo Chen, Yufan Dang, Jiahao Li, Cheng Yang, Weize Chen, Yusheng Su, Xin Cong, et al. 2023. Chatdev: Communicative agents for software development. (2023)

    2023

  39. [47]

    Shuaicai Ren, Hiroyuki Nakagawa, and Tatsuhiro Tsuchiya. 2024. Combining prompts with examples to enhance llm- based requirement elicitation. In 2024 IEEE 48th Annual Computers, Software, and Applications Conference . 1376–1381

    2024

  40. [48]

    Douglas T Ross and Kenneth E Schoman. 1977. Structured analysis for requirements definition. IEEE transactions on Software Engineering 1 (1977), 6–15

    1977

  41. [49]

    Bernd Scholz-Reiter and Eberhard Stickel. 2012. Business process modelling. Springer Science & Business Media

    2012

  42. [50]

    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

  43. [51]

    Junjie Wang, Yuchao Huang, Chunyang Chen, Zhe Liu, Song Wang, and Qing Wang. 2024. Software testing with large language models: Survey, landscape, and vision. IEEE Transactions on Software Engineering (2024)

    2024

  44. [52]

    Bingyang Wei. 2024. Requirements are all you need: From requirements to code with llms. In2024 IEEE 32nd International Requirements Engineering Conference (RE) . IEEE, 416–422

    2024

  45. [53]

    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

  46. [54]

    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

  47. [55]

    Simiao Zhang, Jiaping Wang, Guoliang Dong, Jun Sun, Yueling Zhang, and Geguang Pu. 2024. Experimenting a new programming practice with llms. arXiv preprint arXiv:2401.01062 (2024)

    2024 arXiv

  48. [56]

    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. (2025)

    2025

  49. [57]

    Yiran Zhang, Ruiyin Li, Peng Liang, Weisong Sun, and Yang Liu. 2025. Knowledge-Based Multi-Agent Framework for Automated Software Architecture Design. In Proceedings of the 33rd ACM International Conference on the Foundations of Software Engineering-Ideas, Visions and Reflecti...

    2025

  50. [58]

    2023.Software Requirements Engineering: Methods and Practice

    Jin Zhi, Lin Liu, Xiaohong Chen, and Tong Li. 2023.Software Requirements Engineering: Methods and Practice . Tsinghua University Press. Received 20 February 2007; revised 12 March 2009; accepted 5 June 2009 ACM Trans. Softw. Eng. Methodol., Vol. 1, No. 1, Article . Publication...

    2023

Pith tools

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