Preskočiť na obsah

Stránky analytika

Táto referencia pokrýva hlavné analytické pracovné priestory od plánovania špecifikácie po refinement Requirements a Use Cases. Použite ju vtedy, keď už poznáte analytický flow a potrebujete rýchlu odpoveď na úrovni konkrétnej stránky: na čo stránka slúži, prečo by ste ju otvorili, ktoré akcie sú dôležité a aké modaly na nej očakávať. Stačí vám bežný prístup do aplikácie a väčšina sekcií sa dá prečítať za minútu alebo dve.

Stránka Specification workspace

Účel

Specification workspace používajte ako zjednodušený cockpit pre jednu specification. Zhrnie, čo existuje, čo treba skontrolovať, stav pokrytia, pripravenosť na odovzdanie do implementácie a jeden odporúčaný ďalší krok. Pre novších používateľov je to preferovaný prvý vstup do prípravy špecifikácie, pretože ukazuje postup Štart, Návrh, Kontrola, Prepojiť, Validovať a Odovzdanie.

Sekcia Start here používa rovnaký známy model ako AI, Implementation a Feature workspace: kompaktné KPI, očíslovaný postup prípravy a úzky pás odporúčanej akcie zarovnaný so zvýrazneným krokom. Kroky aj odporúčania zostávajú špecifické pre prácu na špecifikácii. Tenká jantárová čiara na ľavom okraji zodpovedajúcej sekcie nižšie opakuje aktuálne odporúčanie.

Súvisiaci "Flow"

Hlavné akcie

  • skontrolovať sekciu Start here a odporúčaný ďalší krok vrátane počtu aktívnych Test Cases, keď sú Test Cases zapnuté, a kompaktných signálov Ubiquitous Language pre termíny a zistenia
  • otvoriť Pracovať na dokumente špecifikácie a upravovať Requirements, Use Cases a Test Cases v SmartDoc
  • pozrieť draft, bookmarked, bežiace alebo zlyhané položky v Needs your review
  • skontrolovať otvorené zistenia Ubiquitous Language v Needs your review, keď je Ubiquitous Language zapnutý
  • skontrolovať Pokrytie a medzery pre pokrytie Requirements cez Use Cases a pokrytie Use Cases cez Test Cases
  • skontrolovať Pripravenosť na odovzdanie, ktorá oddeľuje pripravenosť špecifikácie od pripravenosti na implementačný handoff
  • použiť Akcie s podporou AI na existujúce workflowy enhancementu, generovania Use Cases, terminológie, návrhov prepojení a gap analysis
  • použiť Detailné nástroje na prechod do stránok Epics, Epic, Requirement, Use Case, Test Case, Ubiquitous Language a Gap analysis, keď vás tam navedie guided workspace

Poznámky

Workspace nenahrádza pokročilé stránky. Odkazuje do nich, aby zostala dostupná traceability, detailná kontrola a akcie konkrétnych artefaktov. Staršie Test Cases so stavom obsolete sa ignorujú v počtoch workspace-u, pokrytí, review zoznamoch aj skratkách recent work.

Terminológia workspace-u zodpovedá detailným stránkam: Epic, Requirement, Use Case, Test Case a Ubiquitous Language.

Stránka Project Demo

Účel

Project Demo slúži na prípravu a vedenie série stakeholder stretnutí pre jednu Specification. Demo Series určuje zamýšľaný rozsah Ubiquitous Language a artefaktov. Môže obsahovať viacero Demo Sessions, takže Specification možno prejsť počas viacerých stretnutí alebo sa vrátiť k už prezentovanému obsahu.

V režime Série vytvorte hlavný rozsah a sledujte pokryté, zostávajúce a od ukážky zmenené položky. Ukážku môže viesť ľubovoľný typ schváleného UL termínu. Fullscreen dialóg Series zachováva workspace pôvodného Project Demo: termíny možno filtrovať podľa kľúčového slova, zobraziť najviac štyri lanes typov, meniť ich poradie potiahnutím a vyberať karty termínov. Cieľ Series zadajte priamo do upraviteľného poľa. Oblasť priradených artefaktov zobrazuje iba prienik artefaktov, na ktoré explicitne odkazuje každý vybraný termín, podporuje filtre RQ/UC/TC a pohľad zoznam/detail. Textové zhody sa neodporúčajú. Následné vyhodnotenie rozsahu zahrnie explicitné UL artifact references aj autoritatívnu RQ–UC–TC lineage.

