Az alábbi cikk a BA KARAKTER Magazin első számában jelent meg, melyben üzleti elemzők és projektszereplők osztották meg velünk gondolataikat izgalmasabbnál izgalmasabb témákban.
Olvassátok sok szeretettel Czirják Péter írását:
Leleplezzük a mumust: Miért Scope creep jelöltek a nem funkcionális követelmények?
Karl Wiegers: “If you don’t have a documented and agreed-to project scope, how do you know if scope creep is taking place?”
Emlékszel, még arra, amikor valakinek annak ellenére nem sikerült a UAT – tesztje, hogy állítása szerint a követelményspecifikáció alapján “mindent”, amit kértek tőlük leszállítottak ráadásul bőven határidő előtt?
Na nekem egyből be is ugrott egy ide vonatkozó jelenet egy fiktív cég fiktív üzleti elemzőjének praxisában.
A történet azzal indult, hogy a Management kiadta, hogy javítani kell az IT és az Üzleti területek közötti együttműködés hatékonyságán, mert bizonyos igényeknél gyanúsan több iterációban kerül csak pont a dolog végére.
A megoldásban segítségünkre lesz Szemfüles BAgoly, tapasztalt Üzleti elemző barátunk, aki már több ilyen helyzetből is sikeresen kinavigálta magát és a csoportját. A szóban forgó esetben az Üzleti terület egy már meglévő végfelhasználói felületre kért egy új aloldalt, amelyen ügyfél adatokat tudnak bevinni és rögzíteni egy elektronikus formanyomtatványon gyorsan, szépen és biztonságosan pont olyan módon ahogy az lenni szokott.
Karl Wiegers: “Two terms that should make your blood run cold are “assumed requirements” and “implied requirements.” Strive to communicate requirements expectations explicitly”
Karl Wiegers: “If some capability or characteristic is not in the requirements, don’t expect to see it in the product.”
Na lapozzunk csak bele abba a specifikációba (…) aztán beszélgessünk el a kollégákkal erről:
Keresem, hol vannak a nem funkcionális igények……
(…) “Hát azt igy külön nem írtuk oda, meg amúgy nem is mondták. Én meg elég régóta itt dolgozom, és mindig ugyanúgy kérik ezeket az ilyen típusú igényeiknél. Csak új kollégához került Üzleti oldalon a feladat, aztán biztos nem értette jól és csak nem szólt. Amúgy is nekem ez magától érthető mit szeretnének”(…)
Kértek egy oldalt, amelyen ügyfél adatokat tudnak rögzíteni gyorsan, szépen és biztonságosan olyan módon ahogy az lenni szokott. Az oldal kész van és működik. Úgy néz ki, mint az előző amire nem mondták, hogy rossz, én meg nem tudom magamtól kitalálni mi nekik a szép. A fejlesztő mondta, hogy majd kitalál valamit magától, amúgy is nemrég olvasott valamit egy UX-es e-learningben, ami szerinte jó lesz. Közösségi fejlesztésű weboldal design.
Az Architect-tel beszéltem, azt mondta az oldalon az adatmentés biztonságos, mert a felhőben elmaszkoljuk a személyes adatokat. A gyors meg relatív szóval azzal úgysem lehet mit kezdeni. Különben is olyan nincs, hogy gyors is meg szép is (…)
Na és mi történt utána…?
(…) “Jöttek a változtatási igények. Először csak ehhez a konkrét új oldalhoz, mert lassú volt, amikor 11:00 körül mindenk ügyintéző ugyanazon az űrlapon dolgozott.
Aztán beesett a GDRP-ban a felejtéshez való jog, amelyet persze azonnal le kellett fejleszteni erre az űrlapra is. Kérdeztük a jogászoktól ez most mennyire fontos vagy sürgős, de azt mondták, hogy nagyon. A másik lehetőségünk, hogy mi IT oldalon fogjuk kifizetni a bírságokat az Adatvédelmi vizsgálat esetére. Végül is mindegy, mert az szerencsére egy másik projektben lett adminisztrálva.
Sajnos egyszer elszálltak a lementett űrlapok (persze ne kérdezd meg, hogy került erre sor, amikor nem volt pontos hibaüzenet róla). De szerencsénk volt, mert fél nap alatt az Üzleti terület újra be tudta gépelni az adatokat papírról, mialatt mi meg nyomoztuk 18:00 után a logokból a hibákat Post GoLive Support időszak után.
Amikor kész lettünk és megoldottuk, akkor az Üzleti terület már javában morgott és végig azt hajtogatták, hogy „Szuper lett volna, ha ilyen eshetőségre magától is figyel az alkalmazás, mert erre mi nem is gondoltunk eredetileg, hogy mi legyen ilyen esetekben a vészmegoldás.” (…)
Szemfüles BAgoly tanácsot ad
- Először is a konkrét esetben a követelményspecifikáció nem lett szinonimája a közös megértésnek a projektterjedelem viszonyában (Scope) amint az elhagyta a jól megszokott rendszerkontextusát. Az interpretáció és a dekompozició során teret nyert a gondolatolvasás, a fakultatív és többféle értelmezés, amelynek következtében, ahogy az lenni szokott: az igényspecifikáció lopakodó módon kilépett az eredeti üzleti igény értelmezési környezetéből. (De ez egy másik témakörbe tartozik: a követelményspecifikációval szemben támasztott tartalmi és formai minőségbiztosítási kritériumok).
- Aztán felmerül a kérdés, hogy biztos, hogy a megfelelő Stakeholdert vonták be a beszélgetésbe? Milyen módon kezelték és alakították ki az elvárásokat vagy választották ki pragmatikusan adott kontextus és igényhez mérten a követelményfeltárási interjú formát? (De ez már Stakeholder management témakör.)
I. Kano Model és a láthatatlan igények
A termékfejlesztésben bevett gyakorlat és a követelménykezelés / követelménymanagement témaköréből is jól ismert Kano modell egy másik aspektusát hívnám elő, ami itt fentebb el lett lazáskodva.
Tegyük félre saját előtörténetünkből adódó részrehajlásunkat, önnön szakbarbárságunkat és az Üzleti területtel közösen legalább három kategóriába tuszakoljuk be az adott igényt.
Tudatosan készüljünk elő arra a természetes emberi jelenségre, amelyben szükségszerűen torzul a beszélő és a hallgató közötti csatornán végigszáguldó információ, amely, ahány csomóponton keresztül végighalad annyiszor torzulhat.
A Kano model sokrétű, ezért redukáltam a konkrét példánkhoz.
Itt ez a személet és perspektivikus olvasat kispórolódott. Ezért minden, amit az üzleti terület nem kommunikált le, az automatikusan nem került bele a projektterjedelmbe (Scope) tehát láthatatlan és ezáltal teljesíthetetlen követelményként megmaradt dokumentálatlanul az Üzleti (UAT Teszt jóváhagyói) oldalon. Ilyenformán bele sem került a követelményspecifikációba (Tehát önkéntelenül kikerült: Out of Scope). Mivel észrevétlenül lecsökkent a projektterjedelem (In-Scope) ezért egy nemteljesítés készült elő csendben halkan a végfelhasználói Demo eseményre. (És a zenekar tovább játszik a Titanic-on…. ismerős?)
Itt még semmilyen nem funkcionális követelményspecifikum nem került terítékre, mivel csak félig látunk át a saját függönyünkön…
Karl Wiegers: “We sometimes express requirements casually because we assume the reader has a sensibility filter” similar to our own, but people often interpret the same statements in different ways. This ambiguity leads to mismatched expectations and surprises upon delivery.”
Szemfüles BAgoly tanácsot ad
Ha végképp elbeszéltek egymás mellett vagy hiányzik a Basic Factor és a Delighters feltárásához szükséges tudás a BA és Üzleti terület között, akkor, kedves BA, ha mást nem, ülj be közéjük és alkalmazz Apprenticing vagy Observation technikát, hogy beleláss a másik fejébe, különben úgy jársz, mint képzeletbeli kolléga a szép és biztonságos ügyféladat űrlappal, ami a végén sem szép nem lett, sem biztonságos.
II. Projektterjedelem (Scope) az igény dinamikus rendszerkontextusában
Térjünk csak vissza egy pillanatra erre a mondatra itt….
“(…) mert bizonyos igényeknél gyanúsan több iterációban kerül csak pont a dolog végére”
Az IREB követelménykezelési módszertanban is szereplő igény/követelménykontextus és annak aspektusain keresztül jobban megérthető, hogy miért nem probléma önmagában az a tény, hogy az igénnyel kapcsolatos közös megértés kialakulása egy természetesen iteratív folyamat.
Emlékszünk még arra, hogy egy üzleti igény az nem a levegőben lóg? Arra is emlékszünk, hogy előtte is és utána is van volt lesz világ?
Amikor az üzleti elemző (BA) egy üzleti igény / követelmény feltárásán dolgozik és a Kano modell segítségével már átlát a láthatatlanságon és felfedezte a gondolatolvasást akkor nincs más hátra, mint beleillesztenie a képzeletbeli szép gyors és biztonságos adatbekérő űrlapunkat, annak saját élő kontextusába.
Először is zárjuk ki mindazt, ami a mi űrlapunk számára az aspektusokból irreleváns. Azaz: nincs sem hatással az igény/követelmény környezetére, se nem mi magunk hozzuk létre, vagy változtatjuk meg azt azáltal, hogy a projektterjedelemben (Scope) leszállításra kerül.
Térképezzük fel a rendszerkontextus aspektusait az IREB módszertan által is ismert módon:
- A bejelentkezési folyamattal nem vagyunk kapcsolatban és nincs is ránk hatással. Ezért ez ide kerül: (Irrelevant environment)
- Az ügyféladatkezelési szabályzat-ot nem változtatjuk meg, de hatással van ránk. Ezért Rendszerkontextuson belüli Aspektus -ként feljegyezzük, a Szabályzatok és rendelkezések alatt.
- Az ügyféladminisztráció üzleti terület kollégáinak munkájában leszünk érdekeltek és hatással vannak ránk. Rendszerkontextuson belüli Aspektus -ként feljegyezzük, mint Stakeholdert.
- A HR üzleti terület nyilvántartási rendszerébe mentjük le az adatokat ezért Rendszerkontextuson belüli Aspektusként feljegyezzük, mint Célrendszer, ahová már tudjuk, hogy létező aktív Interface-ünk van. Mivel az interface-t nem módosítjuk, ezért nem lesz része az új rendszerünknek azaz Scope-unknak (fekete kör)
- Az ügyféladatrögzítési folyamatot megváltoztatjuk, mert az eddigi papír alapú nyomtatványt elektronikus formanyomtatványra cseréljük. Ezt Rendszer – Scope- on belüli üzleti igényként rögzítjük.
A kontextus viszont dinamikusan változik attól függően, hogy milyen gyorsan és mennyi iteráción belül finomodik a megértés ugyanarra az üzleti követelményre vonatkozóan. (Erről részletesen ír az ISO 29148 szabvány.) Ugyanide tartozik, az is, ha bármilyen új elem kerül be az irreleváns környezetből először a rendszerkontextusba, majd a középen lévő körbe (Scope), ezzel változik a dinamika és megmozdulnak a határok.
Ez esetben ez automatikusan újra vizsgáltatja a BA-val, mindazt, amit eddig megismert arról, hogy mi releváns, mi irreleváns, mi van hatással a projektterjedelemre (Scope), továbbra is igaz-e az mit kell létrehozunk vagy megváltoztatunk a kívülről a rendszerkontextusba bekerült új elem miatt.
Emlékszünk még erre a mondatra a kis történetünkből?
“Aztán beesett a GDRP-ban a felejtéshez való jog, amit persze azonnal le kellett fejleszteni erre az űrlapra is. (…)
Mivel a GDPR belekerült a kontextusunkba, így egy új aspektusként horizontálisan automatikusan új igényeket támasztott a Jogi szakterület Stakeholder-ein keresztül.
Amennyiben a rendszerkontextus dinamikusan mozgó szürke zónáira az igénykezelési folyamat fel van készítve, akkor a változtatáskezelési folyamatrész ezt lekezeli.
Ha nem, akkor itt is van a Scope creep.
Karl Wiegers: “The first question to ask when someone proposes a new requirement is, „Is this in scope?” If yes, it must be addressed. If no, it does not, at least not now. But if the answer is “No, but it ought to be,” the scope must be adjusted to accommodate it. “
Szemfüles BAgoly tanácsot ad
Ameddig nem tudod az üzleti területtel közösen feldíszíteni ezt a kontextus diagramot, akkor van egy rossz hírem. Utas vagy a saját gépeden és nem pilóta. Üzleti elemzőként nem tudod mi része a projektterjedelemnek (Scope) és mi nem (Out of scope). Mi van hatással az igényre és mi irreleváns számodra most.
Milyen interface- van már kiépülve (Rendszerkontextus) és mit kell kiépíteni (Scope). Milyen új eseményekre kell reagálnia a rendszernek (Scope) vagy milyen jogszabályi megfelelőségnek kell eleget tennie a megoldásnak (pl GDPR)
Csak kerülgetitek a Scope-ot mint macska a forró kását, kialakul a „jaj de jó, hogy jóváhagytak valamit” formájában a hamis biztonságérzet és nem marad más csak a remény, hogy hátha ez is (…) szerencsére egy másik projektben lett adminisztrálva. “
Karl Wiegers: „If you don’t have a documented and agreed-to project scope, how do you know if scope creep is taking place?”
III. Transzparencia és vizualitás a nem funkcionális követelmények irányába (Kategorizáció és Trade-off-ok)
A nem funkcionális követelményeket az IREB szakirodalom két további alkategóriára tovább bontja. Rendszertulajdonságokra (Quality Attributes) és Peremfeltételekre (Constraints).
A rendszertulajdonságok (Quality Attributes) leírják, hogy milyen tulajdonságokkal kell rendelkeznie egy rendszernek, amelyet vagy közvetve vagy közvetlenül, de implementálnunk kell. Vegyünk két példát.
A Peremfeltételekkel (Constraints) más a helyzet. Ezek vagy lemaradnak sok esetben, vagy túlhatalmaskodóan gátolják a lehetséges megoldásokat.
Addig, amíg a funkcionális igényeket és a rendszertulajdonságokat (Quality Attributes) implementáljuk közvetve vagy közvetetten egy származtatott funkcionális követelményen keresztül, addig a Peremfeltételeket (Constraints) sosem implementáljuk.
Azok direktben jelennek meg, mint a problémára vagy az új igényre adandó megoldási teret eleve korlátozó, determinisztikus parancsok és előírások.
Szemfüles BAgoly tanácsot ad:
Amennyiben egy követelményfeltárás során az a nem tudatos érzésed van, hogy a probléma megismerése helyett, iskolai tollbamondásos házifeladatot kapsz, vagy ha az Üzleti területek túlzottan a megoldás irányából közelítenek, javaslom húzd be a féket két kézzel. Igény helyett peremfeltételeket adsz öntudatlanul a fejlesztőknek és nem pedig követelményfeltárást végzel. Ehhez nézd meg ezt a táblázatot, nehogy eltévedj.
Az üzleti elemző számára a peremfeltételek (Constraints) egyéb módokon is csoportba sorolhatók. Vannak pénzügyi, technikai, jogi, fizikai peremfeltételek, amelyeket az IREB módszertan használ.
A módszertanokból közismert, hogy a funkcionális követelmények a “mit” -et írják le, a nem funkcionális követelmények a “hogyan” kérdésre válaszolnak.
Az ISO 25010 szabvány segítségünkre van mert taxative felsorolja, hogy melyek azok a rendszertulajdonságok (QualityAttributes), amelyeket mindig végig kell beszélnünk az Üzleti területtel akármilyen igényről is van szó.
Idézzük csak fel az idevonatkozó részleteket az űrlapunkról és helyettesítsük be a fenti táblázatnak megfelelően, ha épp téged raktak rá erre a projektre határidő előtt 3 nappal…
Szemfüles BAgoly tanácsot ad:
Ha végképp elbeszéltek egymás mellett vagy hiányzik a közös megértés az IT és az Üzleti terület között a nem funkcionális követelmények kiválasztásában (melyek relevánsak számotokra az adott projekt scope-jára nézve) akkor közösen hozzatok létre egy Trade-off táblázatot és beszéljétek át, hogy az IT és az üzleti terület ki miről hajlandó lemondani. Ezáltal a bizalom a közös megértés és az elvárásmanagement is javul.
Közösen az üzleti területekkel hozzatok létre egy ehhez hasonló, de példákkal kiegészített, számszerűsített és számotokra közösen definiált nem funkcionális követelményeket tartalmazó kérdéssort is akár példákkal, amelyek segítenek eligazodni és újrahasznosíthatóak projektről-projektre.
Összefoglaló és tanulságok
Egy ok, amiért a nem funkcionális követelmények ijesztőek lehetnek, az az, hogy bennük benne rejlik a szubjektivitás és ködösség. Míg a funkcionális követelmények gyakran jól meghatározott bemenetekkel, folyamatokkal és kimenetekkel rendelkeznek, a nem funkcionális követelmények olyan tulajdonságokkal foglalkoznak, amelyeket nehéz mérni és meghatározni. Ez a szubjektivitás félreértéseket és vitaforrásokat eredményezhet a projekt során.
Ehhez: A Kano modell-el láthatóvá teheted a láthatatlan igényeket legyen szó funkcionális igényről vagy nem funkcionális igényről. Amennyiben az üzlet Peremfeltételeket (Constraints) definiál igények helyett úgy többszörös iterációban tárjuk fel mi a valódi igény.
A nem funkcionális követelmények hajlamosak fejlődni a projekt során. Kezdetben a résztvevőknek lehet egy ködös és általános elképzelésük a teljesítmény vagy biztonsági igényekről, de ahogy a projekt halad előre, és több részlet kerül előtérbe, ezek a követelmények specifikusabbá válhatnak.
Ez a fejlődés csak az igénykezelési folyamat kontrollja alatt nem okozhat terjedelemváltozást mindkét irányban. Kb hasonló analógia lehet ehhez: Rossz design vs. Technical debt.
A projektterjedelem (Scope/system) és rendszerkontextus tudatos használatával el tudjuk különíteni, hogy mi tartozik a Scope-ba és mi nem tartozik bele. (Újra megismételve: Mit hozunk létre/változtatunk meg az igény kontextusából kiemelve). Ilyenformán orvosolható és keretben tartható a projektterjedelem kalkulálatlan túlterjengése (Scope creep).
A nem funkcionális követelmények tudatos kategorizálásával a Stakeholder elégedettséget és közvetlenül a sikeres UAT teszt garantálhatja az Üzleti elemző.
A nem funkcionális követelmények természetükből fakadóan szorosan kapcsolódnak a funkcionális követelményekhez. Az egyik változtatása a másikra hatással lehet, ami nem várt projektterjedelem-bővüléshez vezethet. A BA-nak szenioritástól elvárt szinten ügyesen kell navigálnia ebben a bonyolult kapcsolatban, hogy a projekt fókusza és a leszállítandók nyomonkövetése (360% Traceability) mindig elérhető közelségben maradjon.
A Stakeholdermanagement természetes velejárója az érdekkonfliktus. Ehhez a nem funkcionális követelmények Trade-off táblázatával pl a prioritáskonfliktusok egy előre definiált kereten belül tárgyalhatóak le.
A nem funkcionális követelmények forrása és más funkcionális követelményekkel való viszonya láttatható ezáltal validálható majd specifikálható, ezért verifikálható a teljes igénykezelési folyamat alatt beleértve a későbbi végfelhasználói tesztelést és élesítést.
Irodalomjegyzék és könyvajánló
- ISO 25010
- ISO 291488
- Handbook for the CPRE Foundation Level according to IREB Standard
- https://www.ireb.org/content/downloads/3-cpre-foundation-level-handbook/cpre_foundationlevel_handbook_en_v1.1.pdf
- Klaus Pohl, Chris Rupp: Requirements Engineering Fundamentals: A Study Guide for the Certified Professional for Requirements Engineering Examp Foundation Level / IREB Compliant (IREB 2.2 Version).
- Karl Wiegers, Joy Beatty: Software Requirements (Developer Best Practices) Third Edition
- Karl Wiegers Describes 10 Requirements Traps to Avoid
- http://www.uml.org.cn/rjzl/pdf/1113/reqtraps.pdf
A cikkben szereplő idézetek forrása:
- Thoughts for the Day from Karl Wiegers
- Karl Wiegers: Software Development Peals: Lessons from Fifty Years of Software Experience
- Linda Westfall: What, Why, Who, and How of Software Requirements
- https://www.researchgate.net/publication/293118075_What_Why_Who_When_and_How_of_Software_Requirements
- When Telepathy Won’t do. Requirements Engineering Key Practices
- https://www.processimpact.com/articles/telepathy.pdf
Köszönjük Czirják Péternek a nem funkcionális követelmények részletes összefoglalását. Ha tetszett ez a cikk, hasonló szakmai tartalmakért töltsd le a teljes magazint ezen a linken!
