Követelménykezelés

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

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

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

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

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

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

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

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

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

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

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

↑ 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. [2009. december 16-i dátummal az eredetiből archiválva]. (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

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

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

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?

Kapcsolódó szócikkek

[Stellman05-1] 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.]

[2] Requirements management. UK Office of Government Commerce. [2009. december 16-i dátummal az eredetiből archiválva]. (Hozzáférés: 2009. november 10.)

[PMBOK08-3] A Guide to the Project Management Body of Knowledge, 4th, Project Management Institute (2008). ISBN 978-1-933890-51-7

[4] Gotel, O., Finkelstein, A. An Analysis of the Requirements Traceability Problem Proc. of First International Conference on Requirements Engineering, 1994, pages 94-101

[:0-5] 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

[6] 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

[7] 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

[8] 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

[9] 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

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]