V režime Príprava zúžte rozsah ďalšej Session, vyberte jazyk, vyriešte upozornenia zdrojov a vygenerujte alebo upravte šesťdielny scenár s citáciami. Rozbaľte Upraviť zdroje pod časťou scenára, ak potrebujete opraviť jej typované citácie na UL termíny a artefakty. Asociácie rozsahu a zdrojov sa vyberajú kartami, zatiaľ čo referencie RQ/UC/TC sa na obrazovkách ukážky zobrazujú ako kompaktné typované štítky. Ak lokalizovaný text artefaktu nie je dostupný, potvrďte použitie kanonickej angličtiny. Spustiť ukážku zmrazí presné definície, výňatky artefaktov, stavy, scenár, citácie, jazykové zdroje a verzie použité na stretnutí.

Režim prezentácie je zákaznícky pohľad zdieľanej obrazovky. Obsahuje iba pripravený scenár, súvisiace zmrazené definície UL, zjednodušené zmrazené artefakty, navigáciu a poznámky zo stretnutia. Uložené poznámky sa posúvajú v zozname, ktorý vyplní zostávajúcu výšku panela. Finalizovať Session je v rovnakom riadku ako ovládacie prvky Predchádzajúce/Ďalej, ale je od nich vizuálne oddelené. Klávesom N mimo vstupného poľa presuniete fokus do poznámky; Ctrl+Enter ju uloží. Uložená poznámka sa zobrazí okamžite a prepojí sa s aktuálnym kontextom prezentácie.

Po Finalizovať Session použite Vyhodnotenie na kontrolu odprezentovaného rozsahu, chronologických aj zoskupených poznámok, rozhodnutí, otázok, následných úloh, kandidátskej terminológie a AI rekapitulácie. Poznámky v chronologickom zozname možno filtrovať podľa kľúčového slova alebo typu bez zmeny počtov výsledkov či vstupu rekapitulácie. Poznámky možno naďalej upravovať s históriou revízií; úprava označí staršie rekapitulácie, ktoré ju citujú, ako neaktuálne. Dialóg úpravy umožňuje opraviť aj hovoriaceho, príznak následnej úlohy a zmrazené asociácie na UL termíny či artefakty. Typované štítky artefaktov otvoria editory RQ, UC alebo TC bez opustenia vyhodnotenia. Vyriešené poznámky možno označiť priamo v chronologickom zozname a podľa potreby ich znovu otvoriť. Dokončenie série so zostávajúcim rozsahom vyžaduje explicitné potvrdenie a zostávajúci zoznam zachová.

Vygenerované rekapitulácie zobrazujú súhrn kategórií a vizuálne oddeľujú odprezentovaný obsah, vyjadrenia zákazníka, dohody, nevyriešené položky, následné úlohy a kandidátsku terminológiu. Najnovšia verzia je predvolene rozbalená, staršie verzie možno zbaliť a každá položka uvádza počet podporných zdrojov. Odprezentovaný obsah je predvolene skrytý a možno ho prepnúť jeho štítkom kategórie. Ak séria stále obsahuje neodprezentovaný rozsah, povinné potvrdenie pri dokončení používa štandardný výberový ovládací prvok.

Poznámky

Analyst vedie stretnutie v jednom zdieľanom okne. Neexistuje samostatné konto publika ani stav potvrdenia. Kandidátska terminológia je výsledok určený na neskoršie zapracovanie; demo nevytvára ani nemení UL termíny či specification artefakty. Perzistentné Project Demo summaries zostávajú kompatibilné v API, ale dialóg Series ich nepoužíva.

Stránka SmartDoc

Účel

Stránku SmartDoc používajte na kontrolu a úpravu jedného Epic ako štruktúrovaného ProseMirror dokumentu. Každý blok zostáva namapovaný na zdrojový Requirement, Use Case alebo Test Case, takže úpravy stále prechádzajú cez bežné API a pokročilé detailné stránky.

AIKOZO SmartDoc umožňuje používateľom pracovať s Requirements, Use Cases a Test Cases v jednom súvislom editore podobnom dokumentu, pričom každý artefakt zostáva zachovaný ako štruktúrovaný a traceable record.

Súvisiaci "Flow"

