Bachelor and Master Theses

Background and motivation

A software system is described by requirements which are statements of what it must do and how well it must do it. Examples are "A drone shall return home when its battery is below 20%" and "The system shall respond to an operator command within two seconds". A real system has hundreds of them, and they depend on each other.

Systems change constantly, and a change usually starts as a sentence or two. Take this request: "Drones should land immediately when the battery is low." It sounds clear. But the system also requires that a drone carrying a package lands only in an approved zone, and that every drone scans the ground before landing. Should a drone with a package now land anywhere? Should it skip the scan? The request does not say, and each answer changes a different existing requirement.

AI coding tools now act on such requests directly. When a request is unclear, the tool picks one meaning which might not be the intended one and the mistake shows up later in the code. The remedy is to ask first. But a tool that asks about everything wastes people's time, and one that asks about nothing gets it wrong. What matters is asking the few questions whose answers change what happens to the system.

Goal

Build and evaluate a method that reads a change request together with a system's existing requirements, finds the points where the meaning of the request changes which requirements are affected, asks the requester a few targeted questions, and returns the clarified request with the list of affected requirements.

Methodology

The work has main five parts.

1. Study the field. Review recent research on how the effects of a change are found and how AI tools ask for clarification. Position your contribution.
2. Find the data. Identify and obtain suitable public requirement sets and assess what each one offers. Pick the most suitable one(s).
3. Design and build the method. It should check a change request against the existing requirements, identify where the request is ambiguous for this system, and ask the requester the right questions in the right order, in a way that is cognitively lightweight, but reliable.
4. Define and carry out the evaluation. Propose an evaluation plan, justify it, and run it.
5. Write the report.

Expected outcomes

• A method that decides which points of a change request need clarification, based on the system's existing requirements, and that asks about them with little effort for the requester.
• A working prototype that implements the method.
• Evaluation evidence that shows the benefits and limitations of the solution.
• A final written report that presents the problem, the related work, the method, the evaluation and a dicsussion and conclusions.

Required skills:

• Strong Python and programming skills in general.
• Hands-on use of LLMs and related experimental methods (e.g., baselines, precision and recall, repeated runs)

Meriting:

• Knowledge and/or interest in knowledge graphs.
• A course in requirements engineering.
• A course in natural language processing or machine learning.

Additional supervisor: Muhammad Abbas Khan