Bánsághi Anna Bánsághi Anna 1 of 54

Követelmény menedzsment

2. előadás

SZOFTVERTECHNOLÓGIA © Bánsághi Anna [email protected]

2. ELŐADÁS - KÖVETELMÉNY MENEDZSMENT

© Bánsághi Anna

1 of 54


2. előadás

TEMATIKA I. SZOFTVERTECHNOLÓGIA ALTERÜLETEI II. KÖVETELMÉNY MENEDZSMENT III. RENDSZERMODELLEK IV. RENDSZERARCHITEKTÚRÁK V. RENDSZERTERVEZÉS VI. VALIDÁCIÓ, VERIFIKÁCIÓ VII. MINŐSÉGBIZTOSÍTÁS VIII. TESZTELÉS

© Bánsághi Anna

2 of 54


2. előadás

II. KÖVETELMÉNY MENEDZSMENT 1. Funkcionális és nemfunkcionális követelmények 2. Követelményspecifikáció dokumentumai 3. Követelménytervezési folyamat Követelmények felderítése Követelmények specifikálása Követelmények validálása 4. Követelmények kezelése

© Bánsághi Anna

3 of 54


2. előadás

SZOFTVERKÖVETELMÉNYEK a rendszer által nyújtott szolgáltatások és megszorítások kitalálásának, elemzésének, dokumentálásának és ellenőrzésének folyamata a követelményeket különböző absztrakciós szinteken lehet megadni, kezdve a természetes nyelvi leírásoktól egészen a részletes, formális definíciókig a követelményeket a különböző olvasók (megrendelő, felhasználó, üzleti elemző, rendszertervező, fejlesztő, tesztelő) eltérő módon használják, más és más jellegű információközlésre van szükség

© Bánsághi Anna

4 of 54


2. előadás

KÖVETELMÉNY SZINTEK felhasználói követelmények a rendszer végfelhasználói, ügyfélmenedzserek számára készített természetes nyelvi, diagramokkal támogatott leírások a rendszer külső viselkedését érdemes megadni, minél egyszerűbb és világosabb kifejezésekkel rendszerkövetelmények rendszertervezők, szoftverfejlesztők számára készített részletes, pontos, formális specifikációk, rendszermodellek a felhasználói követelmények kibővített változatai, továbbra is kerülve a tervezés és a megvalósítás mikéntjét és hogyanját a két szinten megfogalmazott követelmények között egyértelmű megfeleltetés létezik, a rendszerkövetelmények kiterjesztik, részletezik a felhasználói követelményeket

© Bánsághi Anna

5 of 54


2. előadás

1. FUNKCIONÁLIS ÉS NEM‐ FUNKCIONÁLIS KÖVETELMÉNYEK funkcionális a rendszer által nyújtott szolgáltatások, funkciók nemfunkcionális a szolgáltatásokra és a funkciókra tett megszorítások (teljesítménybeli, időbeli, szabvány) a két típus nem független egymástól, az egyik jelenléte generálhat más típusú követelményt vagy megszorítást egy felhasználói biztonságra vonatkozó nemfunkcionális követelmény maga után vonhatja egy jogosultságkezelő alrendszer beépítésének szükségességét, ami a funkcionális követelmények között fog megjelenni

© Bánsághi Anna

6 of 54


2. előadás

KÖVETELMÉNY SZINTEK ÉS FAJTÁK MÁTRIXA

© Bánsághi Anna

7 of 54


2. előadás

FUNKCIONÁLIS KÖVETELMÉNYEK leírják, hogyan kellene működnie a rendszernek felhasználói szinten absztrakt kívánságok rendszerszinten ki vannak fejtve a bemenetek, kimenetek, kivételek a fejlesztési folyamat későbbi fázisaiban bekövetkező hibák a funkcionális követelményekben lévő pontatlanságokból, ellentmondásokból, többértelműségekből erednek elvben az a cél, hogy a funkcionális követelmények teljesek és ellentmondásmentesek legyenek, a gyakorlatban azonban a megrendelői kívánságok idővel alakulnak, változnak, illetve összetett rendszerek esetén könnyű tévedni vagy kifelejteni

