Az alábbi cikk a BA KARAKTER Magazin első számából származik, melyben többféle izgalmas témát tártak fel számunkra üzleti elemzők és projektszereplők.
Olvassátok sok szeretettel Hegyessy Mária és Kiszely-Jenei Annamária írását:
Az igényt leírtam, de ez sem volt elég: miért van szükség a negatív szemléletre?
Mindig is nagy kedvencem volt az Aladdin című Disney rajzfilm, és benne Dzsini, a dzsinn, aki teljesíti minden kívánságomat. Mármint max hármat. És egyébként is, van néhány feltétel, meg egy csomó kivételszerűség, pl. nem intézhetem úgy, hogy bárki bárkibe beleszeressen, ahogy ő is fogalmaz. Dzsini nem egy üzleti elemző. De a fiktív élete során tuti találkozott eggyel, aki segített neki megfogalmazni, hogy pontosan mi várható tőle, vagy belefutott a munkája során olyan esetekbe, amik miatt kénytelen volt a kivételeket megfogalmazni a felhasználóinak, azaz a kívánóknak, a csoda lámpa tulajdonosoknak. Ezek a kivételek a negatív követelmények.
A negatív követelményeket két szempontból tudjuk megközelíteni:
- Olyan esetek, amiket nem kell kezelni a projekt során, mondhatni nem scope, pl. Maradva a Dzsini példánál, mivel mi, a projekt scope meghatározói, erkölcsileg úgy ítéljük meg, hogy a szerelem rákényszerítése bárkire is nem jó dolog, ezért ennek a funkciónak a tervezésével, fejlesztésével, tesztelésével ne is foglalkozzunk, mert utána úgysem fogjuk használni. (Plusz, kifejezetten jó, hogy nincs is megvalósítva, ha eleve nem is lehetne sosem használni, mert nincs olyan VIP ügyfél, aki miatt eltérnénk a szabálytól.)
- A normál követelmények kiegészítései, ezek lehetnek a kivételek, pl. Nem intézhetem úgy, hogy bárki bárkibe beleszeressen
Na de annak a megfogalmazása, hogy mi a negatív követelmény, már azért is nehéz, mert ezeket ugyanúgy ösztönösen használjuk, mint a normál követelményeket.
Az Out Of Scope igény
Az első csoport az oos = Out of Scope igények, tehát azok, amiket úgy döntöttünk, hogy nem szükséges megvalósítani a projekt során. Ezeknek általában az a haszna, hogy ha megjelennek, akkor ezekkel nem foglalkozunk, nem dolgozzuk ki őket, tehát nem égetünk vele erőforrásokat. (a státusz megszerzésének a projekten belüli idejétől függően a tervezésre, a fejlesztésre, a tesztelésre)
Azzal, hogy a negatív követelmények rögzítésével kifejezetten kimondjuk, mit nem kell, vagy nem szabad a rendszernek megtennie, elkerülhetők a félreértések és a terjedelem felesleges növekedése. Ezzel biztosítható, hogy a fejlesztőcsapat és az érdekelt felek világosan megértsék, mi nem tartozik a hatókörbe.
Azon túl, hogy segítenek meghatározni a rendszer vagy termék határait, további pozitív hatásai is vannak:
- A fejlesztők nem fejlesztenek le olyan programrészeket, amelyre a megrendelőnek nincs szüksége, nem szán rá erőforrást, csak azért, mert az adott probléma kezelése megszokott.
- Alapot biztosítanak a tesztesetek megtervezéséhez és a minőségbiztosítási tevékenységek elvégzéséhez. A tesztelők ezen követelmények alapján ellenőrizhetnek olyan forgatókönyveket, ahol bizonyos műveleteket vagy viselkedéseket korlátozni vagy tiltani kell. Nem utolsósorban nem készül forgatókönyv nem elvárt funkciók tesztelésére, és emiatt majd hiányosságként nem kerül lefejlesztésre.
- Hasznosak lehetnek az érdekelt felek közötti konfliktusok vagy nézeteltérések feloldásában. Ha az érdekelteknek eltérő véleménye van arról, hogy a rendszernek hogyan kell viselkednie, a dokumentált negatív követelményekre való hivatkozás objektív alapot biztosíthat a döntéshozatalhoz.
- Segíthetnek a felhasználói elvárások kezelésében. Azzal, hogy világossá teszi, hogy a rendszer mit nem tesz meg, elkerülheti a felhasználók csalódását, akiknek esetleg irreális elvárásaik vannak a rendszer képességeivel kapcsolatban.
- A jól dokumentált negatív követelmények értékes hivatkozási alapot jelentenek a jövőbeli projektek vagy rendszerfejlesztések számára. Időt és energiát takaríthatnak meg, amikor arról kell dönteni, hogy a későbbi iterációk során hozzáadjunk vagy elhagyjunk bizonyos funkciókat.
Milyen esetekben hasznos jellemzően az Out Of Scope követelmények rögzítése?
- Megfelelés – Adjuk meg azokat a műveleteket, amelyeket a rendszer nem végezhet el a jogi vagy iparági előírásoknak való megfelelés érdekében. Például: „A rendszer nem engedheti meg a felhasználóknak, hogy másik felhasználó nevében rögzítsenek feladatot.” vagy „A rendszer nem őrizheti meg az ügyféladatokat a jogszabályban előírt megőrzési időn túl.
- Csökkentett funkcionalitás – Mindenképpen írjuk le, ha erőforrás megtakarítás céljából a standardtól, szokásostól eltérő módon, csökkentett terjedelemben kell megvalósítani egy funkciót. Például: „Jelszó megadásánál nem kell ellenőrizni az érvényességét.” vagy „Az üzenetek tartalmát nem kell szerkeszteni.”
- Adatintegritás – Adjuk meg, hogy a rendszer mit nem tehet meg az adatok pontosságának és integritásának fenntartása érdekében. Például: „A rendszer nem engedélyezheti ugyanazon ügyfélre vonatkozó kettős bejegyzést” vagy „A rendszer nem törölhet rekordokat megfelelő engedély nélkül.
- Felhasználói jogosultságok – Írjuk le azokat a műveleteket, amelyeket a felhasználói szerepkörök és jogosultságok alapján nem szabad engedélyezni. Például: „A normál felhasználóknak nem szabadna rendszergazdai törlési lehetőséggel rendelkezniük” vagy „A vendégfelhasználóknak nem szabadna hozzáférniük az érzékeny rendszergazdai funkciókhoz”.
- Hozzáférhetőség – Adjuk meg, hogy a rendszer mit nem tehet meg az akadálymentesség biztosítása érdekében. Például: „A rendszer nem hagyatkozhat kizárólag a színekre a fontos információk közvetítésében” vagy „A rendszer nem használhat villogó elemeket, amelyek rohamokat okozhatnak”.
- Hibakezelés – Írjuk le, hogy a rendszer hogyan ne reagáljon hibákra vagy rendellenes helyzetekre. Például: „A rendszer belső hiba esetén nem jeleníthet meg stack traces-t a felhasználók számára” vagy „A rendszer nem naplózhat érzékeny információkat a hibanaplókban.”
A követelmények „jó” és „rossz” oldala
A normál követelmények kiegészítései, pontosításai is követelmények, egymás nélkül csak félig igazak, ritkán egészek. Ha erre keresünk példát, akkor már általános iskolában is találkoztunk velük, amikor megtanultuk a nyelvtani szabályokat, pl.
- Az alap igényünk, hogy: Minden szóvégi ú ű hosszú.
- És a negatív kiegészítése: kivéve anyu, apu, áru stb.
Vagy gondoljunk csak a klasszikus KRESZ szabályokra. Ha látunk egy behajtani tilos táblát, ami alatt szerepel egy kivéve biciklisek tábla, akkor tudjuk, hogy gépjárművel nem lehet bemenni abból az irányból, de biciklivel igen. Ez egy igen hasznos szabály, bár azért mint igény, még elég ködös. Pl. mi vonatkozik a görkörisokra? Ők biciklisek ebből a szempontból? De ez egy másik cikk témája.
Ebben a példában az a jó, hogy látszik, hogy van olyan, hogy a normál igény maga is negatívan van megfogalmazva: autóval tilos behajtani az utcába.
És a negatív kiegészítése lesz a pozitív: de biciklivel be lehet hajtani.
Ami itt jól látszik, hogy a negatív igény lényege, hogy ellent mond az alapszabálynak, kivételt határoz meg.
Tehát általánosságban elmondható, hogy a negatív igény, a kiegészítés a kisebbséget pontosítja, azt a csomagot, amit külön kell kezelni a többségtől.
Normál igény, az alapszabály: minden madár, aminek csőre van.
Negatív igény, a kivétel: kivéve a kacsacsőrű emlőst.
Ha egy új állatot kell bevezetni a rendszerünkbe, és van csőre, akkor alapértelmezetten madárnak fogjuk tekinteni egészen addig, amíg új szabályt nem alkotunk rá.
Na de mindez miért kell nekünk?
Az out of scope követelmények leírása a specifikációban a hatékony követelménykezelés egyik kritikus szempontja. Segít a határok meghatározásában, a kockázatok csökkentésében, a megfelelés biztosításában, az elvárások kezelésében, a tesztelés támogatásában, a konfliktusok feloldásában, a dokumentáció biztosításában a későbbi referenciákhoz, valamint a projekt érdekeltjei közötti kommunikáció javításában. Ez pedig hozzájárul az üzleti és felhasználói igényeknek egyaránt megfelelő rendszer vagy termék sikeres átadásához.
A kiegészítésként megfogalmazott negatív követelmény pedig arra tökéletes, hogy a megrendelővel pontosan tudjuk egyeztetni az elvárásokat a működésre. A legtöbb szabálynak van kivétele, igen ritka az, amelyiknek nincsen. Ezekről pedig nem szabad elfelejtkezni, mert ha igen, akkor igen nagy slamasztikában találjuk magunkat akkor, amikor erre a külön szabályra nagy szükségünk lenne az éles működés közben.
Az, ha tudatosítjuk magunkban, hogy ezekkel is foglalkozni kell, hogy rá kell kérdezni, hogy biztos, hogy ennek a szabálynak minden esetben így kell működnie? Akkor is, amikor …? akkor már bevédtük magunkat és a stakeholdert is, mert ezzel a kérdéssel elindítottunk benne is egy gondolati szálat, ami a végén megerősítést vagy kivételeket fog eredményezni.
A vihar szeme: az alap követelmény
Láttatok már filmet hurrikánnal? Ilyenkor mutatják a fergeteges vihart, ami mindent letarol, és hogy milyen csalóka, hogy egyszer csak megtalál a vihar szeme, a középpont, ahol szinte kísérteties a csend és a nyugalom. Ha csak csend van és nyugalom, jobb óvatosan körbe nézni, hogy van e valami készülőben 🙂
Van, hogy a vihar szemét kapjuk igényként. Egy alap kezelési formát, és nem is tudjuk, hogy tart felénk a vihar sodró szele, csak amikor már megérkezett: ezt tudni kellene, már úgy tegnap előtt is, mert itt és itt vannak a kivételek.
És persze van az ellenkező eset is, hogy a stakeholderek se tudják igazán, hogy mi az alap működés. Csak a kivételeket sorolják. Pl. a lakossági ügyfeleket így kell kezelni, de nem, mert belőlük is van külön kezelési lépéssor a nagy városiaknak, a falusiaknak, a kettő közötti településen élőknek, meg egyébként a Kossuth utcán élőket mindig máshogy kell kezelni. Meg talán a Fő utcásokat is.
És mi meg csak ülünk itt a sok-sok kivétel hurrikánjának szemében, és mi nyugodtak vagyunk, mert habár a stakeholderek körülöttünk dobálóznak a sok-sok negatív követelménnyel, mi már átlátjuk az egészet. És látjuk, hogy mi az alapkövetelmény, amit körülírtak nekünk a különböző kivételeikkel.
Hegyessy Máriának és Kiszely-Jenei Annamáriának köszönjük a kívételes munkát a negatív követelmények elmagyarázásában. Ha tetszett ez a cikk, hasonló szakmai tartalmakért töltsd le a teljes magazint ezen a linken!
