A követelménytervezésben a követelményfeltárás azt a gyakorlatot jelenti, hogy a felhasználók, ügyfelek és más érdekelt felek feltárják a rendszer követelményeit.Requirements Engineering A good practice guide, Ramos Rowel and Kurts Alfeche, John Wiley and Sons, 1997 Ezt a gyakorlatot néha követelménygyűjtésnek is nevezik.

A „feltárás” kifejezést azért használják a könyvekben és a kutatásokban, hogy felhívják a figyelmet arra a tényre, hogy a jó követelményeket nem lehet egyszerűen összegyűjteni az ügyféltől, ahogy azt a "követelmények gyűjtése" kifejezés sugallná. A követelmények feltárása nem triviális, mert soha nem lehet biztos abban, hogy minden követelményt megkap a felhasználótól és az ügyféltől, ha csak megkérdezi őket, hogy mit kellene a rendszernek tennie vagy nem tennie (biztonsági és megbízhatósági szempontból). A követelmények feltárásának gyakorlatai közé tartoznak az interjúk, kérdőívek, felhasználói megfigyelések, workshopok, brainstorming, esetek használata, szerepjáték és prototípusok készítése.

Mielőtt a követelményeket elemezni, modellezni vagy specifikálni lehetne, először egy feltárási folyamaton keresztül kell őket összegyűjteni. A követelmények feltárása a követelménytechnikai folyamat része, amelyet általában a követelmények elemzése és specifikációja követ.

A leggyakrabban használt feltárási folyamatok közé tartoznak az érintettekkel való találkozók vagy interjúk. Például egy fontos első találkozó lehet a szoftvermérnökök és az ügyfelek között, ahol megvitatják a követelményekkel kapcsolatos nézeteiket.

A követelmények feltárási folyamata egyszerűnek tűnhet: kérdezzük meg az ügyfelet, a felhasználókat és másokat, hogy mik a rendszer vagy termék célkitűzései, mit kell elérni, hogyan illeszkedik a rendszer vagy termék az üzleti igényekhez, és végül, hogyan használják majd a rendszert vagy terméket napi szinten. Azonban felmerülhetnek olyan problémák, amelyek bonyolítják a folyamatot.

1992-ben Christel és Kang azonosították azokat a problémákat, amelyek a követelmények feltárásának kihívásait jelzik:

Hatóköri problémák. A rendszer határa rosszul van meghatározva, vagy az ügyfelek/felhasználók szükségtelen műszaki részleteket adnak meg, amelyek inkább összezavarhatják, nem pedig tisztázzák a rendszer általános céljait. Megértési problémák. Az ügyfelek/felhasználók nem teljesen biztosak abban, hogy mire van szükségük, rosszul ismerik számítástechnikai környezetük képességeit és korlátait, nem ismerik teljes mértékben a problémakört, problémáik vannak az igények kommunikálásával a rendszermérnök felé, kihagyják az információkat amelyről úgy gondolják, hogy „nyilvánvaló”, olyan követelményeket határoz meg, amelyek ütköznek más ügyfelek/felhasználók igényeivel, vagy olyan követelményeket ad meg, amelyek nem egyértelműek vagy tesztelhetetlenek. A volatilitás problémái. A követelmények idővel változnak. A változás mértékét néha a követelmények változékonysági szintjének nevezik.

A követelmények minősége a következő megközelítésekkel javítható:

Vizualizáció. Olyan eszközök használata, amelyek elősegítik a kívánt végtermék jobb megértését, mint például a vizualizáció és a szimuláció. Következetes nyelvezet. Egyszerű, következetes definíciók használata a természetes nyelven leírt követelményekhez, és a vállalatnál elterjedt üzleti terminológia használata. Irányelvek. A gyűjtési technikákat és a begyűjtendő követelmények típusait leíró szervezeti irányelvek követése. Ezeket az irányelveket ezután következetesen alkalmazzák a projektekben. A sablonok következetes használata. Következetes modellek és sablonok készítése a követelmények dokumentálásához. Függőségek dokumentálása. A követelmények közötti függőségek és összefüggések dokumentálása. Változások elemzése. A követelmények változásainak kiváltó ok-elemzése és a korrekciós intézkedések végrehajtása.

Irányelvek 1997-ben Sommerville és Sawyer egy sor iránymutatást javasoltak a követelmények megfogalmazásához, hogy kezeljék a Christel és Kang által azonosítottakat:Sommerville and Sawyer, 1997.

