Ugrás a tartalomhoz

Követelmények feltárása

A Wikipédiából, a szabad enciklopédiából

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

  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

[szerkesztés]

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

  • 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

[szerkesztés]

2004-ben Goldsmith egy „problémapiramist” javasolt, amely „hat lépésből áll, amelyeket egymás után kell végrehajtani”:[4]

  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”.[4]

Kiegészítő megközelítések

[szerkesztés]

2008-ban Alexander és Beus-Dukic egy sor kiegészítő megközelítést javasolt a követelmények feltárására:[5]

  • 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.[5]

Nem funkcionális követelmények

[szerkesztés]

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

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

Hivatkozások

[szerkesztés]
  1. ↑ Requirements Engineering A good practice guide, Ramos Rowel and Kurts Alfeche, John Wiley and Sons, 1997
  2. ↑ PMI Requirements CoP Webinar on Requirements Quality
  3. ↑ Sommerville and Sawyer, 1997.
  4. ↑ a b Goldsmith, 2004. Page 12
  5. ↑ a b Beus-Dukic, Ljerka; Alexander, Ian (2008). "Learning How To Discover Requirements"
  6. ↑ a b Miller, 2009.
  7. ↑ 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 

Fordítás

[szerkeszté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

[szerkesztés]

Kapcsolódó szócikk

[szerkesztés]
A lap eredeti címe: „https://hu.wikipedia.org/wiki/Követelmények_feltárása”