© Bánsághi Anna

8 of 54


2. előadás

NEMFUNKCIONÁLIS KÖVETELMÉNYEK leírják, milyen tulajdonságokkal kellene rendelkeznie a rendszernek (teljesítmény, megbízhatóság, erőforrás megszorítások, szabványoknak való megfelelés) nemcsak a fejlesztendő rendszerre vonatkoznak, hanem felvethetik jogi, adatvédelmi, szervezeti szabályzatoknak való megfelelést, vagy más rendszerekkel való együttműködés igényét is ezen követelmények gyakran kritikusabbak, mint a funkcionális követelmények, mert egy nemfunkcionális követelménynek való megfelelés a rendszerarchitektúrára, a szoftverminőségre kihat szabványok, választott fejlesztési folyamatmodell egy nemfunkcionális követelmény új funkcionális követelményeket generálhat jogosultsági rendszer

© Bánsághi Anna

9 of 54


2. előadás

NEMFUNKCIONÁLIS KÖVETELMÉNYEK TÍPUSAI termékkövetelmények meghatározzák a termék viselkedését (használhatóság, hatékonyság, megbízhatóság, hordozhatóság) szervezeti követelmények a megrendelő és a fejlesztő szervezeti szabályzataiból fakadnak (telepítési, implementációs, szabvány) külső követelmények a rendszeren és annak fejlesztési folyamatán kívül esnek (együttműködési, etikai, jogi, adatvédelmi, biztonsági)

© Bánsághi Anna

10 of 54


2. előadás

NEMFUNKCIONÁLIS KÖVETELMÉNYEK MEGADÁSA probléma, hogy nehéz verifikálni őket, mert általános célokként fogalmazzák meg őket, pl. gyors válaszidő Mit jelent, hogy gyors? a mérhető követelményeket érdemes mennyiségileg, objektíven tesztelhető metrika segítségével kifejezni a gyakorlatban azonban nehéz az elképzeléseket mennyiségi követelményekre váltani, mert a megrendelők nem tudják igényeiket íly módon kifejezni ha mégis vannak mérhető követelmények, azok verifikációs költsége igen magas lehet a követelmények ütköznek egymással gyors műveletek, viszont kevés memóriahasználat

© Bánsághi Anna

11 of 54


2. előadás

NEMFUNKCIONÁLIS KÖVETELMÉNYEK METRIKÁI sebesség tranzakciók/mp, felhasználói esemény válaszideje méret kódméretek, memóriaméretek, skálázhatóság használhatóság képzési idő, különféle help-ek megbízhatóság hibák bekövetkezési aránya, hibák átlagos bekövetkezési ideje, rendelkezésre nem-állás valószínűsége robusztusság leállás utáni újraindítási idő, hibát okozó események aránya, hiba okozta adatmeghibásodás valószínűsége hordozhatóság célrendszerek száma, célrendszer függő és független utasítások aránya

© Bánsághi Anna

12 of 54


2. előadás

2. KÖVETELMÉNYSPECIFIKÁCIÓ DOKUMENTUMAI a követelményespecifikáció szó két jelentéssel bír: 1. az a folyamat, amely során mind a felhasználói, mind a rendszerkövetelmények, rendszermodellek definiálásra kerülnek 2. a folyamat során előálló dokumentumok

© Bánsághi Anna

13 of 54


2. előadás

KÖVETELMÉNYSPECIFIKÁCIÓ DOKUMENTUMAI hivatalos leírása annak, amit meg kell valósítani tartalmazza a felhasználói és a rendszerkövetelményeket egyaránt, ha szükséges több dokumentumba szervezve mivel a dokumentum olvasói igen változatosak, ezért kompromisszumot kell képezni a következők között: megrendelők tákékoztatása fejlesztőknek, tesztelőknek szóló tervek továbbfejlesztési lehetőségek

