When applying LLMs to the “What” of software development—the field of requirements engineering—it is essential to define exactly what is what: namely, how LLMs can be utilized across the various facets of requirements.
While there are numerous ways to categorize the requirements engineering process, two stages are particularly distinct: elicitation and specification. In the former, the goal is to engage with stakeholders to ensure needs are fully captured. The latter involves analyzing and processing that information into a rigorous specification that defines the system to be developed.
During the elicitation phase, it is common practice to identify requirements by analyzing similar or ‘analogous’ systems. LLMs are particularly valuable here, as they can suggest potential requirements based on their vast internal knowledge of existing software systems. While an LLM may not always provide groundbreaking innovation, it serves as a powerful tool to enrich the exploratory space, ensuring that standard features or edge cases from similar domains are not overlooked.
Regarding specifications, the impact of LLMs may be even more significant. Some suggest that, given a well-defined requirements specification, LLMs can function as automated code generators. However, several critical aspects must be considered to ensure this process is both reliable and maintainable.
The first challenge concerns the quality of the specification. Requirements engineering exists in the liminal space between natural language and the formal languages of implementation. Consequently, achieving a rigorous specification is essential. One established technique is the use of standardized templates; by providing these templates to an LLM, the model can help structure requirements more effectively. Furthermore, LLMs can be utilized to verify consistency. Even when following a template, requirements often remain rooted in natural language, leaving them prone to ambiguity. LLMs can bridge this gap by identifying contradictions or missing information across the specification.
Once a complete system specification is established, we arrive at the ‘Holy Grail’ of LLM software engineering: Can we ‘vibe code’ a system based solely on the requirements—the ‘What’? In other words, if the specification is sufficiently rigorous, can the LLM bridge the final gap and generate a fully functional implementation without human intervention in the codebase?
To fully grasp the problem this question aims to answer, we must clarify that a specification must address two distinct categories: functional and non-functional requirements. While it is increasingly argued that LLMs can generate code to implement specific functional requirements, that code must still operate within a robust system architecture. This architecture is what supports the non-functional requirements—often referred to as system qualities—such as scalability, security, and maintainability.
System qualities are the direct result of deliberate architectural decisions. These decisions serve as the bridge between desired qualities and the software architecture that supports them—representing the essential ‘Why’ of the system.
This raises a pivotal question: can an LLM generate this ‘Why,’ effectively bridging the gap between the ‘What’ (requirements) and the ‘How’ (implementation)?
Key articles on this subject include:
- Large Language Models (LLMs) for Requirements Engineering (RE): A Systematic Literature Review
- A design science research approach to Large Language Model-Based Agents for Requirements Specification (LLMBA4RS) in low-code applications
- Research directions for using LLM in software requirement engineering: a systematic review