From legacy application to automated quality assurance: AI in requirements engineering
A practical account of AI in requirements engineering: from legacy application screenshots through user stories and acceptance criteria to Gherkin, Zephyr, and Playwright in the CI/CD pipeline.
How do you modernize a business application that has evolved over many years when much of the domain knowledge is embedded in the existing software and the original requirements documentation is only partially available?
This was the challenge I faced in a public-sector redesign project. Alongside requirements engineering and quality assurance, my role was to analyze the existing application from a business perspective, derive structured requirements for the new web application, and establish a foundation for sustainable test automation.
I was able to support the entire process—from analyzing the legacy application to automated regression testing—with an AI solution approved by the customer.

From legacy analysis to continuous quality assurance: requirements, domain review, and tests form a connected process. Original diagram in German.
Open full-size diagram ↗Read the seven steps in English
- Legacy application and screenshots: analyze and visualize the existing application.
- AI-assisted analysis: analyze screenshots and functionality, and structure the information.
- Epics and user stories: derive domain structures and document requirements.
- Acceptance criteria: refine requirements and agree them with the customer.
- Zephyr and Gherkin: create and structure test cases, and manage them in Zephyr.
- Playwright: implement automated end-to-end tests.
- Automated quality assurance: run tests in the pipeline and continuously check core functionality.
Continuous improvement: test findings feed back into analysis.
The challenge: domain knowledge is embedded in the legacy application
Modernizing an existing business application does not always come with complete, up-to-date requirements documentation. A significant part of the implemented domain logic is instead found in screens, workflows, roles, state transitions, and the behavior of the existing application.
For the redesign, this knowledge first had to be captured systematically.
The legacy application was analyzed methodically and documented through numerous screenshots. These showed screens, input fields, tables, status information, and different processing steps.
Instead of evaluating this information entirely by hand, I used an AI solution approved for the project as an analytical tool.
AI as a support tool for requirements engineering
AI helped me systematically analyze the documented interfaces, identify functional relationships, and derive initial domain structures.
The information could, for example, be used to identify potential:
- business functions and processes,
- epics and user stories,
- acceptance criteria,
- role and permission requirements,
- validation and plausibility rules,
- open domain questions, and
- potential test cases.
The crucial point was that AI did not replace consultation with domain experts.
The behavior of the legacy application served as a starting point for analysis, not automatically as the target specification for the new system. The AI-assisted analysis was therefore reviewed systematically and discussed with the relevant domain experts. Only this combination produced reliable requirements and acceptance criteria for the redesign.
This provided substantial support for the time-consuming initial structuring work, while business decisions remained with the responsible people.
From requirements directly to test cases
A particular advantage came from treating requirements engineering and quality assurance as connected activities.
Agreed user stories and acceptance criteria made it possible to derive concrete test scenarios early on. This created an end-to-end connection:
Legacy application → analysis → epic → user story → acceptance criterion → test case → automated test
The test cases were structured around business behavior and described, among other formats, as BDD scenarios in Gherkin. This allowed requirements to be considered from the perspective of later quality assurance before or during development.
Typical scenarios include authentication and authorization, roles and permissions, application lists, filtering and sorting, application processing, and business data reconciliation.
Playwright, Cucumber, and Zephyr as the technical foundation
A modern web testing stack was established for test automation.
Playwright with TypeScript provides the technical foundation for automated browser and end-to-end tests. Cucumber/Gherkin makes it possible to describe business scenarios clearly and close to the requirements. Test cases are organized in Zephyr as part of project and test management and linked to the business requirements.
This makes it possible to automatically validate business scenarios such as displaying assigned applications, filtering, or navigating from the workspace to a specific application.
Test automation is part of the development process rather than a subsequent step.
Automated quality assurance in the CI/CD pipeline
The automated tests are integrated into the CI/CD pipeline and run when changes or deployments occur. This allows particularly important core functions to be checked continuously.
The goal is not to implement every conceivable test as an elaborate end-to-end test. Instead, stable, business-critical workflows are automated selectively and complemented by other testing levels. The test concept therefore combines unit, integration, API, end-to-end, and regression tests with manual and exploratory checks.
Quality assurance becomes a continuous part of software development: a system change can immediately be checked against existing core functionality.
What AI actually changes in this process
For me, the most interesting aspect of this project is not the use of any single AI tool.
The real value comes from connecting several stages of work.
A partially documented legacy application first becomes a structured description of business behavior. This leads to requirements agreed with domain experts. Test cases are derived from these requirements during development. Suitable scenarios are then automated and integrated into the development process.
AI primarily accelerates analysis, structuring, and derivation, while domain evaluation, prioritization, and approval remain human responsibilities.
For me, this project demonstrates how AI-assisted requirements engineering, test management, and test automation can be connected into an end-to-end quality engineering process.