© Bánsághi Anna

14 of 54


2. előadás

A SPECIFIKÁCIÓBAN HASZNÁLHATÓ NYELVEK természetes nyelv jól definiált szakterületi fogalmakkal, világos mondatszerkesztéssel operál struktúrált természetes nyelv szabványos űrlapokat, sablonokat használ tervező nyelv programozási nyelvre hasonlít, a rendszer működési modelljeinek leírására grafikus jelölések BPMN folyamatmodellező, az UML használati esetei, aktivációs és szekvenciadiagramjai matematikai specifikációk véges állapotú automaták

© Bánsághi Anna

15 of 54


2. előadás

KÖVETELMÉNYDOKUMENTUMOK SZABVÁNYAI számos szabvány és ajánlás létezik arra, hogy mit és milyen szerkezetben tartalmazzon a dokumentum a szoftverfejlesztésben használt folyamatmodell nagy mértékben befolyásolja, hogy milyen típusú, milyen részletezettségű dokumentumokra van szükség külső vállalkozó alkalmazása vagy nagy rendszerek évekig tartó evolúciója esetén lényeges, hogy legyen egy - az összes fél által elfogadott és aláírt - dokumentum gyorsan változó követelmények vagy pár hónapos projektek esetén hiábavaló a dokumentumírásra pazarolt energia, inkább pár napos vagy hetes léptékű egységekben érdemes tervezni

© Bánsághi Anna

16 of 54


2. előadás

NAGY RENDSZEREK DOKUMENTUMAI érdemes a következőket megfontolni, és a szükségeseket alkalmazni előszó, bevezetés, szójegyzék felhasználói követelmények definíciói a rendszer felépítése, rendszer követelmények definíciói és specifikációi, rendszermodellek rendszerevolúció függelékek, tárgymutató

© Bánsághi Anna

17 of 54


2. előadás

AGILIS FEJLESZTÉS DOKUMENTUMAI folyamatosan karbantartott product backlog, mely a fejlesztendő funkciók (user story-k) prioritásos listája egy user story felépítése azonosító megnevezés Mint adott típusú felhasználónak szükségem van a funkcióra azon okból, hogy magyarázat prioritás minél fontosabb, annál nagyobb szám típus új / továbbfejlesztés / hibajavítás sprint azonosítója ha már elkészült becsült ráfordítás általában időbeni leírás szabad szöveges információ

© Bánsághi Anna

18 of 54


2. előadás

3. KÖVETELMÉNYTERVEZÉSI FOLYA‐ MAT a folyamat célja a követelményekhez kapcsolódó dokumentumok létrehozása és karbantartása három tevékenység sorozata, melyek iteratívan ismétlődnek követelmények feltárása követelmények specifikálása követelmények validálása a folyamat tevékenységei, a ráfordítások és a keletkező dokumentumok függnek a választott fejlesztési folyamatmodelltől, a fejlesztendő rendszertől

© Bánsághi Anna

19 of 54


2. előadás

KÖVETELMÉNYTERVEZÉS FOLYAMATA

az első iterációban a magasszintű üzleti, nemfunkcionális és felhasználói követelmények megértése történik, majd a következő iterációkban finomodnak a rendszerkövetelmények és modellek specifikáció © Bánsághi Anna

20 of 54


2. előadás

MEGVALÓSÍTHATÓSÁGI TANULMÁNYOK az üzleti követelmények kezdeti vázlata, hogyan illeszkedne és támogatná a tervezett rendszer a meglévő üzleti folyamatokat támogatja-e rendszer az üzleti célokat, milyen üzleti értékkel bírna, ha adott technológiával és költséggel elkészülne a válaszokat a leendő felhasználók, üzemeltetők körében folytatott interjúk adják meg, illetve a piacon lévő hasonló rendszerekkel való összehasonlítások a tanulmány javaslatot is tartalmaz, hogy érdemes-e folytatni a munkát kockázatelemzés és -kezelési javaslat is tarthozhat hozzá