Hlavné akcie

  • otvoriť stránku zo Specification workspace -> Pracovať na dokumente špecifikácie, tlačidlom Open SmartDoc na stránke Epic alebo tlačidlom SmartDoc na riadku artefaktu, ktoré otvorí danú položku s kurzorom v upraviteľnom SmartDoc poli
  • prepínať medzi Requirements, Use Cases a Test Cases
  • upravovať canonical a lokalizovaný text inline ako samostatné štruktúrované polia
  • v bilingválnych projektoch použiť Show Canonical EN / Hide Canonical EN na zobrazenie alebo skrytie read-only canonical angličtiny nad lokalizovaným textom
  • v režime Use Cases upravovať v dokumente iba title a canonical text; pre hlbšie ovládanie Use Case použiť Advanced detail
  • v režime Test Cases upravovať title, canonical text a lokalizovaný text; pre traceability a scenario-specific polia použiť Advanced detail
  • nechať draft úpravy autosavovať, alebo použiť Save draft a Finalize explicitne
  • kontrolovať inline Validation Blockers na dotknutých artefaktoch pre blokovania ako chýbajúci canonical final text, nefinalizované zdrojové artefakty a zistenia z validácie formátu
  • použiť Finalize na AI kontrolu formátu podľa aktívnych presetov pre Requirements, Use Cases a Test Cases; backend blokery sa zobrazia priamo v dotknutej položke SmartDoc
  • použiť Add block alebo Ctrl+Enter na vytvorenie nového draft Requirement, Use Case alebo Test Case za aktuálnou pozíciou kurzora
  • vymazať record-backed Requirement, Use Case a Test Case bloky cez ovládanie bloku
  • pri vymazaní Requirement sa jeho referencie odstránia zo zachovaných Use Cases a Test Cases; pri vymazaní Use Case sa prepojené Test Cases zachovajú a ich referencia na Use Case sa odstráni
  • spustiť AI enhancement, skontrolovať inline diff náhľad a až potom ho výslovne použiť alebo zahodiť
  • pri zapnutom sémantickom vyhľadávaní zvýrazniť zodpovedajúce bloky v dokumente
  • keď je zapnutý Ubiquitous Language, kontrolovať jemné SmartDoc finding markery a badge-e na dotknutom texte Requirements, Use Cases a Test Cases
  • otvoriť Advanced detail pre úplnú traceability a detailné ovládanie artefaktu

Bezpečné limity

Final Epics sú na tejto stránke iba na čítanie. Rozdelenie Requirement je record-aware: aktuálny Requirement sa patchne a pre druhú časť vznikne nový draft Requirement record. Zlúčenie Requirement ponechá predchádzajúci Requirement ako prežívajúci record, spojí doň text a zlúčený zdrojový Requirement označí ako deferred; zdrojový záznam sa nevymaže. AI enhancement náhľady nemenia uložený text, kým nepoužijete Apply preview. Stránka nepodporuje drag reorder, pretože Requirements, Use Cases a Test Cases zatiaľ nemajú pole poradia. SmartDoc finding markery sú read-only signály z Ubiquitous Language findings. Ak AIKOZO nevie finding bezpečne priradiť k viditeľnému textu artefaktu, blok zobrazí iba finding badge bez inline markeru. V bilingválnych projektoch sa inline finding markery umiestňujú iba na lokalizovaný text. Opakované exact zhody termínov sa zvýrazňujú bez ohľadu na veľkosť písmen. Accept, Reject a Defer pri SmartDoc finding-u aktualizujú stav review zistenia; neprepisujú text artefaktu.

Finalizácia je vynucovaná API. Requirements, Use Cases a Test Cases potrebujú canonical final text. Keď je projektové nastavenie Format Enforcement na Enforce, artefakty musia pred prechodom do stavu final prejsť aj aktívnym formátovým presetom; pri Warning Only sa problémy formátu zobrazia ako upozornenia a finalizácia môže pokračovať. Nové osobné projekty a existujúce projekty spred tohto nastavenia majú predvolené Warning Only; nové kolaboratívne projekty majú predvolené Enforce. Finalizácia Use Case vždy vyžaduje, aby prepojené Requirements boli final a mali canonical final text. Finalizácia Test Case vždy vyžaduje final-ready zdrojový Use Case a prepojené Requirements. Finalizácia Epic naďalej vynucuje stav artefaktov, canonical text a pravidlá formátu, ale referenciu na artefakt, ktorý bol medzičasom vymazaný, vyhodnotí ako upozornenie namiesto zlyhania celej úlohy Epic.

Stránka Epics

Účel

Stránku Epics používajte ako hlavný analytický workspace pre jednu specification. Spája správu Epics, sémantické vyhľadávanie, Ubiquitous Language a gap analysis.

Súvisiaci "Flow"

Hlavné akcie

  • filtrovať, radiť a otvárať Epics; kompaktný ovládač na tabe Epics prepína najstaršie, najnovšie a poradie podľa key a zachová výber v URL
  • vytvoriť nový Epic manuálne
  • vygenerovať Epic a štartovacie Requirements z business Requirement
  • spustiť sémantické hľadanie naprieč Requirements, Use Cases, Test Cases a prijatými termínmi Ubiquitous Language, keď sú príslušné funkcionality zapnuté
  • prepínať medzi Epics, Ubiquitous Language a Gap analysis
  • keď sú zapnuté Spec Connectiony, prepnúť sa na Spec Connections a nakonfigurovať JIRA, GitHub alebo GitLab downstream destinácie pre specification
  • kontrolovať staged návrhy Ubiquitous Language, prijímať termíny, zlučovať aliasy, odmietať šum a prechádzať nálezy sémantického nesúladu
  • spustiť gap analysis, upravovať thresholdy a kontrolovať výsledkové riadky
  • otvárať detail coverage z výsledkov gap analysis
  • spravovať Spec Connectiony bez ukladania provider tokenov na connectione; validácia connectionu používa vaše Profile Security Tokens
  • importovať existujúce provider issues cez Spec Connection do nového Epicu ako Requirements alebo Use Cases
  • New Epic
  • Generate Epic with Requirements
  • New from issues: výber aktívneho Spec Connectionu, načítanie nedávnych otvorených provider issues, výber riadkov a import do nového Epicu ako Requirements alebo Use Cases
  • Spec Connection details: pridanie, úprava, validácia, aktivácia, deaktivácia alebo vymazanie JIRA, GitHub alebo GitLab connectionu pre túto specification
  • Coverage map: zobrazuje detailné Requirement coverage za vybraným reportom Gap analysis a ukazuje rozhodnutia o prijatí bez ďalšej akcie alebo vytvorení Requirement z predošlých revízií; značky krokov používajú U pre používateľa alebo externého aktéra, S pre systém, službu alebo platformu a X, keď aktér nie je jasný

