Követelménymérnökség
A követelménymérnökség (RE)[1] a követelmények meghatározásának, dokumentálásának és fenntartásának folyamata[2] 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",[2] 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,[3] 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[4] 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
[szerkesztés | forrásszöveg szerkesztése]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.[5] 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[6] (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.[7]
Problémák
[szerkesztés | forrásszöveg szerkesztése]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.[8]
Kritika
[szerkesztés | forrásszöveg szerkesztése]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.[9] 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[10]
Jegyzetek
[szerkesztés | forrásszöveg szerkesztése]- ↑ Requirements engineering: a roadmap (PDF). ICSE'00. 2000. 35–46. o. doi:10.1145/336512.336523. ISBN 1-58113-253-0.
- 1 2 Maintenance, maintainability, and system requirements engineering.
- ↑ szerk.: Thayer: Software Requirements Engineering, 2nd, IEEE Computer Society Press (1997. március 1.). ISBN 978-0-8186-7738-0
- ↑ Managing the Development of Large Software Systems: Concepts and Techniques (PDF). ICSE'87. 1970. 1–9. o.
- ↑ Sommerville, Ian. Software Engineering, 9th, Addison-Wesley (2009). ISBN 978-0-13-703515-1
- ↑ "Uncovering Requirements With UML Class Diagrams Part 1". tynerblain.com. 2008. március 7. Hozzáférés: 2018. március 14.
- ↑ Hofmann, H.F. (2001). "Requirements engineering as a success factor in software projects". IEEE Software. 18 (4): 58–66. doi:10.1109/MS.2001.936219. ISSN 0740-7459.
- ↑ Méndez Fernández, Daniel (2015). "Naming the pain in requirements engineering: A design for a global family of surveys and first results from Germany". Information and Software Technology. 57: 616–643. doi:10.1016/j.infsof.2014.05.008.
- ↑ Ralph, Paul (2015. május). "Is Requirements Engineering Inherently Counterproductive?". IEEE. doi:10.13140/2.1.3831.6321.
{{cite journal}}: Cite journal requires|journal=(súgó) - ↑ Ralph, P. (2013. szeptember). "The illusion of requirements in software development". Requirements Engineering. 18 (3): 293–296. doi:10.1007/s00766-012-0161-4.
Fordítás
[szerkesztés | forrásszöveg szerkesztése]Ez a szócikk részben vagy egészben a Requirements engineering 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 információk
[szerkesztés | forrásszöveg szerkesztése]- Systems and software engineering -- Life cycle processes --Requirements engineering, 1–94. o.. DOI: 10.1109/IEEESTD.2011.6146379 (2011). ISBN 978-0-7381-6591-2("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