© Bánsághi Anna

21 of 54


2. előadás

KOCKÁZATELEMZÉS KOCKÁZATI KATEGÓRIÁK üzleti kockázat szervezeti szintű kockázat, pl. a konkurens egy hasonló szoftverterméket vezet be projektkockázat folyamat szintű kockázat, kihatással lehet a projekt ütemezésére, az erőforrásokra, pl. csapattagokkal kapcsolatos, az erőforrások becsléséből vagy a megrendelő követelményeinek változásaiból adódó kockázatok termékkockázat a fejlesztett szoftver minőségére vagy teljesítményére gyakorol hatást, pl. a használt technológiákból vagy eszközökból adódó kockázatok

© Bánsághi Anna

22 of 54


2. előadás

KOCKÁZATKEZELÉS FOLYAMATA kockázat azonosítása a fenti kategóriák és alkategóriák alapján a kockázatok azonosítása kockázat elemzése a beazonosított kockázatok bekövetkezési valószínűségének (kicsi, közepes, nagy) és hatásának (nem jelentős, mérsékelt, súlyos) becslése kockázat tervezése a kulcsfontosságú kockázatok kezelési stratégiájának meghatározása kockázat figyelése a bekövetkezési valószínűség és a hatás rendszeres újraértékelése, és ha szükséges, a kezelési stratégia módosítása

© Bánsághi Anna

23 of 54


2. előadás

KOCKÁZATI MÁTRIX a beazonosított kockázatok jelölése a mátrixban

© Bánsághi Anna

24 of 54


2. előadás

KOCKÁZATKEZELÉSI STRATÉGIÁK elkerülés kis bekövetkezési valószínűségű, de súlyos hatású kockázatok esetén érdemes a megelőzésen fáradozni, vagy a bekövetkezési valószínűséget még jobban csökkenteni minimalizálás nagy bekövetkezési valószínűségű, de jelentéktelen hatású kockázatok esetén érdemes inkább a bekövetkező károkat csökkenteni vészhelyzeti terv ha mind a két tényező nagy, akkor érdemes alternatív forgatókönyvekkel felkészülni a kritikus helyzetekre

© Bánsághi Anna

25 of 54


2. előadás

KOCKÁZATI MÁTRIX a kezelés módjának jelölése a mátrixban

© Bánsághi Anna

26 of 54


2. előadás

KÖVETELMÉNYEK FELTÁRÁSA

© Bánsághi Anna

27 of 54


2. előadás

KÖVETELMÉNYEK FELTÁRÁSA

a megrendelők és az üzleti elemzők együtt dolgoznak, ekkor történik a szakterületi fogalomrendszer tisztázása is

© Bánsághi Anna

28 of 54


2. előadás

A FELTÁRÁS FOLYAMATA felderítés végfelhasználókkal, szakterületi szakértőkkel, kereskedelmi képviselőkkel való együttműködésből derül ki, mit is szeretnének osztályozás a kapcsolódó és az összefüggő követelmények csoportosítása, jövőbeni részrendszerek megalapozása priorizálás a fontossági sorrend minden esetben szükséges, különösen akkor, amikor a rendszernek különböző érdekű felhasználói vannak dokumentálás informális vagy formális dokumentáció

© Bánsághi Anna

29 of 54


2. előadás

A FELTÁRÁS ESZKÖZEI interjúk kérdések a fejlesztendő és a már meglévő rendszerekről, a jelenlegi és a jövőbeni üzleti folyamatokról forgatókönyvek a valós életbeli példák alapján könnyebb elképzelni, részletezni, illetve kritizálni a rendszert használati esetek forgatókönyv-alapú diagramok, az UML szabvány egyik diagramtípusa, a rendszer funkcióit, az aktorokat és a közöttük lévő kommunikációt ábrázolják etnográfia megfigyelésen alapuló technika, a fejlesztendő rendszert használó társadalmi, szervezeti és munkakörnyezet felderítése