Záložka Ubiquitous Language je riadená sémantická základňa pre aktívnu specification a predvolený vstup pre downstream generovanie Architecture. AI analyzuje Requirements a Use Cases po Epicoch a potom konsoliduje výsledky z Epicov do jedného projektového review frontu. Prijaté termíny sa menia iba explicitnou akciou používateľa. Prijaté termíny sa zároveň indexujú pre sémantické vyhľadávanie a zobrazujú sa ako výsledky Ubiquitous Language term s badge štýlu entity/process/policy. Prepínačmi typov termínov v Accepted terms zúžite viditeľnú baseline podľa Role, Entity, Process, Policy, Value alebo Event. Nevyhovujúce typy termínov zostanú viditeľné, aby sa dali skontrolovať a opraviť namiesto toho, aby zmizli za filtrom.

Spec Connectiony

Keď sú zapnuté Spec Connectiony, použite záložku Spec Connections na definovanie downstream miesta, kam sa majú synchronizovať artefakty špecifikácie. Flow synchronizácie špecifikácie podporuje aktívne JIRA, GitHub a GitLab connectiony pre Requirements a Use Cases.

Pre JIRA Spec Connection nastavte:

  • Connection URL: základnú URL JIRA stránky, napríklad https://your-domain.atlassian.net pre JIRA Cloud alebo základnú URL vašej JIRA Data Center inštancie
  • Project key: viditeľný kľúč JIRA projektu, napríklad KEY; číselný Project ID je dostupný v pokročilých identifikátoroch iba pre neštandardné JIRA nastavenia
  • Issue type: názov JIRA issue typu, ktorý sa má vytvárať; ak ho nevyplníte, AIKOZO použije Task. Táto hodnota určuje JIRA-side typ artefaktu pre každý Requirement alebo Use Case issue vytvorený cez tento Spec Connection. Použite presný názov issue typu dostupný v cieľovom JIRA projekte, napríklad Story, Task, Bug alebo Ticket; zadajte Story, keď sa majú synchronizované AIKOZO artefakty vytvárať v JIRA ako Stories. Číselný Issue type ID je pokročilý fallback, keď inštancia neakceptuje display name.
  • voliteľný Parent issue key, keď majú vytvorené issues patriť pod existujúci JIRA parent; nechajte ho prázdny, keď sa synchronizované issues nemajú zaradiť do JIRA hierarchie; číselný Parent issue ID je pokročilý fallback
  • voliteľné JIRA issue linky, keď sa má každé synchronizované issue prepojiť s existujúcim JIRA issue; použite existujúci JIRA link label presne tak, ako je zobrazený v Linked work items, a linked issue key musí byť dostupný počas validácie connectionu. Pre implementačnú väzbu použite implements, keď má synchronizované AIKOZO issue implementovať linked issue key, napríklad synchronizované issue ENG-42 implements KEY-21. Použite is implemented by pre opačnú orientáciu, napríklad synchronizované issue ENG-42 is implemented by KEY-21.
  • voliteľné labels, ktoré sa pridajú na každé vytvorené a aktualizované JIRA issue a pomáhajú filtrovať alebo identifikovať AIKOZO položky v JIRA
  • aktívny alebo neaktívny stav; v sync modale sa zobrazujú iba aktívne Spec Connectiony

Pre GitHub Spec Connection nastavte repository v tvare owner/repository. Pre GitLab Spec Connection nastavte buď GitLab project ID alebo repository path, napríklad group/project. GitHub a GitLab connectiony synchronizujú issue title, body alebo description a labels.

