zisky:
- Schopnost rozlišovat funkční a nefunkční požadavky a psát jasné, měřitelné výrazy požadavků s podporou umělé inteligence
- Schopnost používat umělou inteligenci se strukturovanými výzvami k extrahování uživatelského příběhu, kritérií přijetí a omezení rozsahu z poznámek k rozhovoru
- Zvyknout si kontrolovat požadavky generované AI na nejednoznačnost, rozpory a chybějící pravidla a potvrzovat je se zúčastněnými stranami
Úkolem analýzy požadavků je úplným, jasným a ověřitelným způsobem definovat, co by měl systém dělat. Je to jedna z fází, kde specialista MIS produkuje největší hodnotu; protože chyba zde exponenciálně narůstá na konci projektu. Existují dva základní typy analýzy požadavků. Funkční požadavek popisuje práci, kterou by měl systém dělat: „Systém by měl zákazníkovi poslat e-mail, když potvrdí objednávku.“ Nefunkční požadavek popisuje, jaký by měl být systém: vlastnosti jako výkon, bezpečnost, použitelnost a dostupnost. "Obrazovka zprávy by se měla otevřít za méně než 2 sekundy při průměrné zátěži" je nefunkční požadavek.
Dobrý požadavek má tři vlastnosti: je jasný (má jedinou interpretaci), je měřitelný (má testovatelný práh) a je sledovatelný (je jasné, z jaké obchodní potřeby pochází). "Systém musí být rychlý" nesplňuje nic z toho; „rychlý“ je subjektivní, nelze jej měřit, nelze jej testovat. V této fázi je umělá inteligence mocným pomocníkem při navrhování požadavků a zachycení nejednoznačných formulací; ale pouze zainteresovaná strana rozhoduje, které obchodní pravidlo je skutečné.
Uživatelský příběh a kritéria přijetí
Běžným formátem při psaní moderních požadavků je uživatelský příběh: „Jako [role], pro [účel] chci [funkci].“ Příklad: "Jako obchodní zástupce chci kalkulaci slevy z obrazovky mobilního telefonu, abych mohl rychle vytvářet nabídky v terénu." Příběh je krátký a orientovaný na obchod; Neukládá technické řešení.
Každý příběh by měl mít kritéria přijatelnosti: testovatelné podmínky, které musí být splněny, aby byl příběh považován za „ok“. Často používaným vzorem je vzor "Given/When/Then": "Given: zákazník je ve VIP segmentu. Když: objedná nad 10 000 TL. Pak: systém uplatní 5% slevu." Tento vzor eliminuje nejednoznačnost, protože jasně spojuje podmínku a očekávaný výsledek.
Tip: Při psaní uživatelského příběhu do umělé inteligence nezapomeňte říci „vygenerujte pro každý příběh alespoň 2 kritéria přijetí ve formátu Dan/kdy/pak“. Když je model nucen vytvářet benchmarky, skryté mezery v požadavcích se stanou viditelnými.
Krok za krokem: Extrakce požadavků za pomoci AI
Krok 1 — Sbírejte nezpracovaný vstup. Záznamy hovorů, e-maily, existující snímky obrazovky, seznamy stížností. Čím více skutečných vstupů, tím méně výmyslů.
Krok 2 — Extrahujte první sadu příběhů. Poskytněte umělé inteligenci hrubé vstupy a nechte ji vytvořit návrhy uživatelských příběhů. Tento krok není úplný seznam, ale první krok.
Krok 3 — Přidejte kritéria přijetí. Vygenerujte kritéria Dan/kdy/pak pro každý příběh. Příběh, pro který nelze vytvořit kritéria, ve skutečnosti znamená, že není dostatečně definován.
Krok 4 — Hledání rozporů a mezer. Zeptejte se AI: „Existují mezi těmito požadavky nějaké rozpory, duplikace nebo nedefinované situace? Zeptejte se a nechte si to zkontrolovat. Filtrujte výsledek jako člověk.
Krok 5 — Stanovte prioritu a potvrďte. Upřednostňujte příběhy se zúčastněnými stranami na základě obchodní hodnoty a naléhavosti. Prioritní rozhodnutí náleží obchodní jednotce, nikoli AI.
Nezapomeňte na nefunkční požadavky
Většina projektů má problémy v oboru, protože při psaní funkčních požadavků zapomíná na ty nefunkční. Zpráva může fungovat „správně“, ale pokud její otevření trvá 45 sekund, nikdo ji nepoužije. Následující tabulka ukazuje běžně přehlížené typy nefunkčních požadavků a měřitelné příklady psaní.
Žánr
špatný výraz
měřitelný výraz
Výkon
"Musí být rychlý"
"Odpověď na dotaz < 2 s při průměrném zatížení"
dostupnost
"Každý by to měl umět používat"
"WCAG 2.1 AA kompatibilní; plná navigace pomocí klávesnice"
Bezpečnost
"Mělo by to být bezpečné"
"Osobní data jsou v klidu šifrována; přístup je založen na rolích"
dostupnost
"Mělo by to být snadné"
"Nový uživatel dokončí objednávku ve 3 krocích bez školení"
Dostupnost/kontinuita
"Nemělo by se zřítit"
"Měsíční dostupnost ≥ 99,5 %"
Tři mini případy: Podle čísel
Případ 1 — Cena neměřitelné potřeby. Obrazovka, která byla vyvinuta v bance s požadavkem, aby se „obrazovka hlášení rychle otevřela“, se při zatížení v terénu otevřela za 22 sekund. Vývojář si myslel, že ve svém prostředí poskytuje slovo „rychlý“ (2 sekundy). Pokud by byl požadavek zapsán jako „< 3 sekundy ve špičce, skutečná propustnost“, problém by byl zachycen při testování. Přestavba stála 3 týdny a měřitelné dodatečné náklady.
Případ 2 – Mezera zachycená kritérii přijatelnosti. Při psaní kritérií přijetí pro příběh „systém uplatňuje slevu“ v projektu elektronického obchodování si zúčastněná strana všimla, že se vůbec nediskutovalo o tom, co by se stalo, kdyby sleva byla v rozporu s kupónem a VIP slevou. Jediná otázka Dáno/kdy/pak zabránila chybě dvojité slevy před spuštěním; Tato chyba způsobila u podobných projektů vážnou ztrátu příjmů.
Případ 3 – pravidlo vytvořené AI. V HR projektu přidala AI do návrhu požadavků větu „žádost o dovolenou je automaticky schválena do 24 hodin“. Na schůzi se o takovém automatickém schválení nemluvilo; Model vytvořil pravidlo, které se zdálo „rozumné“. Vedle každého požadavku odborník napíše „zdroj: který rozhovor/dokument?“ Přidáním sloupce odstranil 4 nezdrojované věty.
Slabá výzva / Silná výzva
Slabá výzva:
Napište uživatelské příběhy pro tento projekt.
Výkonná výzva:
Vaše role: Jste obchodním analytikem MIS. Vytáhněte uživatelské příběhy z poznámky k rozhovoru níže.Pravidla:- Formát: „Jako [role], pro [účel], chci [funkci].“- Napište ALESPOŇ 2 kritéria přijetí pro každý příběh ve formátu Dan/Kdy/Potom.- Přidejte sloupec „Zdroj“ vedle každého příběhu:- která věta není jasná [označení nepochází z textu] poznámka; kování.- Měřitelné nefunkční požadavky (výkon, bezpečnost, dostupnost) napište do samostatné sekce. Poznámka k rozhovoru: [text]
Výkonná výzva prosazuje formát příběhu, kritéria přijetí, sledovatelnost zdroje a nefunkční požadavky najednou; To usnadňuje ovládání výstupu.
Čtyři kopírovatelné šablony
1) Vyjasnění požadavků:
Zkontrolujte níže uvedený požadavek. Označte každé tvrzení, které je vágní, nesouměřitelné nebo otevřené více než jedné interpretaci, a ke každému napište upřesňující otázku. Nevymýšlej odpověď. Požadavek: [text]
2) Skenování protikladů:
V níže uvedeném seznamu požadavků najděte položky, které si odporují, opakují se nebo ponechávají logické mezery. Oznamte každý nález s čísly položek a zdůvodněním jednou větou. Seznam: [text]
3) Generování kritérií přijetí:
Napište alespoň 4 kritéria přijetí pro následující uživatelský příběh ve formátu Dan/kdy/pak, včetně limitních a výjimečných případů. Uveďte také všechny body, které zůstávají nejasné. Příběh: [text]
4) Popis rozsahu:
Navrhněte položky "V rozsahu" a "Mimo rozsah" jako dvousloupcovou tabulku podle následujících požadavků. U každé položky, kterou si nejste jisti, označte [POTVRZENÍ VYŽADOVÁNO]. Požadavky: [text]
Časté chyby
- Myslet na řešení je potřeba. "Přidat rozbalovací nabídku" je řešení, nikoli požadavek. Požadavek říká „uživatel musí mít možnost vybrat zemi z definovaného seznamu“; IT tým navrhne řešení.
- Přeskakování těch nefunkčních. Pouhé zapsání „co dělat“ a zapomenutí „jak být“ (rychlost, bezpečnost, dostupnost) je nejčastější a nejdražší mezera.
- Používání nezměrných přídavných jmen. Slova jako „rychlý, snadný, bezpečný, uživatelsky přívětivý“ jsou bez prahu neplatná.
- Nevšímat si pravidla, které AI vymyslela. Model může přidat „rozumná“, ale ne skutečně vyslovená pravidla; Požádejte o zdroje pro každou potřebu.
- Ponechání priorit na AI. Co udělat jako první, je rozhodnutí o obchodní hodnotě; Obchodní jednotka to dává.
Pozor: Nejnebezpečnější věta v analýze požadavků je „to už všichni vědí“. Nevyslovené předpoklady se nedostanou do dokumentace, nikdy se nedostanou do kódu a objeví se v terénu. Zeptejte se AI: „Co se v tomto požadavku předpokládá, ale není napsáno? zviditelní tyto skryté předpoklady.
V souhrnu
Analýza požadavků definuje, co by měl systém dělat jasným, měřitelným a sledovatelným způsobem. Funkční požadavky popisují práci, nefunkční požadavky popisují kvality a na ty druhé se často zapomíná. Příběh uživatele a kritéria přijetí Dan/kdy/pak jsou mocnými nástroji, které eliminují nejistotu. Umělá inteligence výrazně urychluje produkci storyboardů, akceptačních kritérií, odhalování konfliktů a vyjasňování otázek; Za správnost obchodního pravidla, rozsah a prioritní rozhodnutí a zdroj každé věty však odpovídá člověk. Nedokončujte žádný požadavek, který je nezdrojovaný a neměřitelný.
Aplikační úkol
Napište jednoodstavcový obchodní požadavek na imaginární „online systém schůzek“ (např. „Klienti by měli mít možnost sjednávat schůzky online, zaměstnanci by měli mít možnost vidět kalendáře“). (1) Vytvořte alespoň 5 uživatelských příběhů a 2 kritéria přijetí pro každý se silnou výzvou z tohoto požadavku. (2) Najděte alespoň 2 skryté mezery v kritériích vytvořených modelem (např. dvojitá schůzka ve stejnou dobu, pravidlo zrušení). (3) Zahrňte alespoň 3 nefunkční požadavky v měřitelné podobě. (4) Označte alespoň 3 položky jako „Mimo rozsah“. (5) Označte pravidlo, které si model mohl vymyslet, a napište, jak byste jej potvrdili.
kontrolní seznam
- [ ] Napsal jsem zvlášť funkční a nefunkční požadavky.
- [ ] Každý požadavek je jasný, měřitelný a testovatelný.
- [ ] Každý příběh má kritéria přijetí Dan/kdy/pak.
- [ ] Dokážu dohledat zdroj (konverzaci/dokument) každého požadavku.
- [ ] Označil jsem možná pravidla, která AI vymyslela, a nechal je pro potvrzení.
- [ ] Stanovení priorit jsem provedl společně s obchodní jednotkou.