© Bánsághi Anna

30 of 54


2. előadás

INTERJÚK FAJTÁK zárt előre definiált kérdéshalmaz nyílt nincs megadott kérdéssorozat, hanem minél szélesebb körű problémákat vizsgálnak át

HÁTRÁNY minden képviselő a saját szakterületi terminológiáját használja, ezért az is célja az interjúnak, hogy a követelménytervező megismerje a különféle terminológiákat bizonyos szakterületi ismeretek olyan evidensek a képviselők számára, hogy talán nem is említik meg, így azok nem kerülnek be a követelmények közé

© Bánsághi Anna

31 of 54


2. előadás

HATÉKONY INTERJÚK kerülik az előítéleteket, hatalmi vagy befolyási viszonyoktól mentesek, bármilyen meglepő ötlettel álljon is elő egy képviselő, azt megfontolás alá veszik a követelménytervezők a rendszer egy prototípusával készülnek, így a végfelhasználóra nem hárul akkora felelősség, a beszélgetés egy konkrét dologról történik, könnyebb kapcsolódni

© Bánsághi Anna

32 of 54


2. előadás

FORGATÓKÖNYVEK szerves részei az agilis módszertanoknak interakció-sorozatok leírásai informális leírás a követelménytervezők és a felhasználók együtt dolgoznak a forgatókönyvek azonosításán és a részletek megragadásán, készíthetők diagramok, képernyőtervek formális leírás struktúráltabb, űrlapokon, kártyákon megírt esemény-sorozatok vagy használati esetek

© Bánsághi Anna

33 of 54


2. előadás

FORGATÓKÖNYVEK ELEMEI induló feltétel mit vár a rendszer, és mit vár a felhasználó a forgatókönyv kezdetén normális működés az interakciók normális menetének leírása ami elromolhat és azt hogyan kezeli a rendszer egyéb tevékenységek amelyek ugyanebben az időben mehetnek végbe rendszerállapot befejezéskor az események lezajlása után milyen állapotban marad a rendszer

© Bánsághi Anna

34 of 54


2. előadás

HASZNÁLATI ESETEK az UML jelölés egyik diagramja üzleti vagy rendszer szempontú, magasszintű áttekintése a rendszer funkcióinak, az aktorok és a funkciók közötti interakcióknak a rendszerrel szemben támasztott követelmények lényegét ragadják meg, nem vesznek el a részletekben a rendszer fejlesztésében résztvevő összes szereplő számára hasznosak, mert megadják a végső célt

© Bánsághi Anna

35 of 54


2. előadás

A DIAGRAM ÉPÍTŐKÖVEI aktor a rendszerrel interakcióba lépő személy, szervezet vagy külső rendszer használati eset az aktor számára értéket előállító funkció (valamely művelet-együttes), melynek végrehajtása a rendszer és egy külső aktor közötti üzenetváltást kíván kapcsolat aktorok, használati esetek közötti kapcsolatok (társítás, azaz asszociáció, öröklődés, függőség) rendszer határoló keret a kereten belüli használati esetek a rendszer részei, amelyek azon kívül vannak, azok nem

© Bánsághi Anna

36 of 54


2. előadás

KAPCSOLAT FAJTÁK társítás (asszociáció) közötti kapcsolat

aktorok és használati esetek

általánosítás aktorok közötti vagy használati esetek közötti öröklődési kapcsolat tartalmazás tekinthetjük úgy. mint egy alprogramhívást, felbontjuk a használati esetet alfunkciókra (al-használati esetekre) kiterjesztés tekinthetjük úgy, mint egy hardver megszakítást, valamilyen feltételtől függően végrehajtott funkció, nem tudjuk, hogy be fog-e következni, és azt sem, hogy mikor

© Bánsághi Anna

37 of 54