Spec Connectiony neukladajú provider secrets. Najprv uložte pomenovaný provider token v Profile > Security tokens. Nové Spec Connectiony majú predvolenú viditeľnosť Personal: vidíte ich iba vy a používajú vybraný názov tokenu z vášho profilu. Shared Spec Connectiony vidia oprávnení používatelia s prístupom k projektu, ale vždy používajú token aktuálneho používateľa označený ako default pre daného providera, nie token tvorcu connectionu. Pomocou Validate connection overíte, že váš aktuálny profilový token vie pristúpiť ku konfigurovanému projektu alebo repository. Existujúce connectiony sa berú ako Shared.

Viditeľnosť a použitie tokenov

Viditeľnosť vyberáte pri vytvorení Spec Connectionu. Neskôr sa nedá zmeniť.

  • Personal: connection sa zobrazuje iba používateľovi, ktorý ho vytvoril, stále podľa rovnakých project access kontrol. Provider volania používajú vybraný pomenovaný Profile Security Token z profilu daného používateľa. Tento režim použite, keď má byť samotný routing súkromný alebo keď má connection používať konkrétny pomenovaný token.
  • Shared: connection sa zobrazuje používateľom, ktorí prejdú projektovým a Spec Connection RBAC. Provider volania nepoužívajú PAT tvorcu connectionu. Každý používateľ musí mať vlastný Profile Security Token pre daného providera označený ako default. Ak aktívny používateľ nemá default token, AIKOZO v UI deaktivuje load/import/sync akcie a API odmietne operáciu ešte pred provider volaním alebo vytvorením sync runu.

Aj validácia zdieľaného connectionu je viazaná na aktívneho používateľa. Úspešná validácia jedného používateľa neznamená, že connection vie použiť každý ďalší používateľ; každý stále potrebuje vlastný provider token a provider permissions. Pri osobnej validácii sa výsledok môže zobrazovať ako stav connectionu, pretože connection patrí jednému používateľovi.

Zo záložky Epics akcia New from issues používa vybraný aktívny Spec Connection ako zdroj issues. JIRA import načíta nedávne otvorené issues z nakonfigurovaného projektu a zároveň použije issue type, parent a issue link filtre z connectionu, keď sú nastavené. GitHub a GitLab import načíta nedávne otvorené issues z nakonfigurovanej repository alebo projektu. Import vytvorí nový Epic a v background jobe vytvorí vybrané issues ako Requirements alebo Use Cases. Po zaradení importu sa modal zatvorí a zoznam Epicov sa obnoví, zatiaľ čo job pokračuje. Importované artefakty uložia text provider issue ako original text podľa locale pravidiel projektu a adoptujú remote issues ako downstream mappingy, takže neskorší Sync SPEC aktualizuje tie isté source issues. V lokalizovaných bilingválnych projektoch sa importovaný provider text zároveň preloží do kanonickej angličtiny a pôvodný provider text sa zachová ako lokalizovaný source text.

Connectiony, ktoré sú viditeľné, ale aktuálnemu používateľovi chýba požadovaný token, zostanú v zozname ako nedostupné. Pred načítaním issues, importom issues alebo spustením Sync SPEC pridajte požadovaný Profile Security Token.

Working with JIRA

Tento flow použite, keď má analytik synchronizovať AIKOZO Requirements alebo Use Cases do JIRA issues. Spec Connection sync zo stránky Epic spracúva Requirements a Use Cases; Test Cases sa z tohto flowu nesynchronizujú.

  1. Vytvorte JIRA token:
  2. Pre JIRA Cloud vytvorte Atlassian API token na https://id.atlassian.com/manage-profile/security/api-tokens. V AIKOZO ho uložte ako <atlassian-email>:<api-token>, napríklad analyst@example.com:token.
  3. Pre JIRA Data Center alebo Server vytvorte Personal Access Token v JIRA profile a v AIKOZO uložte iba surovú hodnotu PAT.
  4. JIRA účet, ku ktorému token patrí, musí vedieť prehliadať cieľový projekt a vytvárať alebo upravovať issues v tomto projekte.
  5. Uložte token v AIKOZO:
  6. Otvorte Profile > Security tokens.
  7. Vyberte provider JIRA.
  8. Uložte token pod názvom, napríklad sync_bot. Ak sa má tento token používať pre zdieľané JIRA Spec Connectiony, použite Make default. AIKOZO po uložení hodnotu zamaskuje, preto ju skopírujte z JIRA pred zatvorením JIRA token stránky.
  9. Vytvorte JIRA Spec Connection:
  10. Otvorte záložku Spec Connections v danej specification.
  11. Pridajte JIRA connection.
  12. Zvoľte Personal, keď má connection vidieť iba vy a má používať vybraný pomenovaný token. Zvoľte Shared, keď majú connection vidieť oprávnení používatelia a každý má používať vlastný default JIRA token.
  13. Nastavte Connection URL na základnú URL JIRA stránky, napríklad https://your-domain.atlassian.net.
  14. Nastavte Project key na JIRA project key, do ktorého sa majú issues synchronizovať.
  15. Nastavte Issue type na JIRA-side typ artefaktu, ktorý sa má vytvárať, napríklad Story, Task, Bug alebo Ticket; použite Story, keď sa majú AIKOZO artefakty vytvárať v JIRA ako Stories.
  16. Voliteľne nastavte Parent issue key, labels a JIRA issue linky. Pri issue linkoch implements znamená, že synchronizované AIKOZO issue implementuje nakonfigurované linked issue, zatiaľ čo is implemented by vytvorí opačnú orientáciu.
  17. Vyberte názov uloženého JIRA tokenu, validujte connection a označte ju ako aktívnu.
  18. Synchronizujte AIKOZO artefakty do JIRA:
  19. Otvorte stránku Epic a vyberte záložku Requirements alebo Use Cases.
  20. Pomocou filtrov, vyhľadávania, sortu a bookmarked-only prepínača určite, ktoré artefakty sa majú spracovať.
  21. Vyberte Sync SPEC, zvoľte aktívnu JIRA Spec Connection, skontrolujte zhrnutie filtrov a spustite sync.
  22. Sync beží na pozadí. Modal zobrazuje počty vytvorených, aktualizovaných, nezmenených, remote changes, konfliktných a zlyhaných položiek. Pri vytvorených JIRA issues AIKOZO uloží downstream mapping, takže neskorší sync aktualizuje rovnaké JIRA issue.

