A könyv leír egy módszert a problémafelvetés egy részének írására, nevezetesen a használati eset módszert.
Ami? Ez a felhasználói interakciós forgatókönyv leírása a rendszerrel (vagy a vállalkozással). Ebben az esetben a rendszer fekete dobozként működik (és ez lehetővé teszi a komplex tervezési feladat felosztását interakció tervezésére és ennek biztosítására). Ezzel egyidejűleg jelölési szabványokat vezetnek be, amelyek biztosítják a könnyű olvashatóságot, beleértve a nem résztvevők számára is, valamint lehetővé teszik a teljesség és az érintett céljainak való megfelelés bizonyos ellenőrzését.
Használjon esetpéldát
Hogyan néz ki a forgatókönyv a webhelyen e-mailben történő engedélyezés példájával:
(Rendszer) Jelentkezzen be a webhelyre, hogy hozzáférjen személyes fiókjához. ~~ (tengerszint)
Kontextus: A jogosulatlan ügyfél bejelentkezik az oldalra, így az oldal felismeri őt, és személyes adatokat jelenít meg számára: böngészési előzményeket, vásárlási előzményeket, aktuális bónuszpontok számát stb., bejelentkezésként e-mailt használva.
szint: felhasználói cél
Főszereplő: ügyfél (webáruházunk látogatója)
Hatály: Ügyfél interakciója az online áruház weboldalával
Érintettek és érdekek:
- a marketingszakember azt akarja, hogy a webhely látogatóinak maximális számát azonosítsák a személyes levelek nagyobb lefedettsége érdekében,
- a biztonsági szakember biztosítani kívánja, hogy ne kerüljön sor a látogató személyes adataihoz való jogosulatlan hozzáférésre, ideértve egy fiók jelszavának kitalálását, vagy gyenge jelszóval rendelkező fiók keresését,
- a támadó hozzá akar jutni az áldozat bónuszaihoz,
- a versenytársak negatív véleményeket szeretnének hagyni a termékekről,
- A botnet meg akarja szerezni az áruház vevőkörét, és egy támadás segítségével működésképtelenné akarja tenni az oldalt.
Előfeltételek: a látogatót nem szabad engedélyezni.
Minimális garanciák: a látogató tudni fogja, hogy az engedélyezési kísérlet sikeres volt-e vagy sikertelen.
A siker garanciái: a látogató jogosult.
Fő forgatókönyv:
- Az ügyfél kezdeményezi az engedélyezést.
- A rendszer megerősíti, hogy az ügyfél nem jogosult, és nem lépi túl az adott munkamenetből származó sikertelen engedélyezési kísérletek számát (gyenge jelszó keresése több fiókhoz) a „23. számú biztonsági szabály” szerint.
- A rendszer növeli az engedélyezési kísérletek számának számlálóját.
- A rendszer megjelenít egy engedélyezési űrlapot az ügyfélnek.
- Az ügyfél megadja e-mail címét és jelszavát.
- A rendszer megerősíti az ilyen e-mail-címmel rendelkező ügyfél jelenlétét a rendszerben, valamint azt, hogy a jelszó megegyezik, és a fiókba történő bejelentkezési kísérletek száma nem lépi túl a „24. számú biztonsági szabály” szerint.
- A rendszer engedélyezi az ügyfelet, hozzáadja a munkamenet böngészési előzményeit és kosarát az ügyfélfiók utolsó munkamenetéhez.
- A rendszer megjelenít egy engedélyezési sikeres üzenetet, és áttér arra a szkriptlépésre, amelynél az ügyfél engedélyezése megszakadt. Ebben az esetben az oldalon lévő adatok újratöltése a személyes fiókadatok figyelembevételével történik.
Kiterjesztések:
2.a. Az ügyfél már jogosult:
2.a.1. A rendszer értesíti az ügyfelet a korábban végrehajtott engedélyezés tényéről, és felajánlja, hogy vagy megszakítja a szkriptet, vagy ugorjon a 4. lépésre, és ha a 6. lépés sikeresen befejeződött, akkor a 7. lépést pontosítással hajtja végre:
2.a.7. A rendszer deaktiválja az ügyfelet a régi fiók alatt, engedélyezi az ügyfelet az új fiók alatt, miközben ezen interakciós munkamenet böngészési előzményei és kosara a régi fiókban marad, és nem kerül át az újba. Ezután folytassa a 8. lépéssel.
2.b Az engedélyezési kísérletek száma meghaladta a „23. számú biztonsági szabály” szerinti küszöbértéket:
2.b.1 Folytassa a 4. lépéssel, és egy captcha is megjelenik az engedélyezési űrlapon
2.b.6 A rendszer megerősíti a helyes captcha bevitelt
2.b.6.1 A Captcha hibásan lett beírva:
2.b.6.1.1. a rendszer megnöveli a sikertelen engedélyezési kísérletek számát ennél a fióknál is
2.b.6.1.2. a rendszer hibaüzenetet jelenít meg, és visszatér a 2. lépéshez
6.a. Nem található fiók ezzel az e-mail-címmel:
6.a.1 A rendszer egy hibaüzenetet jelenít meg, és felkínálja a választás lehetőségét, hogy a 2. lépésre lép, vagy a „Felhasználói regisztráció” forgatókönyvre lép, és elmenti a megadott e-mailt,
6.b. Az ehhez az e-mailhez tartozó fiók jelszava nem egyezik a megadottal:
6.b.1 A rendszer növeli a sikertelen bejelentkezési kísérletek számát ehhez a fiókhoz.
6.b.2 A rendszer hibaüzenetet jelenít meg, és felkínálja a választást, hogy a „Jelszó-helyreállítás” forgatókönyvre lép, vagy a 2. lépésre.
6.c: A fiók bejelentkezési kísérletszámlálója túllépte a „24. számú biztonsági szabály” küszöbértékét.
6.c.1 A rendszer üzenetet jelenít meg a fiókba való bejelentkezés letiltására vonatkozóan X percre, és továbblép a 2. lépésre.
Mi a nagyszerű
Ellenőrzi a teljességet és a céloknak való megfelelést, vagyis egy másik elemzőnek adhat követelményeket ellenőrzésre, így kevesebb hibát követ el a probléma megfogalmazásának szakaszában.
A fekete doboz típusú rendszerrel való munka lehetővé teszi, hogy elkülönítse az automatizálandó fejlesztést és a megrendelővel történő egyeztetést a megvalósítási módoktól.
Ez része az elemzői útnak, a használhatóság egyik fő része. A felhasználó forgatókönyve határozza meg mozgásának főbb útjait, ami nagymértékben csökkenti a tervező és a megrendelő választási szabadságát, és elősegíti a tervezési fejlesztés gyorsaságát.
Nagyon örülök annak a helynek a leírásban, ahol az egyes interakciós lépések alól kivételek találhatók. Egy teljes informatikai rendszernek biztosítania kell valamilyen kivételkezelést, hol manuálisan, hol automatikusan (mint a fenti példában).
A tapasztalatok azt mutatják, hogy az átgondolatlan kivételkezelés könnyen borzasztóan kényelmetlen rendszerré változtathat egy rendszert. Emlékszem arra a történetre, amikor a szovjet időkben ahhoz, hogy döntést hozz, több jóváhagyást kellett beszerezni a különböző szolgálatoktól, és milyen fájdalmas, amikor az utolsó szolgáltatás azt mondja - de rossz néven van a kérelmed, vagy valami más hiba a írásjeleket, mindent újra és mindent újra koordinál.
Gyakran találkozom olyan helyzetekkel, amikor a kivételekre átgondolatlan rendszer működési logikája jelentős átdolgozást igényelt a rendszeren. Emiatt az elemzői munka oroszlánrészét kivételkezelésre fordítják.
A szöveges jelölés a diagramokkal ellentétben több kivétel azonosítását és lefedését teszi lehetővé.
Kiegészítés a módszerhez a gyakorlatból
A használati eset a felhasználói történettel ellentétben nem önállóan priorizált része az utasításnak.
A fenti forgatókönyvben vegye figyelembe a „6.a. Ezzel az e-mail-címmel nem található fiók.” és a következő lépés: „6.a.1 A rendszer hibaüzenetet jelenít meg, és továbblép a 2. lépésre.” Milyen negatív dolgok maradtak a színfalak mögött? Az ügyfél számára minden megtérülés egyenértékű azzal, hogy az adatbevitellel végzett összes munka a szeméttelepre kerül. (Csak nem látszik a forgatókönyvben!) Mit lehet tenni? Építse újra a szkriptet, hogy ez ne forduljon elő. Lehetséges ezt megtenni? Példaként megtekintheti a Google engedélyezési szkriptjét.
Forgatókönyv optimalizálás
A könyv beszél a formalizálásról, de keveset mond az ilyen forgatókönyvek optimalizálásának módszereiről.
De lehetőség van a módszer megerősítésére a forgatókönyvek optimalizálásával, és a használati esetek formalizálási módszere ezt lehetővé teszi. Pontosabban, minden előforduló kivételt át kell gondolnia, meg kell határoznia az okot, és újra kell építenie a szkriptet, hogy megszabaduljon a kivételtől, vagy minimalizálja az ügyfél útját.
Az online áruházból történő rendelés leadásakor meg kell adnia a szállítási várost. Előfordulhat, hogy az üzlet nem tud árut kiszállítani a megrendelő által választott városba, mert oda nem szállít, méretkorlátozás, vagy a megfelelő raktár áruhiánya miatt.
Ha egyszerűen leírjuk az interakció forgatókönyvét a regisztrációs szakaszban, akkor azt írhatjuk, hogy „tájékoztassa az ügyfelet, hogy a szállítás lehetetlen, és felajánlja a város vagy a kosár tartalmának megváltoztatását” (és sok kezdő elemző megáll itt). De ha sok ilyen eset van, akkor a forgatókönyv optimalizálható.
Az első dolog, amit meg kell tennie, hogy csak azt a várost válassza ki, ahol szállítani tudunk. Mikor kell ezt megtenni? Mielőtt kiválasztana egy terméket a webhelyen (város automatikus felismerése IP-n keresztül, pontosítással).
Másodszor, csak azon áruk közül kell választani, amelyeket ki tudunk szállítani az ügyfélnek. Mikor kell ezt megtenni? A kiválasztás pillanatában - a terméklapon és a termékkártyán.
Ez a két változtatás nagyban hozzájárul e kivétel megszüntetéséhez.
A mérésekre és a mérőszámokra vonatkozó követelmények
A kivételkezelés minimalizálásának mérlegelésekor beállíthat jelentéskészítési feladatot (a használati eset nincs leírva). Hány kivétel volt, milyen esetekben fordult elő, valamint hány bejövő forgatókönyv ment sikeresen.
De sajnos. A tapasztalatok azt mutatják, hogy az ilyen formájú forgatókönyvekre vonatkozó jelentéstételi követelmények nem elegendőek, figyelembe kell venni az olyan folyamatokra vonatkozó jelentési követelményeket, amelyeket főként nem használati eset formájában írnak le.
Hozzáférés a használhatósághoz
Gyakorlatunkban a használati esetleírás űrlapot kibővítettük az entitások és adatok konkrét attribútumainak leírásával, hogy az ügyfél döntést tudjon hozni, ami javítja a későbbi használhatóságot.
A használhatóság kialakításához hozzáadtunk egy beviteli részt - adatok megjelenítése.
Egy jogosultsággal rendelkező forgatókönyvben ez az a tény, hogy az ügyfél jogosult a rendszerben. Ha az ügyfél előzetesen engedélyezett, akkor a sikeres hitelesítés után figyelmeztetést jelenítsen meg a navigációs előzmények és a kosár új fiókra váltásáról.
Általában ez a szükséges információk megjelenítése az ügyfél számára, hogy a forgatókönyv szerint dönthessen a további lépéseiről (megkérdezheti, hogy ez az adat elegendő-e az ügyfélnek, mire van még szükség, milyen információ az ügyfélnek kell döntéseket hoznia).
A bevitt információkat beviteli mezőkre is érdemes felosztani, ha azokat külön-külön és különböző kivételek kialakításával dolgozzuk fel.
A kliens hitelesítési példában, ha a beírt információkat bejelentkezési névre és jelszóra választja, akkor érdemes megváltoztatni az engedélyezési szkriptet, hogy kiemelje a külön bejelentkezés és a külön jelszó megadásának szakaszait (és ez a Yandex, Google, de a legtöbb online áruházban nem történik meg).
A szükséges adattranszformációk elérése
Az adatkonverziós algoritmusokra vonatkozó követelményeket is kivonhatja a szkriptből.
Példák:
- Az online áruházban történő termékvásárláshoz az ügyfélnek tudnia kell a termékkártyán ennek a terméknek a lehetőségét, költségét, városába szállítási idejét (amelyeket az algoritmus számít ki a termék elérhetősége alapján raktárak és az ellátási lánc paraméterei).
- Amikor beír egy kifejezést a keresősorba, a kliensnek az algoritmusnak megfelelő keresési javaslatok jelennek meg (amelyeket az algoritmus generál...).
Összességében
Általánosságban elmondható, hogy a könyv elolvasása után sajnos nem világos, hogyan lehet eljutni az elemzőtől az üzleti problémákon át a formalizált műszaki specifikációig egy fejlesztő számára. A könyv a folyamatnak csak egy részét mutatja be, a beviteli lépések nem világosak, a következő lépések pedig nem egyértelműek. Maga a használati eset legtöbbször nem teljes nyilatkozat a fejlesztő számára.
Mindazonáltal ez egy nagyon jó módszer egy objektum és egy alany közötti interakciós forgatókönyvek formalizálására és feldolgozására, amikor az interakció változást okoz valamiben a szubjektumban. Ez azon kevés írási módok egyike, amely lehetővé teszi az ellenőrizhető követelményeket explicit kivételes keresési pontokkal.
A könyv az elemzők számára kötelező olvasmány ahhoz, hogy kipróbálható darabokat írhasson.
Forrás: will.com