Jak definiować wymagania dla aplikacji w GENESIS-AI
GENESIS-AI to projekt badawczy programu inLABs. Opisane funkcje są celem badań, a nie dostępnym produktem. Status projektu: inLABs
W większości projektów IT najwięcej czasu i ryzyka wiąże się nie z samym programowaniem, lecz z definiowaniem i utrzymywaniem wymagań. Projekt GENESIS-AI ma uprościć ten etap: od rozmowy w języku naturalnym do kompletnej dokumentacji GENESIS-DOCU, która ma być paliwem dla fabryki aplikacji.
Dlaczego klasyczne specyfikacje już nie wystarczają
W tradycyjnych projektach największym wyzwaniem nie jest samo programowanie, lecz stworzenie specyfikacji, która:
- jest zrozumiała zarówno dla zespołów biznesowych, jak i technicznych,
- pozostaje aktualna przez cały czas trwania projektu,
- pozwala szybko sprawdzić, czy budowany system rzeczywiście rozwiązuje problem biznesowy.
Obszerne dokumenty Word, arkusze Excel z listami wymagań i rozproszona dokumentacja techniczna sprawiają, że:
- definiowanie wymagań jest kosztowne i podatne na błędy,
- zmiany są wdrażane powoli i często „giną” po drodze,
- trudno zachować spójność między tym, co uzgodniono, a tym, co faktycznie wdrożono.
W rezultacie specyfikacja staje się statycznym dokumentem zamiast żywego modelu systemu, który można automatycznie przekształcić w działającą aplikację.
Podczas projektowania systemów opartych na AI wszystkie trzy obszary — analiza, rozwój i testowanie — powinny być w możliwie największym stopniu wspierane przez inteligentne narzędzia. W przeciwnym razie dokładamy jedynie kolejną warstwę złożoności.
GENESIS-AI: założenie — od rozmowy do gotowej aplikacji
Na rynku dostępne są dziś różne środowiska generowania aplikacji, ale większość z nich skupia się na samym kodzie i próbuje ograniczyć błędy wynikające z ręcznego programowania za pomocą fragmentów generowanego oprogramowania. Projekt GENESIS-AI idzie o krok dalej: zakłada nie tylko generowanie kodu, lecz kompleksową platformę produkcji aplikacji — od definiowania wymagań, przez projektowanie architektury, po wygenerowanie kompletnej, skonteneryzowanej aplikacji.
Kluczowy jest sposób opisania wymagań na wejściu. Projekt zakłada uproszczenie tego procesu na dwa sposoby:
- biznes ma rozmawiać o systemie w języku naturalnym, o systemie w języku naturalnym,
- rozmowy mają być automatycznie przekładane na ustrukturyzowaną dokumentację w standardzie GENESIS-DOCU na ustrukturyzowaną dokumentację w standardzie GENESIS-DOCU, która staje się „paliwem” dla fabryki aplikacji.
Jak ograniczyć ryzyko niedokładnej specyfikacji
GENESIS-AI zakłada, że aby ograniczyć ryzyko niedokładnych specyfikacji i zmniejszyć koszt ich tworzenia, warto:
- sprowadzić analizę do definiowania wymagań w języku naturalnym,
- skrócić proces tworzenia specyfikacji przy pomocy agentów AI,
- szybko udostępniać prototypy — przede wszystkim interfejsu użytkownika — do oceny przez biznes,
- walidować wymagania i tworzyć mierzalne wskaźniki ich jakości.
W tym miejscu pojawia się GENESIS-BIZSTORY — mechanizm projektu GENESIS-AI, który ma przekładać rozmowy na precyzyjnie opisane wymagania.
GENESIS-BIZSTORY: definiowanie wymagań w języku naturalnym
**GENESIS-BIZSTORY ma być wspieranym przez AI interfejsem konwersacyjnym, który prowadzi zespół przez proces definiowania wymagań. Projekt zakłada kilka trybów dostosowanych do złożoności rozwiązania:
- Rozmowa z asystentem w języku naturalnym – dla najprostszych aplikacji (np. MVP), gdzie najważniejsze jest szybkie przejście od pomysłu do działającej wersji.
- Rozmowa moderowana – dla prostszych systemów, w których potrzebna jest dodatkowa kontrola nad wybranymi funkcjami (np. rolami, uprawnieniami, integracjami).
- Moderowana rozmowa biznesowa – dla bardziej złożonych aplikacji, w których wymagania trzeba określić bardzo szczegółowo.
Moderacja oznacza, że w procesie mają uczestniczyć wyspecjalizowani agenci AI odpowiedzialni za różne aspekty systemu, w tym:
- interfejs użytkownika (UI),
- integracje,
- model danych,
- testowanie.
Agenci zadają pytania doprecyzowujące, wykrywają sprzeczności i dbają o spójność wymagań już na etapie dyskusji, zanim rozpocznie się generowanie aplikacji.
W trybie moderowanym agent odpowiedzialny za UI może także na bieżąco prezentować prototypy ekranów — bez generowania całej aplikacji — co pozwala szybciej zbierać informacje zwrotne i unikać sytuacji, w której użytkownik po raz pierwszy „widzi” system dopiero podczas testów akceptacyjnych.
Od rozmowy do standardu GENESIS-DOCU
Każdy z opisanych trybów ma prowadzić do jednego celu: stworzenia precyzyjnego, ustrukturyzowanego opisu aplikacji. Ostateczny kształt rozwiązania zależy od szczegółowości rozmowy i wybranego trybu pracy, a całość można dodatkowo wzbogacić przy użyciu metajęzyka GENESIS-DOCU.
W wyniku pracy GENESIS-BIZSTORY ma automatycznie powstawać dokumentacja zgodna ze standardem GENESIS-DOCU – spójny opis procesów, ról, danych i interfejsów, który:
- jest czytelny dla biznesu, analityków i architektów,
- można iteracyjnie rozwijać i udoskonalać,
- ma stanowić bezpośrednie polecenie do wygenerowania kompletnej aplikacji w GENESIS-AI.
Walidacja wymagań ma trwać także podczas generowania aplikacji: platforma ma sygnalizować niespójności, braki lub potencjalne ryzyka, zanim kod trafi do środowiska testowego lub produkcyjnego.
Co zyskują organizacje, które przechodzą na ten model?
Z perspektywy organizacji — niezależnie od tego, czy mówimy o software housie, dziale IT w banku czy zespole produktowym w startupie — taki sposób definiowania wymagań oznacza:
- mniej czasu poświęcanego na ręczne pisanie i aktualizowanie złożonych specyfikacji,
- szybsze udostępnianie pierwszych wersji rozwiązania (UI, przepływy pracy), które można ocenić wspólnie z użytkownikami,
- wyższą jakość wymagań, którą można monitorować i mierzyć,
- szybkie wprowadzanie zmian: aktualizacja GENESIS-DOCU ma przekładać się na nową wersję aplikacji wygenerowaną przez GENESIS-AI
Oznacza to mniej projektów „ratunkowych” po wielu miesiącach pracy, a więcej krótkich iteracji obarczonych mniejszym ryzykiem i lepiej dopasowanych do rzeczywistych potrzeb użytkowników. Dla wielu zespołów jest to nie tylko poprawa komfortu pracy, ale przede wszystkim realna zmiana modelu ryzyka: zamiast po wielu miesiącach odkrywać, że system „nie spełnia” potrzeb, można iteracyjnie rozwijać wymagania i aplikację w jednym spójnym cyklu – od rozmowy do działającego produktu.