Ako alternatívny začiatok môže analytik vytvoriť celý Epic z JIRA: na záložke Epics vyberte New from issues, zvoľte aktívnu JIRA Spec Connection, načítajte nedávne otvorené JIRA issues, vyberte issues na import a vytvorte ich ako Requirements alebo Use Cases v novom Epicu. Importované artefakty si ponechajú JIRA issue mappingy, takže neskorší Sync SPEC aktualizuje tie isté source issues.

Stránka Epic

Účel

Stránku Epic používajte na organizáciu analytickej práce pre jeden Epic v záložkách Requirements, Use Cases, Test Cases a voliteľný dependency graph.

Súvisiaci "Flow"

Hlavné akcie

  • prepínať medzi Requirements, Use Cases, Test Cases a voliteľným Dependency graph
  • meniť stav Epic medzi draft a final; finalizácia prebieha ako backendová úloha, zostáva viditeľná v Úlohách na pozadí a po dokončení aktualizuje stránku
  • finalizovať jednotlivé riadky Requirement, Use Case a Test Case; blokované validačné odpovede zobrazia na danom riadku červenú správu Final text
  • keď finalizácia Epic zlyhá, pretože final text artefaktu neprešiel validáciou pripravenosti, skontrolovať červenú správu Final text na dotknutom riadku
  • keď je generovanie Use Case alebo Test Case zablokované nefinálnymi zdrojovými artefaktmi alebo chýbajúcim canonical final textom, skontrolovať červenú správu s blokovaním priamo pod nadpisom modalu generovania
  • filtrovať Requirements, Use Cases a Test Cases podľa vyhľadávania, lifecycle stavu a bookmark markerov na follow-up
  • vytvárať, importovať a hromadne vylepšovať Requirements
  • vytvárať, AI-generovať, auto-generovať a hromadne vylepšovať Use Cases
  • keď sú zapnuté Spec Connectiony, synchronizovať filtrované Requirements alebo Use Cases do aktívneho Spec Connectionu; Test Cases sa z tohto flowu nesynchronizujú
  • vytvárať manuálne Test Cases a meniť ich review stav
  • generovať nové Test Cases z vybraných, nepokrytých alebo všetkých Use Cases s voliteľným výberom typov scenárov
  • hromadne vylepšovať Test Cases, ktoré sú ešte v stave new, cez Enhance new
  • exportovať skontrolované a finálne Test Cases zo záložky Test Cases cez Export Xray, keď je Xray export zapnutý
  • otvárať detaily Requirements a Use Cases na hlbší refinement
  • kontrolovať traceability Requirement -> Use Case -> Test Case vo vrstvenom dependency graph-e, keď je graph zapnutý
  • používať horné markery SEM6 a LINKS na riadkoch Requirements, use case-ov a Test Cases na kontrolu existencie embeddings a graph väzieb; modrá znamená, že existujú, sivá znamená, že chýbajú
  • používať kompaktný superscript ULn na identifikáciu riadkov s otvorenými Ubiquitous Language findings a otvoriť riadok priamo v SmartDoc na review
  • New Requirement: manuálne vytvorenie jednej Requirement
  • Import Requirements: import zoznamu Requirements z externého textu
  • New Use Case: manuálne vytvorenie jedného Use Case
  • Generate Use Case from Requirements: vytvorenie Use Case z vybraných Requirements; vybrané Requirements musia byť final a mať canonical final text
  • Sync SPEC: výber aktívneho použiteľného Spec Connectionu, potvrdenie aktuálnych filtrov, spustenie async synchronizácie a kontrola vytvorených, aktualizovaných, nezmenených, konfliktných alebo zlyhaných downstream issues
  • New Test Case: manuálne vytvorenie štruktúrovaného Test Case prepojeného na Use Case a Requirements; keď je Use Case už vybraný, jeho prepojené Requirements sa vyberú automaticky
  • AI New: spustenie AI generovania nových Test Case záznamov; vybrané zdrojové Use Cases a prepojené Requirements musia byť final a mať canonical final text. Predvolene sú vybrané všetky používateľsky voliteľné typy scenárov a používateľ môže generovanie obmedziť na vybrané typy, napríklad happy_path, negative alebo edge