2. előadás

HASZNÁLATI ESET TERVEZÉSE 1. beazonosítjuk az összes lehetséges aktort 2. megadjuk az aktorok és a használati esetek közötti társításokat: ha egy aktor részt vesz egy használati eset inicializálásban, információt szolgáltat vagy kap attól, akkor van közöttük kapcsolat 3. észrevesszük az aktorok közötti hasonlóságokat, és a használati esetek közötti hasonlóságokat (származtatás) 4. megadjuk az aktorok közötti kapcsolatokat (általánosítás) 5. megadjuk a használati esetek közötti kapcsolatokat (általánosítás, függőség)

© Bánsághi Anna

38 of 54


2. előadás

ÜZLETI HASZNÁLATI ESET

© Bánsághi Anna

39 of 54


2. előadás

RENDSZER HASZNÁLATI ESET

© Bánsághi Anna

40 of 54


2. előadás

ETNOGRÁFIA az elemző elmélyed a munkakörnyezetben, ahol a rendszert majd használni fogják, megfigyeli a munkát, a munkafolyamatokat, a résztvevők aktuális tevékenységeit felderíti az implicit rendszerkövetelményeket, melyek az embereket érintő tényleges folyamatokat érintik felfedezi a nem nyilvánvaló társadalmi, szervezeti csoportdinamikát, a formális és az informális szerepek közötti különbségeket felfedi a feltételezett és a tényleges munka közötti különbségeket

© Bánsághi Anna

41 of 54


2. előadás

HATÉKONY ETNOGRÁFIA az emberek tényleges munkavégzési módja a résztvevők elbeszéléséből általában nem derül ki, hogy a valóságban hogyan zajlanak a munkafolyamatok, hogyan szeretnék azt optimalizálni, hol lehetne automatizálni együttműködés a különböző szervezeti szinteken, különböző fogalmi rendszerrel rendelkező résztvevők közötti kapcsolatok, a bürokrácia vagy a káosz mértéke más emberek tevékenységeinek számon tartása fel kell deríteni és közös megoldást kell találni a tisztázatlan felelősségi és homályos feladatköröket illetően

© Bánsághi Anna

42 of 54


2. előadás

KÖVETELMÉNYEK SPECIFIKÁLÁSA

© Bánsághi Anna

43 of 54


2. előadás

KÖVETELMÉNYEK SPECIFIKÁLÁSA a rendszer modellezése különböző absztrakciós szinteken történik a különféle olvasók számára (üzleti oldal, végfelhasználók, tervezők, fejlesztők, tesztelők) általában grafikus reprezentációk, melyek leírják: az üzleti folyamatokat a megoldandó problémát a kifejlesztendő rendszert

© Bánsághi Anna

44 of 54


2. előadás

A RENDSZER SZEMSZÖGEI külső (környezeti) a rendszer kontextusát vagy környezetét modellezük interakciós a rendszer és környezete vagy a rendszer komponensei közötti együttműködés modellezése szerkezeti a rendszer statikus tulajdonságait, felépítését, struktúráját és az előforduló adatszerkezeteket modellezük viselkedési a rendszer dinamikus tulajdonságait, a kiváltott és bekövetkező eseményeket, és az azokra való reakciókat modellezük

© Bánsághi Anna

45 of 54


2. előadás

KÖVETELMÉNYEK VALIDÁLÁSA

© Bánsághi Anna

46 of 54


2. előadás

KÖVETELMÉNYEK VALIDÁLÁSA a rendszert leíró követelmények valóban a megrendelő akaratát fejezik ki? cél, hogy megtaláljuk a követelményekkel kapcsolatos problémákat egy szekvenciális folyamatban ezek az ellenőrzések utólag történnek meg, míg egy agilis folyamatban interaktívan, azonnal visszacsatolva

© Bánsághi Anna

47 of 54


2. előadás

