Describe generative requirements

Figure 2: The BDD pyramid as a basis for efficient requirement-describing prompts.

© talsen team

When working with LLMs and creating good prompts, the following simple principle applies: the better the compilation of the input information and the more precise the request, the more useful the generated formulation result that we can expect. As already described for the generation of epics and user stories, "divide and conquer" also applies to the successful use of LLMs for requirements creation. This means breaking down the requirements into coherent content blocks that can also be clearly assigned in terms of their abstraction levels. In prompt engineering terms, the "Chain of Thoughts" technique is the leading prompt tactic. At talsen team, we use the levels of decomposition as described in behavior-driven software development (BDD) in our day-to-day business(Figure 2). It should be noted that the descriptions of the work description merge seamlessly with the descriptions of the specification. This reflects the fact that useful and valuable insights are often gained during the "making" process, from which concrete specifications can be derived. If there is a break in the system or the description logic, this is not only more difficult for product management. It also reduces the potential success of generative AI methods, as the input information for a good prompt is likely to be incomplete.

Figure 3: An example of suitable abstraction levels for the AI-supported, step-by-step, generative creation of requirements descriptions.

© talsen team

In the following, the value contributions in the dependency tree for the generative creation of specifying and work-describing artifacts along the different levels of abstraction are illustrated using a small example of a simple IIoT application(Figure 3). The subdivision into the different abstraction levels is a great help when using LLMs at the current state of the art. If the queries become too complex or cover too broad a range of content, the responses from ChatGPT and the like are generally generalized and therefore hardly useful in terms of a precise formulation of requirements.

>> Read part 2 of the article series "ChatGPT in the industry"!

The final stage and the source for the decisive details in the specification work are the feature files, which also come from the world of behavior-driven software development. They represent the last level before concrete implementation in tests and productive code. An example of such a feature file - written in the specification language Gherkin as part of a small IIoT example - could be formulated as follows:

• FEATURE: Connect digital temperature sensor via OPC-UA
• SCENARION: Initialization of a temperature sensor
• GIVEN: a functional, installed and commissioned temperature sensor with the ID "123"
• AND the IIoT system is deactivated
• IF the IIoT system is activated
• THEN the temperature sensor is initialized via OPC-UA with the given parameters
• AND the temperature sensor continuously transmits measured values according to the set parameter values.

Figure 4: The prompt workflow for the automated creation of request artifacts.

© talsen team

This result could, for example, be generated automatically from the chain of the previously created, higher abstraction levels of the artifacts. If, as shown in Figure 4, code from the existing code base is integrated into the prompt context, it is also possible to create the test code in parallel with the behavioral description of the feature file. The developer should not be afraid of long prompts: A prompt enriched with all important content may well contain several hundred lines of text.

>> Read part 3 of the article series "ChatGPT in the industry"!

The choice of Gherkin as a proven specification language in behavior-driven software development is not arbitrary. Due to its formalized description structure, Gherkin is very close to the actual process structures in the code. This means that the level of abstraction to executable code and the associated automated test is very low. Prompts that contain Gherkin as input and context are therefore not only extremely precise and yet easy to understand requirement descriptions, but also excellent starting points for generative software creation with LLMs.

Prompt Engineering for good formulations

Using the pyramid of agile specification artefacts described in Figure 2 as the backbone for efficient prompts, it is possible to implement the "divide and conquer" principle well. This means that the prompt can always be optimally supplemented with the relevant context without overloading the request with too much information. However, it should be borne in mind that the generation of requirement descriptions still has a relatively high level of complexity for generative AI, even with well-graduated levels of abstraction. In addition to the prompt strategies and tactics already mentioned in the previous articles, it is therefore worth taking a closer look at the following four special prompt techniques for complex requests. These all deal with a step-by-step decomposition and step-by-step enrichment of the solution and thus fit perfectly with the described decomposition approach for specification artifacts.

• Few-shot: Few-shot refers to a method in which one or more examples are provided in the prompt context in order to prepare or adapt the LLM for a specific task. These examples are used to give the model a concrete understanding of the task. This technique is often used to quickly adapt models to specific scenarios. For example, the use of document templates, as shown here, is a concrete example of the Few-Shot technique.
• Chain of Thought: The Chain of Thought technique uses an LLM to first develop an explicit, step-by-step solution to complex problems before deriving the final answer. On the one hand, this helps to track the "thought processes" of the model. On the other hand, it is suitable for improving the accuracy of difficult tasks. This technique is highly recommended for solving problems that require logical thinking or mathematical calculations.
• Tree of Thought: Tree of Thought is an extension of the Chain of Thought technique in that different possible thought paths are examined by the model in a tree-like structure. This gives the LLM the opportunity to explore several possible solutions at the same time. Finally, the model evaluates the respective plausibility and selects the best solution from the variants developed. This method improves decision-making in complex or ambiguous situations in particular, as it enables a more in-depth analysis of the options.
• Step-back: The step-back technique is also used in complex solution processes and means that the LLM does not immediately give the answer to the question but first tries to recognize and explain the underlying general principle of the task or problem. The actual question is then answered using this self-created content foundation. This makes it possible to achieve good and well-founded solutions even for difficult questions.

The good requirements description

The author: Dr. Hans Egermeier is Managing Director of talsen team.

© talsen team

Whether the requirements description process is carried out using BDD methods and artifacts or not is, in principle, easily interchangeable. The prompts can be easily adapted to the prevailing methodology, processes and document types in the individual company environment. The key to efficient and high-quality generative creation of requirements descriptions is the quality and granularity of the context as input and the complexity of the questions or the leap between the levels of abstraction in the requirements description process. With regard to the current state of LLM intelligence, both can be covered very well with BDD methods and description forms in combination with the aforementioned prompt techniques and should definitely be worth considering for the next "generated" project.

>> Read part 4 of the article series "ChatGPT in the industry"!