Downstream synchronizácia špecifikácie

Downstream sync sa spúšťa zo záložky Requirements alebo Use Cases na stránke Epic. Používa aktívne filtre na aktuálnej záložke, takže vybraný status, bookmarked-only prepínač, vyhľadávací výraz a sort určujú, ktoré artefakty sa spracujú.

Synchronizácia beží asynchrónne cez background job. Po výbere aktívneho použiteľného Spec Connectionu a spustení syncu modal priebežne načítava run a zobrazuje počty:

  • Created: AIKOZO vytvorilo nové downstream issue a uložilo väzbu
  • Updated: AIKOZO aktualizovalo existujúce prepojené downstream issue
  • Unchanged: aktuálna Requirement alebo Use Case už zodpovedá poslednému synchronizovanému stavu downstream issue
  • Remote changes: importovateľné remote polia sa zmenili downstream a dajú sa po explicitnom potvrdení importovať späť do AIKOZO, keď sa rovnaká položka nezmenila v AIKOZO
  • Conflicts: AIKOZO odmietlo aktualizáciu, pretože uložené downstream issue chýba, nie je prístupné, nemá bezpečnú sync baseline alebo sa remote zmenilo mimo bezpečného importu
  • Failed: provider odmietol operáciu alebo connection/token nebolo možné použiť

Tabuľka výsledkov zobrazuje rovnaký outcome v stĺpci Výsledok syncu a pri úspešnom odoslaní lokálnych zmien downstream ukáže správu ako Issue aktualizované..

Pri vytváraní downstream issue AIKOZO posiela kanonický issue title, body alebo description, labels a provider-specific routing polia cez vybraný Spec Connection. JIRA navyše posiela project, issue type, voliteľný parent a nakonfigurované issue linky. Pri existujúcich prepojených issues AIKOZO spravuje iba title/body/labels: JIRA summary, description a labels; GitHub title, body a labels; GitLab title, description a labels. Pred aktualizáciou existujúceho issue načíta tieto polia od providera a porovná ich s posledným stavom, ktorý AIKOZO zapísalo. Generovaný traceability blok na konci remote body alebo description sa pri porovnaní ignoruje. Ak niekto zmenil iba text remote body/description alebo remote title pre Use Case, zatiaľ čo AIKOZO Use Case ostal bez zmeny, riadok sa zobrazí pod Remote changes s akciou Confirm import. Po jej výbere sa remote body alebo description text, bez traceability bloku, importuje do Requirement alebo Use Case; pri Use Cases sa remote title importuje ako názov Use Case. Import sa potvrdzuje po jednotlivých položkách. Ak sa zmenilo AIKOZO aj remote položka, riadok sa zobrazí ako konflikt a remediácia je potvrdiť Overwrite remote, čím AIKOZO ostáva autoritatívne. Timeline záznamy vytvorené potvrdeným importom sa zobrazia ako akcia potvrdzujúceho používateľa a budú označené Downstream sync.

Pre Requirements je downstream title nastavený na human ID Requirementu. Pre Use Cases je downstream title nastavený na názov Use Case. Downstream body alebo description začína lokalizovaným final textom, keď je dostupný; ak final text chýba, použije lokalizovaný original text. Traceability sa pridáva na koniec a používa AIKOZO kľúče, napríklad project, specification, Epic, Requirement a Use Case keys, namiesto MongoDB IDs.

Test Cases sa z tohto flowu nesynchronizujú.

Xray CSV export

Keď je zapnutý Xray export, na záložke Test Cases sa zobrazí Export Xray. Exportuje skontrolované a finálne Test Cases Epic ako CSV oddelené bodkočiarkou, kompatibilné s krokovým mapovaním Xray Test Case Importer. Každý krok Test Case sa exportuje ako samostatný riadok s rovnakým Issue Id; preconditions, test data a evidované gaps sú súčasťou test summary v prvom riadku. Stĺpec Test type používa scenario type Test Case, napríklad happy_path alebo negative. Stiahnutý súbor má názov aikozo-{project-key}-{spec-key}-{epic-key}-tests.csv. Súbor následne importujte v Jira/Xray cez Xray Test Case Importer.

