Követelménykezelés
 |
Ez a szócikk vagy szakasz lektorálásra, tartalmi javításokra szorul. |
A követelménykezelés az a folyamat, amely során a követelményeket dokumentálják, elemzik, nyomon követik, rangsorolják és egyeztetik, majd a változásokat ellenőrzik és kommunikálják az érintett felekkel. Ez egy folyamatos eljárás a projekt teljes időtartama alatt. A követelmény egy olyan képesség, amelynek a projekt eredményének (termék vagy szolgáltatás) meg kell felelnie.
Áttekintés[szerkesztés]
A követelménykezelés célja annak biztosítása, hogy egy szervezet dokumentálja, igazolja és megfeleljen ügyfelei és belső vagy külső érintettjei igényeinek és elvárásainak.[1] A követelménykezelés azzal kezdődik, hogy elemzik és feltárják a szervezet céljait és korlátait. A követelménykezelés továbbá magában foglalja a követelményekre vonatkozó tervezés támogatását, a követelmények integrálását és a velük való munkavégzés szervezését (a követelmények attribútumait), valamint a követelményeknek megfelelő információk kapcsolatát és az ezekre vonatkozó változtatásokat.
Az így létrehozott nyomon követhetőség a követelmények kezelésében használatos, hogy jelentést adjon a vállalati és érdekelt felek érdekeinek teljesüléséről a megfelelés, teljesség, lefedettség és következetesség szempontjából. A nyomon követhetőségek támogatják a változáskezelést is a követelménykezelés részeként, mivel segítenek megérteni a változások hatásait a követelményeken vagy más kapcsolódó elemek (például a funkcionális architektúrához való kapcsolatok révén történő funkcionális hatások) keresztül, és megkönnyítik ezen változások bevezetését.[2]
A követelménykezelés magában foglalja a projektcsapat tagjai és az érintettek közötti kommunikációt, valamint a követelményváltozásokhoz való alkalmazkodást a projekt teljes időtartama alatt.[3] Annak érdekében, hogy az egyik követelményosztály ne írja felül a másikat, elengedhetetlen a fejlesztőcsapat tagjai közötti folyamatos kommunikáció. Például a belső alkalmazások szoftverfejlesztése során a vállalkozásnak olyan erős igényei vannak, hogy figyelmen kívül hagyhatja a felhasználói követelményeket, vagy úgy gondolja, hogy a használati esetek létrehozása során a felhasználói követelményeket figyelembe veszik.
Nyomon követhetőség[szerkesztés]
A követelmények nyomon követhetősége a követelmény életútjának dokumentálásával foglalkozik.[4] Lehetővé kell tenni az egyes követelmények eredetének visszakövetését, és ezért a követelménnyel kapcsolatos minden változtatást dokumentálni kell a nyomon követhetőség érdekében.[5] Még a követelmény felhasználásának is nyomon követhetőnek kell lennie a megvalósított funkciók bevezetése és használata után.[5]
A követelmények különböző forrásokból származnak, például az üzleti személytől, aki a terméket rendeli, a marketing menedzsertől és a tényleges felhasználótól. Ezek az emberek mind különböző követelményeket támasztanak a termékkel szemben. A követelménykövetés segítségével egy megvalósított szolgáltatás visszavezethető ahhoz a személyhez vagy csoporthoz, aki a követelményfelismerés során azt kívánta. Ez felhasználható például a fejlesztési folyamat során a követelmény prioritásainak meghatározására,[6] meghatározva, hogy a követelmény mennyire értékes egy adott felhasználó számára. Ez akkor is használható, amikor a bevezetés után a felhasználói tanulmányok kimutatják, hogy egy funkciót nem használnak, hogy megvizsgáljuk, miért volt eredetileg szükséges.
Követelmények[szerkesztés]
A fejlesztési folyamat minden szakaszában vannak kulcsfontosságú követelménykezelési tevékenységek és módszerek. Példaként vegyünk egy szabványos ötfázisú fejlesztési folyamatot, amely az alábbi szakaszokból áll: Vizsgálat, Megvalósíthatóság, Tervezés, Kivitelezés és Tesztelés, valamint Kiadás.
Vizsgálat[szerkesztés]
Az Investigationben a követelmények első három osztályát a felhasználóktól, a vállalkozástól és a fejlesztőcsapattól gyűjtik össze. Minden területen hasonló kérdéseket tesznek fel; mik a célok, mik a korlátok, mik a jelenlegi eszközök vagy folyamatok, stb. Csak akkor lehet funkcionális követelményeket kialakítani, ha ezeket a követelményeket jól megértjük.
Általában a követelményeket nem lehet teljes mértékben meghatározni a projekt elején. Néhány követelmény változni fog, akár azért, mert egyszerűen nem kerültek feltárásra, akár azért, mert belső vagy külső erők a projekt közepén hatást gyakorolnak rá.
A vizsgálati szakasz leszállítandó dokumentuma egy követelménydokumentum, amelyet a csapat minden tagja jóváhagyott. Később, a fejlesztések sűrűjében ez a dokumentum kritikus fontosságú lesz a hatókör elcsúszásának vagy a szükségtelen változtatások megelőzésében. Ahogy a rendszer fejlődik, minden új funkció új lehetőségek világát nyitja meg, így a követelményspecifikáció az eredeti elképzeléshez rögzíti a csapatot, és lehetővé teszi a hatókör változtatásának kontrollált megbeszélését.
Míg sok szervezet még mindig csak dokumentumokat használ a követelmények kezelésére, mások szoftveres eszközöket alkalmaznak a követelmények bázisvonalainak kezelésére. Ezek az eszközök lehetővé teszik a követelmények adatbázisban történő kezelését, és általában olyan funkciókkal rendelkeznek, amelyek automatizálják a nyomon követhetőséget (például lehetővé teszik elektronikus kapcsolatok létrehozását a szülő- és gyermekkövetelmények, vagy a tesztesetek és a követelmények között), valamint az elektronikus bázisvonal létrehozását, a verziókezelést és a változáskezelést. Az ilyen eszközök általában tartalmaznak egy export funkciót, amely lehetővé teszi egy specifikációs dokumentum létrehozását a követelményadatok szabványos dokumentumalkalmazásba történő exportálásával.
Megvalósíthatóság[szerkesztés]
A megvalósíthatóság szakaszban meghatározzák a követelmények költségeit. A felhasználói követelmények esetében az aktuális munkaköltségeket összehasonlítják a jövőbeli, az új rendszer bevezetése utáni költségekkel. Ilyen kérdéseket tesznek fel: „Mennyibe kerülnek jelenleg az adatbevitel hibái?” vagy „Mennyi a selejt költsége az aktuális interfész használata miatti kezelői hibák miatt?” Valójában az új eszköz szükségessége gyakran akkor válik nyilvánvalóvá, amikor ezek a kérdések a szervezet pénzügyi szakembereinek figyelmébe kerülnek.
Az üzleti költségek a következőket tartalmazzák: „Melyik osztálynak van erre a költségvetése?” „Mi az új termék várható megtérülési rátája a piacon?” „Mi a belső megtérülési ráta a képzési és támogatási költségek csökkentésében, ha új, könnyebben használható rendszert készítünk?”
A technikai költségek a szoftverfejlesztési költségekhez és a hardverköltségekhez kapcsolódnak. – Megfelelő embereink vannak az eszköz létrehozásához? „Szükségünk van új berendezésekre a kiterjesztett szoftverszerepek támogatásához?” Ez utóbbi kérdés fontos típus. A csapatnak meg kell vizsgálnia, hogy a legújabb automatizált eszközök elegendő feldolgozási teljesítményt biztosítanak-e ahhoz, hogy a terhek egy részét a felhasználóról a rendszerre hárítsák át, és ezzel az emberek időt takarítanak meg.
Ez a kérdés rámutat a követelménykezelés egyik alapvető pontjára is. Egy ember és egy eszköz egy rendszert alkotnak, és ez a felismerés különösen fontos, ha az eszköz egy számítógép vagy egy új alkalmazás a számítógépen.Az emberi elme hiányos adatokkal jeleskedik a trendek párhuzamos feldolgozásában és értelmezésében. A CPU kiemelkedik a soros feldolgozásban és a pontos matematikai számításokban. A szoftverprojektek követelménykezelési erőfeszítéseinek átfogó célja tehát az lenne, hogy az automatizált munka a megfelelő processzorhoz kerüljön hozzárendelésre. Például: „Ne emlékeztesse az emberrel, hogy hol van a felületen. Állítsa be, hogy az interfész mindig jelentse az ember tartózkodási helyét a rendszerben.” Vagy „Ne kényszerítse az embert, hogy ugyanazokat az adatokat két képernyőn írja be. A rendszer tárolja az adatokat, és szükség szerint töltse ki a második képernyőt."
A megvalósíthatósági szakasz eredménye a projekt költségvetése és ütemezése.
Tervezés[szerkesztés]
Feltéve, hogy a költségeket pontosan határozták meg, és az elérendő előnyök kellően nagyok, a projekt továbbléphet a tervezési szakaszba. A tervezésben a fő követelménykezelési tevékenység a tervezés eredményeinek összehasonlítása a követelménydokumentummal, hogy megbizonyosodjon arról, hogy a munka hatókörében marad.
Ismét a rugalmasság a legfontosabb a sikerhez. Íme egy klasszikus történet a terjedelem változásáról a stream közepén, amely valójában jól működött. A Ford autótervezői a 80-as évek elején arra számítottak, hogy a benzin ára eléri a gallononkénti 3,18 dollárt az évtized végére. A Ford Taurus tervezésének felénél az árak körülbelül 1,50 dollárra összpontosultak gallononként. A tervezőcsapat úgy döntött, hogy nagyobb, kényelmesebb és erősebb autót építhetnek, ha a benzinárak alacsonyak maradnak, ezért újratervezték az autót. A Taurus piacra dobása országos eladási rekordokat döntött az új autó megjelenésekor, elsősorban azért, mert olyan tágas és kényelmes volt vezetni.
A legtöbb esetben az eredeti követelményektől való ilyen mértékű eltérés nem működik. Így a követelményspecifikációs dokumentum kulcsfontosságú eszközzé válik, amely segíti a csapatot a tervezési változtatásokkal kapcsolatos döntések meghozatalában.[7]
Kivitelezés és tesztelés[szerkesztés]
A kivitelezési és tesztelési szakaszban a követelménykezelés fő tevékenysége annak biztosítása, hogy a munka és a költségek az ütemterv és a költségvetés keretein belül maradjanak, valamint hogy a kialakuló eszköz valóban megfeleljen a kitűzött követelményeknek. Ebben a szakaszban az egyik fő eszköz a prototípus készítése és az iteratív tesztelés. Egy szoftveralkalmazás esetében a felhasználói felület papíron megtervezhető és tesztelhető potenciális felhasználókkal, miközben a szoftver keretrendszere épül. Ezeknek a teszteknek az eredményeit egy felhasználói felület tervezési útmutatóban rögzítik, és a tervezőcsapatnak adják át, amikor készen állnak a felület fejlesztésére.
Ennek a szakasznak egy fontos aspektusa az ellenőrzés. Ez az erőfeszítés azt ellenőrzi, hogy a követelményt helyesen valósították-e meg. Négy ellenőrzési módszer létezik: elemzés, ellenőrzés, tesztelés és bemutatás. Például a numerikus szoftverfuttatási eredmények vagy a hálózati teszt áteresztőképessége analitikai bizonyítékot szolgáltat arra, hogy a követelmény teljesült. A szállítói dokumentáció vagy specifikációs lapok ellenőrzése szintén igazolja a követelményeket. A szoftver laboratóriumi környezetben történő tesztelése vagy bemutatása szintén igazolja a követelményeket: a teszt típusú ellenőrzés akkor történik, amikor a laboratórium (vagy a tesztelt rendszer) normál részét nem képező tesztberendezést használnak. Az átfogó teszteljárások, amelyek körvonalazzák a lépéseket és azok elvárt eredményeit, világosan meghatározzák, mit kell látni a lépés végrehajtása eredményeként. Miután a lépést vagy lépéssorozatot befejezték, az utolsó lépés elvárt eredményei megmutatják, mit láttak, majd azonosítják, hogy mely követelmény(eke)t igazoltak (szám szerint meghatározva). A követelményszám, cím és szöveg egy másik helyen van összekapcsolva a tesztdokumentumban.
Követelmények változáskezelése[szerkesztés]
Aligha lenne bármely szoftverfejlesztési projekt befejezve anélkül, hogy ne kérnének változtatásokat a projekten. A változások eredhetnek abból, hogy változik az a környezet, amelyben a kész terméket használni kívánják, üzleti változásokból, szabályozási változásokból, az eredeti követelménymeghatározás hibáiból, a technológia korlátaiból, a biztonsági környezet változásaiból és így tovább. A követelményváltozás-menedzsment tevékenységei közé tartozik az érintettek változási kérelmeinek fogadása, a beérkezett változtatási kérelmek rögzítése, a megvalósítás kívánatosságának és folyamatának elemzése és meghatározása, a változtatási kérelem végrehajtása, a végrehajtás minőségbiztosítása és a változtatási kérelem lezárása. Ezt követően a változtatási kérelmek adatait össze kell állítani, elemezni, megfelelő mérőszámokat levezetni és beilleszteni a szervezeti tudástárba.[8]
Kiadás[szerkesztés]
A követelménykezelés nem ér véget a termék kiadásával. Ettől a ponttól kezdve az alkalmazás elfogadhatóságáról érkező adatokat összegyűjtik, és a következő generáció vagy kiadás Vizsgálati szakaszába táplálják be. Így a folyamat újra kezdődik.
Eszközök[szerkesztés]
Egy eszköz beszerzése a követelménykezelés támogatására nem kis feladat, és egy átfogóbb folyamatfejlesztési kezdeményezés részeként kell végrehajtani. Régóta elterjedt az a nézet, hogy egy eszköz, ha egyszer megvásárolják és telepítik egy projektben, képes kezelni az összes követelménykezeléssel kapcsolatos igényt. Azonban egy követelménykezelést támogató eszköz megvásárlása vagy kifejlesztése költséges döntés lehet. A szervezeteket megterhelhetik a drága támogatási szerződések, az aránytalan erőfeszítések félreirányulhatnak az eszköz használatának elsajátítására és az egyedi igények kielégítésére történő konfigurálására, a nem megfelelő használat pedig hibás döntésekhez vezethet. A szervezeteknek egy fokozatos folyamatot kell követniük, hogy döntéseket hozzanak azokról az eszközökről, amelyek támogatják sajátos szükségleteiket a fejlesztési folyamatuk és eszközeik szélesebb összefüggésében.[9] Az eszközök a Követelmények nyomon követése című cikkben találhatók.
Jegyzetek[szerkesztés]
- ↑ Stellman, Andrew. Applied Software Project Management [archivált változat]. O'Reilly Media (2005). ISBN 978-0-596-00948-9 [archiválás ideje: 2015. február 9.]
- ↑ Requirements management. UK Office of Government Commerce. (Hozzáférés: 2009. november 10.)
- ↑ A Guide to the Project Management Body of Knowledge, 4th, Project Management Institute (2008). ISBN 978-1-933890-51-7
- ↑ Gotel, O., Finkelstein, A. An Analysis of the Requirements Traceability Problem Proc. of First International Conference on Requirements Engineering, 1994, pages 94-101
- ↑ a b Gotel, Orlena.szerk.: Cleland-Huang: Software and Systems Traceability (angol nyelven). Springer London, 3–22. o.. DOI: 10.1007/978-1-4471-2239-5_1 (2012. január 1.). ISBN 9781447122388
- ↑ Rempel, Patrick.szerk.: Fricker: Requirements Engineering: Foundation for Software Quality, Lecture Notes in Computer Science (angol nyelven). Springer International Publishing, 81–97. o.. DOI: 10.1007/978-3-319-16101-3_6 (2015. március 23.). ISBN 9783319161006
- ↑ Ralph, P., and Wand, Y. A Proposal for a Formal Definition of the Design Concept. In, Lyytinen, K., Loucopoulos, P., Mylopoulos, J., and Robinson, W., (eds.), Design Requirements Engineering: A Ten-Year Perspective: Springer-Verlag, 2009, pp. 103-136
- ↑ Chemuturi, M.. Requirements Engineering and Management for Software Development Projects. DOI: 10.1007/978-1-4614-5377-2 (2013). ISBN 978-1-4614-5376-5
- ↑ Gotel, Orlena.szerk.: Cleland-Huang: Software and Systems Traceability (angol nyelven). Springer London, 43–68. o.. DOI: 10.1007/978-1-4471-2239-5_3 (2012. január 1.). ISBN 9781447122388
Fordítás[szerkesztés]
Ez a szócikk részben vagy egészben a Requirements management című angol Wikipédia-szócikk ezen változatának fordításán alapul. Az eredeti cikk szerkesztőit annak laptörténete sorolja fel. Ez a jelzés csupán a megfogalmazás eredetét és a szerzői jogokat jelzi, nem szolgál a cikkben szereplő információk forrásmegjelöléseként.
További irodalom[szerkesztés]
- CMMI Product Team (2006. augusztus 1.). „CMMI for Development, Version 1.2” (PDF), Kiadó: Software Engineering Institute. (Hozzáférés: 2008. január 22.)
- Colin Hood, Simon Wiedemann, Stefan Fichtinger, Urte Pautz Requirements Management: Interface Between Requirements Development and All Other Engineering Processes Springer, Berlin 2007, ISBN 3-540-47689-X
- Requirements Management - A Practice Guide, PMI
További információk[szerkesztés]
- Egyesült Királyság Kormányzati Kereskedelmi Hivatala (OGC) – Követelmények kezelése (archívum; Az OGC webhelye 2011. október 1-jén megszűnt)
- CDC Unified Process Practices Guide – Követelménykezelés
- International Requirements Engineering Board (IREB)
- Mi az a követelménykezelés?