Követelmények feltárása

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. 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:

1. 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.
2. 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.
3. 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ó:

1. 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ó.
2. 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.
3. 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.
4. A sablonok következetes használata. Következetes modellek és sablonok készítése a követelmények dokumentálásához.
5. 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.
6. 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:

• 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”:

1. Azonosítsa a valódi problémát, lehetőséget vagy kihívást
2. Határozza meg a jelenlegi intézkedés(eke)t, amelyek azt mutatják, hogy a probléma valós
3. 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
4. Határozza meg a probléma "ahogy van" okát, mivel ezeket az okokat kell megoldani, nem közvetlenül a problémát
5. Határozza meg azokat az üzleti „igényeket”, amelyeket teljesíteni kell a célintézkedés(ek) teljesítéséhez
6. 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”.

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:

• 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. 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:

1. Működés: mennyire jól használható a rendszer [szerkesztést igényel]?
2. Felülvizsgálat: mennyire egyszerű a hibák kijavítása és a funkciók hozzáadása?
3. Á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.

Fordítás

Ez a szócikk részben vagy egészben a Requirements elicitation 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.

Bibliográfia

• Alexander, Ian F.. Discovering Requirements: How to Specify Products and Services. John Wiley (2009. március 1.). ISBN 978-0-470-71240-5 
• Goldsmith, Robin F.. Discovering Real Business Requirements for Software Project Success. Artech House (2004). ISBN 1-58053-771-5 
• Miller, Roxanne E.. The Quest for Software Requirements: Probing Questions to Bring Nonfunctional Requirements Into Focus; Proven Techniques to Get the Right Stakeholder Involvement. MavenMark Books (2009). ISBN 978-1-59598-067-0 
• Sommerville, Ian. Requirements Engineering: A Good Practice Guide. John Wiley (1997. május 1.). ISBN 0-471-97444-7 
• 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