Aktuálne limity: export vytvára iba nové testy, preto je Issue key prázdny. Automaticky nevytvára Test Sets ani Preconditions a exportuje iba krokový CSV formát Test Cases.

Stránka Requirement

Účel

Stránku Requirement používajte na refinement jedného Requirement, správu jeho final textu a kontrolu histórie enhancementov a väzieb.

Súvisiaci "Flow"

Hlavné akcie

  • kontrolovať original text, uložený final text, prompt template a kontext; editor final textu je prázdny, kým sa final text neuloží
  • označiť Requirement bookmarkom na neskôr
  • prejsť na predchádzajúcu alebo nasledujúcu Requirement v rovnakej Epic z context tree
  • ukladať zmeny, finalizovať alebo odložiť Requirement
  • keď finalizácia zlyhá, skontrolovať červenú validačnú správu Final text vedľa labelu
  • skopírovať original text do final textu cez Use as final; zmena sa uloží a Requirement sa vráti do stavu draft
  • spustiť Enhance, voliteľne zadať guidance pre AI vylepšenie a kontrolovať enhancement históriu
  • prezrieť podobné Requirements v záložke Semantics, ak je dostupná
  • navrhovať, schvaľovať, zamietať, vytvárať a upravovať Requirement links
  • kontrolovať, pridávať a odoberať Use Cases pokrývajúce Requirement
  • prezrieť timeline, ak je dostupná
  • Create link: pridanie novej väzby na inú Requirement
  • Edit link: úprava existujúcej väzby Requirement
  • Add Use Case: pripojenie ďalšieho Use Case k Requirement

Stránka Use Case

Účel

Stránku Use Case používajte na refinement jedného Use Case, kontrolu jeho coverage voči Requirements a správu väzieb na súvisiace Use Cases.

Súvisiaci "Flow"

Hlavné akcie

  • kontrolovať original text, final text, prompt template a kontext
  • označiť Use Case bookmarkom na neskôr
  • prejsť na predchádzajúci alebo nasledujúci Use Case v rovnakej Epic z context tree
  • vygenerovať krátky Name z textu Use Case a pokrytých Requirements
  • ukladať zmeny, finalizovať alebo odložiť Use Case
  • keď finalizácia zlyhá, skontrolovať červenú validačnú správu Final text vedľa labelu
  • skopírovať original text do final textu cez Use as final; zmena sa uloží a Use Case sa vráti do stavu draft
  • spustiť Enhance, voliteľne zadať guidance pre AI vylepšenie a kontrolovať enhancement históriu
  • kontrolovať pokryté Requirements a pridávať alebo odoberať coverage väzby
  • kontrolovať súvisiace Test Cases v záložke Test Cases, keď sú zapnuté Test Case capabilities
  • navrhovať, schvaľovať, zamietať a vytvárať Use Case links typu závislosť alebo konflikt
  • prezrieť podobné Use Cases v záložke Semantics, ak je dostupná
  • prezrieť timeline, ak je dostupná
  • Add Requirement: pripojenie ďalšej Requirement k Use Case
  • Create link: pridanie novej väzby na iný Use Case

Stránka Test Case

Účel

Stránku Test Case používajte na refinement jedného Test Case, kontrolu zdrojového Use Case, prepojených Requirements a súvisiacich Test Cases.

Hlavné akcie

  • kontrolovať original text a final text v rovnakom voľnom tele Test Case, ktoré používa AI generovanie
  • označiť Test Case bookmarkom na neskorší follow-up
  • prejsť na predchádzajúci alebo nasledujúci Test Case v rovnakej Epic z context tree
  • uložiť final text alebo finalizovať Test Case
  • keď finalizácia zlyhá, skontrolovať červenú validačnú správu Final text vedľa labelu
  • skopírovať original text do final textu cez Use as final; zmena sa uloží a Test Case sa vráti do stavu draft
  • kontrolovať prepojené Requirements a zdrojový Use Case v Requirements
  • navrhnúť AI klasifikované závislosti alebo konflikty medzi Test Cases zo semantických kandidátov v záložke Links a potom návrhy schváliť alebo zamietnuť skôr, než sa stanú potvrdenými vzťahmi v grafe
  • pridať potvrdené závislosti alebo konflikty medzi Test Cases manuálne v záložke Links
  • prezrieť semanticky podobné Test Cases z embeddings indexu v Semantics
  • spustiť Enhance, voliteľne zadať guidance a zaradiť bilingválne generovanie final textu podľa Test Case formátu a potom kontrolovať formátovanú históriu enhancementov s promptom, modelom a Use as final; vygenerovaný text sa skopíruje do final textu až po výbere Use as final
  • prezrieť posledné udalosti Test Case v Timeline, filtrovať human, AI, linkové alebo statusové aktivity a rozbaliť Details pri udalostiach, ktoré majú detailný payload