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ésA 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ésA 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ésA 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ésAz 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ésA 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ésFelté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ésA 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ésAligha 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ésA 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ésEgy 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ésEz 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?