zisky:
- Schopnosť rozlíšiť funkčné a nefunkčné požiadavky a napísať jasné, merateľné výrazy požiadaviek s podporou umelej inteligencie
- Schopnosť používať umelú inteligenciu so štruktúrovanými výzvami na extrahovanie používateľského príbehu, akceptačných kritérií a limitu rozsahu z poznámok k rozhovorom
- Zvyknite si kontrolovať požiadavky generované AI na nejednoznačnosť, rozpory a chýbajúce pravidlá a potvrdzovať ich so zainteresovanými stranami
Analýza požiadaviek má za úlohu definovať úplným, jasným a overiteľným spôsobom, čo by mal systém robiť. Je to jedna z fáz, v ktorej špecialista MIS produkuje najväčšiu hodnotu; pretože chyba tu rastie exponenciálne na konci projektu. Existujú dva základné typy analýzy požiadaviek. Funkčná požiadavka popisuje prácu, ktorú by mal systém vykonávať: „Systém by mal zákazníkovi poslať e-mail, keď potvrdí objednávku.“ Nefunkčná požiadavka popisuje, aký by mal byť systém: vlastnosti ako výkon, bezpečnosť, použiteľnosť a dostupnosť. "Obrazovka správy by sa mala otvoriť za menej ako 2 sekundy pri priemernom zaťažení" je nefunkčná požiadavka.
Dobrá požiadavka má tri vlastnosti: je jasná (má jedinú interpretáciu), je merateľná (má testovateľný prah) a je vysledovateľná (je jasné, z akej obchodnej potreby pochádza). "Systém musí byť rýchly" nespĺňa nič z toho; „rýchlo“ je subjektívne, nedá sa zmerať, nedá sa otestovať. V tejto fáze je AI silným pomocníkom pri navrhovaní požiadaviek a zachytávaní nejednoznačných formulácií; ale iba zainteresovaná strana rozhoduje, ktoré obchodné pravidlo je skutočné.
Príbeh používateľa a kritériá prijatia
Bežným formátom pri písaní moderných požiadaviek je príbeh používateľa: „Ako [rola], na [účel] chcem [funkciu].“ Príklad: "Ako obchodný zástupca chcem výpočet zľavy z obrazovky mobilu, aby som mohol robiť rýchle cenové ponuky v teréne." Príbeh je krátky a orientovaný na biznis; Neukladá technické riešenie.
Každý príbeh by mal mať kritériá prijatia: testovateľné podmienky, ktoré musia byť splnené, aby bol príbeh považovaný za „ok“. Často používaným vzorom je vzor "Given/When/Then": "Given: zákazník je vo VIP segmente. Keď: objedná nad 10 000 TL. Potom: systém uplatní 5% zľavu." Tento vzor eliminuje nejednoznačnosť, pretože jasne spája stav a očakávaný výsledok.
Tip: Pri písaní používateľského príbehu pre umelú inteligenciu nezabudnite povedať „vygenerujte aspoň 2 akceptačné kritériá vo formáte Dan/Kedy/Potom pre každý príbeh“. Keď je model nútený vytvárať referenčné hodnoty, stanú sa viditeľné skryté medzery v požiadavkách.
Krok za krokom: Extrakcia požiadaviek s pomocou AI
Krok 1 – Zozbierajte nespracovaný vstup. Záznamy hovorov, e-maily, existujúce snímky obrazovky, zoznamy sťažností. Čím viac skutočných vstupov, tým menej výmyslov.
Krok 2 — Extrahujte prvý súbor príbehov. Poskytnite umelej inteligencii surové vstupy a nechajte ju vytvoriť návrhy používateľských príbehov. Tento krok nie je úplný zoznam, ale prvý krok.
Krok 3 – Pridajte kritériá prijatia. Vygenerujte kritériá Dan/Ked/Vtedy pre každý príbeh. Príbeh, pre ktorý nemožno vytvoriť kritériá, v skutočnosti znamená, že nie je dostatočne definovaný.
Krok 4 — Skenovanie proti rozporom a medzier. Opýtajte sa AI: „Existujú nejaké rozpory, duplikácie alebo nedefinované situácie medzi týmito požiadavkami? Opýtajte sa a nechajte si to skontrolovať. Filtrujte výsledok ako človek.
Krok 5 — Stanovte prioritu a potvrďte. Uprednostňujte príbehy so zainteresovanými stranami na základe obchodnej hodnoty a naliehavosti. Prioritné rozhodnutie patrí obchodnej jednotke, nie AI.
Nezabudnite na nefunkčné požiadavky
Väčšina projektov má problémy v teréne, pretože pri písaní funkčných požiadaviek zabúda na tie nefunkčné. Správa môže fungovať „správne“, ale ak jej otvorenie trvá 45 sekúnd, nikto ju nepoužije. Nasledujúca tabuľka zobrazuje bežne prehliadané typy nefunkčných požiadaviek a merateľné príklady písania.
Žáner
zlý výraz
merateľný výraz
Výkon
"Musí byť rýchly"
"Odozva na dopyt < 2 sekundy pri priemernom zaťažení"
prístupnosť
"Každý by to mal vedieť používať"
"WCAG 2.1 AA kompatibilný; úplná navigácia klávesnicou"
Bezpečnosť
"Malo by to byť bezpečné"
"Osobné údaje sú v pokoji šifrované; prístup je založený na rolách"
dostupnosť
"Malo by to byť ľahké"
"Nový používateľ dokončí objednávku v 3 krokoch bez školenia"
Dostupnosť/kontinuita
"Nemal by sa zrútiť"
„Mesačná dostupnosť ≥ 99,5 %“
Tri mini prípady: Podľa čísel
Prípad 1 – Cena nemerateľnej potreby. Obrazovka, ktorá bola vyvinutá v banke s požiadavkou, aby sa „obrazovka správy rýchlo otvorila“, sa pri záťaži v teréne otvorila za 22 sekúnd. Vývojár si myslel, že poskytuje slovo „rýchly“ vo svojom prostredí (2 sekundy). Ak by bola požiadavka napísaná ako "< 3 sekundy v špičkovej hodine, skutočný výkon", problém by bol zachytený pri testovaní. Prestavba stála 3 týždne a merateľné dodatočné náklady.
Prípad 2 – Medzera zachytená kritériami prijatia. Pri písaní kritérií prijatia pre príbeh „systém uplatňuje zľavu“ v projekte elektronického obchodu si zainteresovaná strana všimla, že o tom, čo by sa stalo, keby bola zľava v rozpore s kupónom a VIP zľavou, sa vôbec nehovorilo. Jediná otázka Dan/Ked/Potom zabránila chybe dvojitej zľavy pred spustením; Táto chyba spôsobila vážnu stratu príjmov v podobných projektoch.
Prípad 3 – pravidlo vytvorené AI. V HR projekte pridala AI do návrhu požiadaviek vetu „žiadosť o dovolenku je automaticky schválená do 24 hodín“. O takomto automatickom schválení sa na stretnutí nediskutovalo; Modelka vytvorila pravidlo, ktoré sa zdalo „rozumné“. Vedľa každej požiadavky odborník napíše „zdroj: ktorý rozhovor/dokument?“ Pridaním stĺpca odstránil 4 nezdrojované vety.
Slabá výzva / silná výzva
Slabá výzva:
Napíšte príbehy používateľov pre tento projekt.
Výkonná výzva:
Vaša rola: Ste obchodným analytikom MIS. Extrahujte príbehy používateľov z poznámky k rozhovoru nižšie.Pravidlá:- Formát: „Ako [rola], na [účel], chcem [funkciu].“- Napíšte ASPOŇ 2 kritériá prijatia pre každý príbeh vo formáte Dan/Ked/Vtedy.- Pridajte stĺpec „Zdroj“ vedľa každého príbehu:- ktorá veta nie je jasná [Značka nepochádza z jasného] poznámka; kovanie.- Merateľné nefunkčné požiadavky (výkon, bezpečnosť, dostupnosť) napíšte do samostatnej časti. Poznámka k rozhovoru: [text]
Výkonná výzva presadzuje formát príbehu, akceptačné kritériá, sledovateľnosť zdroja a nefunkčné požiadavky naraz; To uľahčuje ovládanie výstupu.
Štyri kopírovateľné šablóny
1) Objasnenie požiadaviek:
Skontrolujte požiadavku nižšie. Označte každé tvrdenie, ktoré je vágne, nekombinovateľné alebo otvorené viacerým výkladom, a ku každému napíšte objasňujúcu otázku. Nevymýšľaj si odpoveď. Požiadavka: [text]
2) Skenovanie protikladov:
V nižšie uvedenom zozname požiadaviek nájdite položky, ktoré si navzájom odporujú, opakujú sa alebo zanechávajú logické medzery. Oznámte každý nález s číslami položiek a odôvodnením v jednej vete. Zoznam: [text]
3) Generovanie kritérií prijatia:
Napíšte aspoň 4 akceptačné kritériá pre nasledujúci používateľský príbeh vo formáte Dan/Ked/Vtedy, vrátane limitných a výnimočných prípadov. Uveďte aj body, ktoré zostávajú nejasné. Príbeh: [text]
4) Náčrt rozsahu:
Navrhnite položky "V rozsahu" a "Mimo rozsahu" ako tabuľku s dvoma stĺpcami podľa nasledujúcich požiadaviek. Označte [CONFIRMATION REQUIRED] pre každú položku, o ktorej si nie ste istí. Požiadavky: [text]
Časté chyby
- Myslieť na riešenie je potreba. „Pridať rozbaľovaciu ponuku“ je riešenie, nie požiadavka. Požiadavka hovorí, že „používateľ musí mať možnosť vybrať si krajinu z definovaného zoznamu“; IT tím navrhne riešenie.
- Preskakovanie nefunkčných. Jednoduché písanie „čo robiť“ a zabudnutie „ako byť“ (rýchlosť, bezpečnosť, dostupnosť) je najbežnejšou a najdrahšou medzerou.
- Používanie nemerateľných prídavných mien. Slová ako „rýchle, jednoduché, bezpečné, užívateľsky prívetivé“ sú bez prahu neplatné.
- Nevšímajúc si pravidlo, ktoré vytvorila AI. Model môže pridať „rozumné“, ale v skutočnosti nevyslovené pravidlá; Požiadajte o zdroje pre každú potrebu.
- Ponechanie priorít na AI. Čo treba urobiť ako prvé, je rozhodnutie o obchodnej hodnote; To dáva obchodná jednotka.
Pozor: Najnebezpečnejšia veta v analýze požiadaviek je „toto už všetci vedia“. Nevyslovené predpoklady sa nedostanú do dokumentácie, nikdy sa nedostanú do kódu a objavia sa v teréne. Opýtajte sa AI: „Čo sa predpokladá, ale nie je napísané v tejto požiadavke? zviditeľňuje tieto skryté predpoklady.
V súhrne
Analýza požiadaviek definuje, čo by mal systém robiť jasným, merateľným a sledovateľným spôsobom. Funkčné požiadavky popisujú prácu, nefunkčné popisujú kvality a na tie druhé sa často zabúda. Príbeh používateľa a akceptačné kritériá Dan/Ked/Potom sú výkonnými nástrojmi, ktoré eliminujú neistotu. Umelá inteligencia výrazne urýchľuje tvorbu storyboardov, akceptačných kritérií, odhaľovania konfliktov a objasňovania otázok; Za správnosť obchodného pravidla, rozsah a prioritné rozhodnutie a zdroj každej vety je však zodpovedný človek. Nedokončujte žiadnu požiadavku, ktorá nie je zdrojom a je nemerateľná.
Aplikačná úloha
Napíšte jednoodstavcovú obchodnú požiadavku na imaginárny „online systém stretnutí“ (napr. „Klienti by mali mať možnosť dohodnúť si stretnutia online, zamestnanci by mali vidieť kalendáre“). (1) Vytvorte aspoň 5 používateľských príbehov a 2 akceptačné kritériá pre každý so silnou výzvou z tejto požiadavky. (2) Nájdite aspoň 2 skryté medzery v kritériách vytvorených modelom (napr. dvojité stretnutie v rovnakom čase, pravidlo zrušenia). (3) Zahrňte aspoň 3 nefunkčné požiadavky v merateľnej forme. (4) Označte aspoň 3 položky ako „mimo rozsah“. (5) Označte pravidlo, ktoré si model mohol vymyslieť a napíšte, ako by ste ho potvrdili.
kontrolný zoznam
- [ ] Samostatne som písal funkčné a nefunkčné požiadavky.
- [ ] Každá požiadavka je jasná, merateľná a testovateľná.
- [ ] Každý príbeh má kritériá prijatia Dané/Kedy/Vtedy.
- [ ] Viem vysledovať zdroj (rozhovor/dokument) každej požiadavky.
- [ ] Označil som možné pravidlá, ktoré vymyslela AI a nechal som ich na potvrdenie.
- [ ] Stanovenie priorít som robil spolu s obchodnou jednotkou.