A négyszintű követelmény-architektúra
Ez a termék gondolkodásmódbeli gerince: a felhasználó ezen a létrán megy le a szándéktól a kódig. Minden szint egy külön absztrakciós réteg, saját formátummal és célközönséggel.
| Szint | Entitás | Formátum | Kinek szól |
|---|---|---|---|
| L1 Business Case | Üzleti eset buborékok | Gherkin (Given-When-Then) | Döntéshozó, terméktulajdonos |
| L2 User Story & Epic | Story-k, epicek, AC-k | Story sablon + Gherkin AC | Üzleti elemző, architekt |
| L3 Screen & Path | Képernyők, útvonalak, funkció-térkép | Screen flow gráf | Architekt, UI/UX |
| L4 Technical Spec | Komponensek, fájlok, tokenek, sémák | JSON + kódrészletek | Fejlesztő, AI ágens |
A „Big Picture" nézet L2-től lefelé fűzi össze a képernyő-útvonalakat egy interakciós térképpé.
A kulcsmechanizmus
Az L2 acceptance criteria kettős életet él: belőle keletkeznek a fejlesztési taskok és a tesztesetek. Egy AC = egy task = egy teszt.
A schema 1.1.0 óta a Gherkin elfogadási kritériumok egyetlen forrása a Business Case
(acceptanceCriteria). A User Story nem ír saját Gherkint, hanem a szülő Business Case
AC-jaira hivatkozik (acceptanceCriteriaRefs), és eldönti, melyik érvényes rá, és melyik
generáljon Work Package-et (generatesTask — ez story-szintű). Így egy AC pontosítása egy
helyen történik, és minden rá hivatkozó story-ra érvényes.
Részletek: Adatmodell → Egy entitás anatómiája.
Szerepkör-szűrés
Céges használatban a négy szint egyben szerepkör-szűrő is:
| Szerepkör | Látja | Szerkeszti |
|---|---|---|
| Üzleti oldal (BA, PO, CTO) | L1 + L2 | L1–L2 |
| Elemző / architekt | L2 + L3 | L2–L3 |
| Fejlesztő, AI ágens | L3 + L4 | L3–L4, generált Work Package |
Solo/Team edition-nél ez csak UI-szűrő (nincs valódi jogosultság-kényszerítés).
Enterprise-nál (RBAC) ez válik tényleges hozzáférés-kényszerítéssé a server módban — a
gating logika az engine-ben van, nem a UI-ban.