Mérje fel a javasolt rendszer üzleti és műszaki megvalósíthatóságát Azonosítsa azokat az embereket, akik segítenek meghatározni a követelményeket és megérteni szervezeti elfogultságukat Határozza meg azt a műszaki környezetet (pl. számítástechnikai architektúra, operációs rendszer, távközlési igények), amelybe a rendszer vagy termék kerül Azonosítsa a "tartományi megszorításokat" (azaz az üzleti környezetnek az alkalmazástartományra jellemző jellemzőit), amelyek korlátozzák az építendő rendszer vagy termék funkcionalitását vagy teljesítményét. Határozzon meg egy vagy több követelményfeltárási módszert (pl. interjúk, fókuszcsoportok, csapattalálkozók) Számos ember bevonása, hogy a követelményeket különböző nézőpontokból határozzák meg; győződjön meg arról, hogy minden rögzített követelményhez meg van határozva az indoklás is Azonosítsa a kétértelmű követelményeket prototípus-készítés jelöltjeként Hozzon létre használati forgatókönyveket vagy használati eseteket, hogy segítsen az ügyfeleknek/felhasználóknak jobban azonosítani a legfontosabb követelményeket

Lépések sorrendje 2004-ben Goldsmith egy „problémapiramist” javasolt, amely „hat lépésből áll, amelyeket egymás után kell végrehajtani”:Goldsmith, 2004. Page 12

Azonosítsa a valódi problémát, lehetőséget vagy kihívást Határozza meg a jelenlegi intézkedés(eke)t, amelyek azt mutatják, hogy a probléma valós Határozza meg a célintézkedés(eke)t annak bizonyítására, hogy a problémát megoldották, és azt, hogy milyen értéket képvisel a probléma megoldása Határozza meg a probléma "ahogy van" okát, mivel ezeket az okokat kell megoldani, nem közvetlenül a problémát Határozza meg azokat az üzleti „igényeket”, amelyeket teljesíteni kell a célintézkedés(ek) teljesítéséhez Határozza meg a terméktervet, hogyan lehet kielégíteni a valós üzleti követelményeket

Goldsmith azonban megjegyzi, hogy a valódi probléma azonosítása „rendkívül nehéz”.Goldsmith, 2004. Page 12

Kiegészítő megközelítések 2008-ban Alexander és Beus-Dukic egy sor kiegészítő megközelítést javasolt a követelmények feltárására:Beus-Dukic, Ljerka; Alexander, Ian (2008). "Learning How To Discover Requirements"

Az érintettek azonosítása Célok modellezése Modellezési kontextus Forgatókönyvek felfedezése (vagy használati esetek ) A „minőségek és korlátok” felfedezése ( nem funkcionális követelmények ) A modellezés indoklása és feltételezései Fogalomdefiníciók írása Mérések elemzése (elfogadási kritériumok) A prioritások elemzése

Alexander és Beus-Dukic azt javasolta, hogy ezeket a megközelítéseket egyénekkel (mint az interjúk során), csoportokkal (például műhelyeknek nevezett fókuszált találkozókon vagy elektronikus találkozórendszereken keresztül), vagy „dolgokból” (termékekből), például prototípusokból lehetne megvalósítani.

Nem funkcionális követelmények 2009-ben Miller több mint 2000 kérdést tartalmazó kérdőívet javasolt a nem funkcionális követelmények feltárására.Miller, 2009. Az ő megközelítése az érdekelt felek profiljának felépítése, majd az érintettek széles körű megkérdezése. A kérdések három részre vannak csoportosítva, amelyek mindegyike a felhasználói igényekre összpontosít:

Működés: mennyire jól használható a rendszer [szerkesztést igényel]? Felülvizsgálat: mennyire egyszerű a hibák kijavítása és a funkciók hozzáadása? Átállás: Mennyire könnyű alkalmazkodni a technikai környezet változásaihoz?

2013-ban Murali Chemuturi azt javasolta, hogy a "Nem Funkcionális Követelmények" helyett az "Kiegészítő Funkcionalitás Követelmények" kifejezést használják, mivel a "nem funkcionális" azt sugallja, hogy "soha nem működik". Másodszor, ezek a követelmények valójában olyan követelményeket teljesítenek, amelyek támogatják a fő vagy alapvető funkcionális követelményeket.

Hivatkozások

Fordítás

Bibliográfia

Gobov, Denys, Huchenko, Inna. (2020). Requirement Elicitation Techniques for Software Projects in Ukrainian IT: An Exploratory Study. http://dx.doi.org/10.15439/2020F16.

Kapcsolódó szócikk Munkalebontási szerkezet

Kategória:Szoftverfejlesztés