Nyereség:
- Képes a funkcionális és a nem funkcionális követelmények megkülönböztetésére, valamint világos, mérhető követelménykifejezések írására mesterséges intelligencia támogatásával
- Lehetőség mesterséges intelligencia használatára strukturált promptokkal a felhasználói történet, az elfogadási kritériumok és a terjedelmi korlát kinyerésére az interjúk jegyzeteiből
- A mesterséges intelligencia által generált követelmények kétértelműség, ellentmondás és hiányzó szabályok ellenőrzésének megszokása, és ezek megerősítése az érdekelt felekkel
A követelményelemzés az a feladata, hogy teljes, világos és ellenőrizhető módon meghatározza, mit kell tennie egy rendszernek. Ez az egyik szakasz, ahol az MIS szakember a legtöbb értéket produkálja; mert itt egy hiba a projekt végén exponenciálisan nő. A követelményelemzésnek két alapvető típusa van. A funkcionális követelmény leírja azt a munkát, amelyet a rendszernek el kell végeznie: „A rendszernek e-mailt kell küldenie az ügyfélnek, amikor visszaigazolja a rendelést.” A nem funkcionális követelmény leírja, hogy milyennek kell lennie a rendszernek: olyan tulajdonságokkal, mint a teljesítmény, a biztonság, a használhatóság és a hozzáférhetőség. "A jelentés képernyőjének átlagos terhelésnél kevesebb mint 2 másodpercen belül meg kell nyílnia" nem funkcionális követelmény.
A jó követelménynek három jellemzője van: egyértelmű (egyetlen értelmezése van), mérhető (tesztelhető küszöbértéke van), és nyomon követhető (egyértelmű, hogy milyen üzleti igényből származik). „A rendszernek gyorsnak kell lennie” ezek egyikének sem felel meg; A „gyors” szubjektív, nem mérhető, nem tesztelhető. Ebben a szakaszban a mesterséges intelligencia hatékony segítséget nyújt a követelmények megfogalmazásában és a kétértelmű megfogalmazások megragadásában; de csak az érintett dönti el, hogy melyik üzleti szabály valós.
Felhasználói történet és elfogadási feltételek
A modern követelményírásban elterjedt formátum a felhasználói történet: "[szerepként], [cél]ként [funkciót] szeretnék." Példa: "Értékesítési képviselőként kedvezményszámítást szeretnék a mobil képernyőjén, hogy gyorsan árajánlatokat tudjak tenni a terepen." A történet rövid és üzletközpontú; Nem ír elő műszaki megoldást.
Minden történetnek rendelkeznie kell elfogadási kritériumokkal: tesztelhető feltételekkel, amelyeknek teljesülniük kell ahhoz, hogy a történetet „rendnek” tekintsék. Egy gyakran használt minta az "Adott/Akkor/Akkor" minta: "Adott: a vásárló a VIP szegmensben van. Mikor: 10.000 TL feletti rendelés. Ekkor: 5% kedvezményt alkalmaz a rendszer." Ez a minta kiküszöböli a kétértelműséget, mert egyértelműen összekapcsolja a feltételt és a várt eredményt.
Tipp: Amikor felhasználói történetet ír a mesterséges intelligenciának, feltétlenül mondja ki, hogy „minden történethez legalább 2 elfogadási feltételt Adva/Mikor/Akkor formátumban generáljon”. Amikor a modellt benchmarkok előállítására kényszerítik, a követelmény rejtett hiányosságai láthatóvá válnak.
Lépésről lépésre: AI-asszisztált követelmények kivonása
1. lépés – Nyers bemenet gyűjtése. Hívásnaplók, e-mailek, meglévő képernyőképek, panaszlisták. Minél több valós input, annál kevesebb gyártás.
2. lépés – Bontsa ki az első történetkészletet. Adjon nyers inputot a mesterséges intelligenciának, és készíttesse el a felhasználói történetvázlatokat. Ez a lépés nem egy teljes lista, hanem az első lépés.
3. lépés – Adjon hozzá elfogadási feltételeket. Generáljon Adott/Mikor/Akkor kritériumokat minden történethez. Az a történet, amelyhez nem lehet kritériumokat felállítani, valójában azt jelenti, hogy nincs kellően definiálva.
4. lépés – Ellentmondások és hiányosságok keresése. Kérdezd meg a mesterséges intelligencia „vannak-e ellentmondások, párhuzamosságok vagy meghatározatlan helyzetek e követelmények között?” Kérdezz és ellenőriztesd. Szűrje le az eredményt emberként.
5. lépés – A prioritások meghatározása és megerősítése. Az érdekelt felekkel folytatott történetek prioritása az üzleti érték és a sürgősség alapján. Az elsőbbségi döntés az üzleti egységé, nem az AI-é.
Ne felejtse el a nem funkcionális követelményeket
A legtöbb projektnek nehézségei vannak a területen, mert a funkcionális követelmények írása közben elfelejtik a nem funkcionálisakat. Lehet, hogy egy jelentés „helyesen működik”, de ha 45 másodpercig tart a megnyitás, senki sem fogja használni. A következő táblázat a gyakran figyelmen kívül hagyott nem funkcionális követelménytípusokat és mérhető írási példákat mutatja be.
Műfaj
rossz kifejezés
mérhető kifejezés
Teljesítmény
"Gyorsnak kell lennie"
"A lekérdezés válasza < 2 mp átlagos terhelésnél"
hozzáférhetőség
"Mindenkinek tudnia kell használni"
"WCAG 2.1 AA kompatibilis; teljes billentyűzetes navigáció"
Biztonság
"Biztonságosnak kell lennie"
"A személyes adatok nyugalmi állapotban titkosítva vannak; a hozzáférés szerepkör alapú"
elérhetősége
"Könnyűnek kell lennie"
"Az új felhasználó 3 lépésben, képzés nélkül teljesíti a megrendelést"
Elérhetőség/folytonosság
"Nem szabad lezuhanni"
"Havi üzemidő ≥ 99,5%"
Három mini tok: a számok szerint
1. eset – Egy mérhetetlen szükséglet ára. A képernyő, amelyet egy bankban fejlesztettek ki azzal az előírással, hogy "a jelentés képernyő gyorsan nyíljon", terepi terhelés alatt 22 másodperc alatt nyílt meg. A fejlesztő úgy gondolta, hogy a "gyors" szót adja a környezetében (2 másodperc). Ha a követelményt úgy írták volna, hogy "< 3 mp csúcsidőben, tényleges átviteli sebesség", akkor a probléma a tesztelés során elakadt volna. Az átépítés 3 hétbe került és mérhető többletköltség.
2. eset – Az elfogadási kritériumok által rögzített hiányosság. Egy e-kereskedelmi projektben a "rendszer kedvezményt alkalmaz" sztori elfogadási feltételeinek megírása közben az érintett észrevette, hogy egyáltalán nem került szóba, hogy mi lesz, ha a kedvezmény ütközik a kuponnal és a VIP-kedvezménnyel. Egyetlen Adott/Mikor/Akkor kérdés megakadályozta a dupla engedményhibát az életbe lépés előtt; Ez a hiba komoly bevételkiesést okozott hasonló projekteknél.
3. eset – MI által készített szabály. Egy HR-projektben az AI kiegészítette a követelménytervezethez azt a mondatot, hogy „a szabadságkérelmet 24 órán belül automatikusan jóváhagyják”. Az ülésen nem esett szó ilyen automatikus jóváhagyásról; A modell olyan szabályt alkotott, amely „ésszerűnek” tűnt. Minden követelmény mellé a szakértő azt írja, hogy „forrás: melyik interjú/dokumentum?” Az oszlop hozzáadásával 4 forrás nélküli mondatot távolított el.
Gyenge felszólítás / Erős felszólítás
Gyenge felszólítás:
Írjon felhasználói történeteket ehhez a projekthez.
Erőteljes felszólítás:
Az Ön szerepe: Ön az MIS üzleti elemzője. Vonja ki a felhasználói történeteket az alábbi interjújegyzetből. Szabályok:- Formátum: „[szerepként], [cél]ként [funkciót] szeretnék.”- Írjon LEGALÁBB 2 elfogadási feltételt minden történethez Adott/Mikor/Akkor formátumban.- Adjon hozzá egy „Forrás” oszlopot minden történet mellé. jegyzet; illesztés.- A mérhető, nem funkcionális követelményeket (teljesítmény, biztonság, hozzáférhetőség) külön rovatba írja be! Interjú megjegyzés:[text]
Az erőteljes prompt egyszerre érvényesíti a történetformátumot, az elfogadási feltételeket, a forrás nyomon követhetőségét és a nem funkcionális követelményeket; Ez megkönnyíti a kimenet szabályozását.
Négy másolható sablon
1) Követelmények pontosítása:
Tekintse át az alábbi követelményt. Jelöljön meg minden olyan állítást, amely homályos, összemérhetetlen vagy több értelmezésre alkalmas, és mindegyikhez írjon egy tisztázó kérdést. Ne találd ki a választ. Követelmény: [szöveg]
2) Ellentmondás szkennelés:
Az alábbi követelménylistában keresse meg az egymásnak ellentmondó, ismétlődő vagy logikai hézagokat hagyó elemeket. Minden megállapítást tételszámmal és egy mondatos indoklással számoljon be. Lista: [szöveg]
3) Elfogadási feltételek generálása:
Írjon legalább 4 elfogadási feltételt a következő felhasználói történethez Adott/Mikor/Akkor formátumban, beleértve a limit- és kivételes eseteket is. Sorolja fel azokat a pontokat is, amelyek még tisztázatlanok. Történet: [szöveg]
4) A hatókör vázlata:
Az alábbi követelményeknek megfelelően kétoszlopos táblázatként fogalmazza meg a „Hatályon kívül” és „Hatáskörön kívül” elemeket. Minden olyan elemnél jelölje meg a [MEGERŐSÍTÉS SZÜKSÉGES] címkét, amelyben nem biztos. Követelmények: [szöveg]
Gyakori hibák
- A megoldáson való gondolkodás szükségszerű. A "legördülő menü hozzáadása" megoldás, nem követelmény. A követelmény szerint "a felhasználónak ki kell tudnia választani az országot a definiált listából"; Az IT csapat megtervezi a megoldást.
- A nem működőképesek kihagyása. Egyszerűen fel kell írni, hogy „mit tegyünk”, és elfelejtjük „hogyan kell lenni” (sebesség, biztonság, hozzáférhetőség) a leggyakoribb és legdrágább kiskapu.
- Mérhetetlen melléknevek használata. Az olyan szavak, mint a „gyors, egyszerű, biztonságos, felhasználóbarát”, küszöbérték nélkül érvénytelenek.
- Nem veszi észre a szabályt, amit az AI alkotott. A modell hozzáadhat „ésszerű”, de valójában nem kimondott szabályokat; Minden igényhez kérjen forrást.
- A rangsorolást az AI-ra hagyva. Az első lépés az üzleti érték döntése; Az üzletág ezt adja.
Vigyázat: A követelményelemzés legveszélyesebb mondata az "ezt már mindenki tudja". A kimondatlan feltételezések nem kerülnek be a dokumentációba, soha nem kerülnek be a kódba, és a terepen jelennek meg. Kérdezd meg az AI-t, hogy „mi feltételezhető, de nincs leírva ebben a követelményben?” láthatóvá teszi ezeket a rejtett feltételezéseket.
Összefoglalva
A követelményelemzés világosan, mérhetően és nyomon követhetően határozza meg, hogy mit kell tennie a rendszernek. A funkcionális követelmények a munkakört, a nem funkcionális követelmények a tulajdonságokat írják le, és ez utóbbit gyakran elfelejtik. A felhasználói történet és az Adott/Mikor/Akkor elfogadási kritériumok hatékony eszközök, amelyek kiküszöbölik a bizonytalanságot. A mesterséges intelligencia jelentősen felgyorsítja a storyboardok, az elfogadási kritériumok, a konfliktusfelismerés és a kérdések tisztázása elkészítését; Az üzletszabály helyessége, a terjedelem és az elsőbbségi döntés, valamint az egyes mondatok forrása azonban az ember felelőssége. Ne véglegesítsen semmilyen forrás nélküli és mérhetetlen követelményt.
Pályázati feladat
Írjon egy egy bekezdésből álló üzleti kérelmet egy képzeletbeli „online időpontegyeztetési rendszerre” (pl. „Az ügyfeleknek online kell időpontot egyeztetniük, a személyzetnek látnia kell a naptárakat”). (1) Hozzon létre legalább 5 felhasználói történetet és mindegyikhez 2 elfogadási feltételt a kérésből származó erőteljes felszólítással. (2) Keressen legalább 2 rejtett hiányosságot a modell által előállított kritériumok között (pl. kettős kinevezés egyidejűleg, törlési szabály). (3) Legalább 3 nem funkcionális követelményt tartalmazzon mérhető formában. (4) Határozzon meg legalább 3 elemet, mint „nem hatályos”. (5) Jelöljön meg egy szabályt, amelyet a modell kitalált, és írja le, hogyan erősítené meg!
ellenőrző lista
- [ ] A funkcionális és a nem funkcionális követelményeket külön írtam.
- [ ] Minden követelmény világos, mérhető és tesztelhető.
- [ ] Minden történetnek vannak Adva/Akkor/Akkor elfogadási kritériumai.
- [ ] Az egyes követelmények forrását (beszélgetés/dokumentum) nyomon tudom követni.
- [ ] Megjelöltem a lehetséges szabályokat, amelyeket az AI kitalált, és hagytam őket megerősítésre.
- [ ] A rangsorolást az üzletággal együtt végeztem.