A követelménymérnökség (RE) a követelmények meghatározásának, dokumentálásának és fenntartásának folyamata a mérnöki tervezési folyamatok során. Ez egy gyakran előforduló szerepkör a rendszermérnökségben és a szoftvermérnökségben.
A követelménymérnökség kifejezést valószínűleg először 1964-ben használták a "Maintenance, Maintainability, and System Requirements Engineering", nevű konferenciacikkben, de általános használatra csak az 1990-es évek végén került sor, az IEEE Computer Society 1997 márciusában megjelent oktatóanyagával, valamint a követelménymérnökséggel foglalkozó konferenciasorozat létrehozásával, amelyből a International Requirements Engineering Conference fejlődött.
A vízesésmodellben a követelménymérnökség a fejlesztési folyamat első fázisai között jelenik meg. A későbbi fejlesztési módszereket, beleértve a szoftverekhez használt Rational Unified Process (RUP) módszert is, ami azt feltételezik, hogy a követelménymérnökség a rendszer élettartama alatt folytatódik.
A követelménykezelés, amely a rendszermérnöki gyakorlat részfunkciója, a International Council on Systems Engineering (INCOSE) kézikönyveiben is szerepel.
Tevékenységek A követelménymérnökség a tevékenységek széles skáláján mozognak, a fejlesztendő rendszer típusától és a szervezet alkalmazott konkrét gyakorlatától (gyakorlataitól) függően. Ezek a következők lehetnek:
Követelmények meghatározása vagy követelményfelmérés – A fejlesztők és az érdekelt felek találkoznak; utóbbiakat megkérdezik a szoftvertermékkel kapcsolatos igényeikről és kívánságaikról. Követelményelemzés és tárgyalás – A követelmények azonosítása (beleértve az újakat is, ha a fejlesztés iteratív), és az érdekelt felekkel fennálló konfliktusok feloldása. Mind az írott, mind a grafikus eszközöket (ez utóbbiakat általában a tervezési fázisban használják, de egyesek ebben a szakaszban is hasznosnak találják) sikeresen alkalmazzák segédeszközként. Írásos elemzőeszközök példái: használati esetek és felhasználói történetek . Grafikus eszközökre példák: Unified Modeling Language (UML) és Lifecycle Modeling Language (LML). Rendszermodellezés – Egyes mérnöki területeken (vagy speciális helyzetekben) a terméket teljes mértékben meg kell tervezni és modellezni, mielőtt megkezdődne a gyártása vagy megépítése. Ezért a tervezési fázist előre el kell végezni. Például egy épület tervrajzait ki kell dolgozni, mielőtt bármilyen szerződést jóváhagynának és aláírnának. Sok terület az LML segítségével származtathatja a rendszer modelljét, míg mások UML-t használhatnak. Megjegyzés: Számos területen, például a szoftverfejlesztésben, a legtöbb modellezési tevékenységet tervezési tevékenységként, és nem követelménymérnöki tevékenységként osztályozzák. Követelményspecifikáció – A követelményeket egy hivatalos dokumentumban, a követelményspecifikációban (RS) dokumentálják, amely csak a validáció után válik hivatalossá. Egy RS szükség esetén tartalmazhat írásos és grafikus (modell) információkat is. Példa: Szoftverkövetelmény-specifikáció (SRS). Követelmények validálása – Annak ellenőrzése, hogy a dokumentált követelmények és modellek következetesek-e és megfelelnek-e az érdekelt felek igényeinek. Csak akkor válik hivatalossá az RS, ha a végleges tervezet átmegy az érvényesítési folyamaton. Követelménykezelés – A követelményekkel kapcsolatos összes tevékenység kezelése a kezdetektől fogva, a rendszer fejlesztésének felügyelete, sőt, a használatbavétel után is (pl. változtatások, bővítések stb.).
Ezeket néha időrendi szakaszokként ábrázolják, bár a gyakorlatban ezek a tevékenységek jelentős mértékben összefüggenek.
A követelménymérnökséggel kapcsolatban egyértelműen kimutatták, hogy hozzájárul a szoftverprojektek sikeréhez.
Problémák Egy Németországban végzett korlátozott tanulmány a követelménymérnökség megvalósításával kapcsolatos lehetséges problémáit mutatta be, és megkérdezte hogy ezek tényleges problémák. Az eredményeket nem általánosíthatóként mutatták be, de arra utaltak, hogy a nagyobb észlelt problémák a hiányos követelmények, a változó célok és az időbeli korlátok voltak, amíg a kisebb problémák a kommunikációval kapcsolatos hibák, a nyomon követhetőség hiánya, a terminológiai problémák és a nem egyértelműen elkülöníthető felelősségi körök voltak.
Kritika A probléma strukturálásáról, a követelménymérnökség egyik kulcsfontosságú lépéséről, számos feltételezés született, amelyek ronthatják a tervezési teljesítményt. Egyes kutatások azt feltételezik, hogy ha a követelménytervezési folyamatban hiányosságok lépnek fel, amelyek olyan helyzetet hoznak létre, ahol a követelmények nem léteznek, akkor a szoftverkövetelmények ettől függetlenül létrejöhetnek, mint egy illúzió, amely a tervezési döntéseket tévesen követelményekként hamisítja
Jegyzetek
Fordítás
További információk ("This standard replaces IEEE 830–1998, IEEE 1233–1998, IEEE 1362-1998 - https://standards.ieee.org/ieee/29148/5289/") Systems Engineering Body of Knowledge Requirements Engineering Management Handbook by FAA International Requirements Engineering Board (IREB) IBM Rational Resource Library by IEEE Spectrum
Kategória:Szoftverfejlesztés