ELLENŐRZÉSEK validitás a rendszer profilját alkotó funkciók maguk után vonhatnak számos segédfunkciót, melyekkel a megrendelő kezdetben nem számolt ellentmondás általában ellentmondóak a követelmények, ekkor tudnunk kell, hogy milyen lemondások árán történt a kompromisszum teljesség se többet, se kevesebbet ne tudjon a rendszer, mint amit a követelmények és a megszorítások leírnak megvalósíthatóság technológiai, költségvetési, ütemezési realitások verifikálhatóság úgy kell megírni a követelményhalmazt, hogy azzal bizonyítani lehessen, hogy a rendszer teljesíti az összes követelményt

© Bánsághi Anna

48 of 54


2. előadás

VALIDÁLÁSI TECHNIKÁK felülvizsgálat a követelményhalmaz rendszeres ellenőriztetése a megrendelővel, az elemezőkkel, és a problémák beazonosítása prototípus készítés a rendszer egy végrehajtható modelljét ellenőrzi a megrendelő és a végfelhasználók, mely bemutatja a fő koncepciókat, a tervezési lehetőségeket teszteset készítés ha a tesztet nehéz vagy lehetetlen megtervezni, az általában azt jelzi, hogy a követelményekben probléma van, tanácsos azokat újragondolni

© Bánsághi Anna

49 of 54


2. előadás

4. KÖVETELMÉNYKEZELÉS a rendszerek javulnak, mert a működtetés és a használat során felmerülő hibák karbantartásra kerülnek a rendszerek változnak, mert új megrendelői, végfelhasználói igények jelennek meg a rendszerek fejlődnek, mert a használt módszertanok, technológiák, technikák, szabványok javulnak, fejlődnek a rendszerek bővülnek, mert más rendszerekkel integrálódhatnak, vagy szolgáltatásokat nyújthatnak / vehetnek igénybe

© Bánsághi Anna

50 of 54


2. előadás

KÖVETELMÉNYKEZELÉS TERVEZÉSE követelmények azonosítása minden követelményt egyértelműen azonosítani kell, hogy hivatkozni lehessen rá, illetve a nyomonkövethetőség érdekében változtatáskezelési folyamat a változtatások hatását és költségét becslő eljárás nyomon követhetőség elemei a követelmények közötti, a követelmények és a rendszerterv közötti, illetve a követelmények és az implementáció közötti kapcsolatok követése eszköz támogatás a bonyolult rendszerektől kezdve az egyszerű táblázatkezelőkig

© Bánsághi Anna

51 of 54


2. előadás

NYOMONKÖVETHETŐSÉG források és követelmények között a követelményt indítványozó résztvevő hozzárendelése, és a követelmény szükségességének magyarázata követelmények között függőségi kapcsolatok, egy változtatás mely más követelményekre lesz hatással követelmények és tervek között a rendszertervek, a komponensek, a megvalósított modulok közötti kapcsolatok, a változtatás hogyan fut végig az implementációig

© Bánsághi Anna

52 of 54


2. előadás

VÁLTOZTATÁSKEZELÉS ajánlott minden változtatást azonos módon, egy formális folyamatban kezelni előnye, hogy minden változtatási szándék kezelése konzisztens és ellenőrzött módon történik hátránya, hogy ha sürgősen kell javítani, akkor előbb történik az implementáció, majd utána kell igazítani a követelmény dokumentumokat

© Bánsághi Anna

53 of 54


2. előadás

VÁLTOZTATÁSKEZELÉS FŐ SZAKASZAI problémaelemzés a változtatási szándék és indítvány vizsgálata, validálása, finomítása változtatáselemzés és költségfelmérés a tervezett változtatás hatásának becslése a nyomon követhetőségi információra támaszkodva változtatás implementálása a változtatás végigvezetése kezdve a követelményspecifikációval, a rendszerterveken át, befejezve az implementációval, teszteléssel

© Bánsághi Anna

54 of 54

Bánsághi Anna Bánsághi Anna 1 of 54

Recommend Documents