Szerkesztő:BubblyJubbly/Követelményelemzés

A rendszermérnökségben és a szoftvermérnökségben a követelményelemzés azokra a feladatokra összpontosít, amelyek meghatározzák az új vagy módosított termék vagy projekt kielégítésének szükségleteit vagy feltételeit, figyelembe véve a különböző érdekeltek esetlegesen ellentmondó követelményeit, elemezve, dokumentálva, hitelesítve és kezelve a szoftvereket, rendszerkövetelményeket.^[2]

A követelmények elemzése kritikus fontosságú egy rendszer vagy szoftver projekt sikere vagy kudarca szempontjából.^[3] A követelményeknek dokumentáltnak, kereshetőnek, mérhetőnek, tesztelhetőnek, nyomon követhetőnek kell lenniük, kapcsolódniuk kell a meghatározott üzleti igényekhez vagy lehetőségekhez, és a rendszer tervezéséhez elegendő részletességgel kell meghatározni.

Áttekintés

Fogalmilag a követelményelemzés háromféle tevékenységet foglal magában:

Feltételezési követelmények: (pl. A projekt alapokmánya vagy meghatározása), üzleti folyamatok dokumentálása és az érdekelt felekkel folytatott interjúk. Ezt néha követelménygyűjtésnek vagy követelményfelfedezésnek is nevezik.
Felvételi követelmények: A követelményeket különféle formában lehet dokumentálni, általában összefoglaló listát is beleértve, és tartalmazhatnak természetes nyelvű dokumentumokat, használati eseteket, felhasználói történeteket, folyamatspecifikációkat és különféle modelleket, beleértve az adatmodelleket is.
A követelmények elemzése: annak meghatározása, hogy a megállapított követelmények világosak-e, teljesek-e, egyértelműek-e, tömörek-e, érvényesek-e, következetesek és egyértelműek-e, valamint a látszólagos konfliktusok megoldása. Az elemzés tartalmazhat méretezési követelményeket is.

A követelményelemzés hosszú és fárasztó folyamat lehet, amelynek során sok kényes pszichológiai készség vesz részt. Az új rendszerek megváltoztatják a környezetet és az emberek közötti kapcsolatokat, ezért fontos meghatározni az összes érdekelt felet, figyelembe venni minden igényüket és biztosítani, hogy megértsék az új rendszerek következményeit. Az elemzők többféle technikát alkalmazhatnak arra, hogy megtudják az ügyfél elvárásait. Ez a folyamat magába foglalhatja a forgatókönyvek kidolgozását (az agilis módszerekben felhasználói történetekként ábrázolva), a felhasználási esetek azonosítását, a munkahelyi megfigyelés vagy az etnográfia használatát, interjúk tartását vagy fókuszcsoportokat (ebben az összefüggésben találóbban megnevezve: követelményműhelyek vagy követelmények felülvizsgálati munkamenetek) és követelménylisták készítése. A prototípus-készítés felhasználható az érdekelt felek számára bemutatható példa-rendszer kidolgozására. Szükség esetén az elemző ezen módszerek kombinációját alkalmazza az érdekelt felek pontos követelményeinek megállapításához, hogy az üzleti igényeknek megfelelő rendszert hozzanak létre. A követelmények minősége javítható ezeken és más módszereken keresztül.

Megjelenítés. Olyan eszközök használata, amelyek elősegítik a kívánt végtermék jobb megértését, például vizualizáció és szimuláció.
A sablonok következetes használata. A követelmények dokumentálásához következetes modellek és sablonok készítése.
A függőségek dokumentálása. A követelmények közötti függőségek és összefüggések, valamint az esetleges feltételezések és összegyűlések dokumentálása.

Követelmények elemzés témák

Az érdekelt felek azonosítása

Lásd az érdekelt felek elemzését a rendszer iránt érdeklődő személyek vagy szervezetek (jogi személyek, például vállalatok, szabványügyi testületek) megismeréséért. Közvetlenül vagy közvetve befolyásolhatja őket. Az 1990-es években a fő új hangsúly az érdekelt felek azonosítására irányult. Egyre inkább elismerték, hogy az érdekelt felek nem korlátozódnak az elemzőt alkalmazó szervezetre. Érdekelt felek lehetnek a következők:

bárki, aki üzemelteti a rendszert (normál és karbantartó üzemeltetők)
bárki, aki profitál a rendszerből (funkcionális, politikai, pénzügyi és társadalmi kedvezményezettek)
bárki, aki részt vesz a rendszer megvásárlásában vagy beszerzésében. Tömeges piaci termékszervezésben a termékmenedzsment, a marketing és néha az értékesítés helyettesítő fogyasztóként (tömegpiaci vásárlók) irányítja a termék fejlesztését.
a rendszer szempontjait szabályozó szervezetek (pénzügyi, biztonsági és egyéb szabályozók)
a rendszerrel szemben álló emberek vagy szervezetek (negatívan érdekelt felek; lásd még a Visszaélés esetét)
olyan szervezetekért felelős szervezetek, amelyek kapcsolódnak a tervezett rendszerhez.
azok a szervezetek, amelyek horizontálisan integrálódnak a szervezettel, akik számára az elemző tervezi a rendszert.

Közös követelmények kidolgozása (JRD)

A követelményeknek gyakran vannak olyan funkcionális vonatkozásai, amelyek ismeretlenek az egyes érdekelt felek számára, és gyakran hiányoznak vagy hiányosan vannak meghatározva az érintettek interjúi során. Ezeket a keresztfunkcionális következményeket kiválthatja úgy, hogy JRD-foglalkozásokat végeznek ellenőrzött környezetben, képzett segítőként (üzleti elemző, „Business Analyst” pozícióban) elősegítve, ahol az érdekelt felek részt vesznek a megbeszéléseken a követelmények előidézése, a részletek elemzése és a keresztfunkcionális vonatkozások feltárása érdekében. Egy dedikált írnoknak jelen kell lennie a vita dokumentálásához, felszabadítva az üzleti elemzőt, hogy a beszélgetést olyan irányba vezesse, amely megfelelő követelményeket generál, amelyek megfelelnek a munkamenet céljának.

A JRD munkamenetek analógak a közös alkalmazástervezési munkamenetekkel. Az előbbiben a munkamenetek olyan követelményeket támasztanak, amelyek a tervezést irányítják, míg az utóbbiak az előírt követelmények kielégítése érdekében megvalósítandó sajátos tervezési jellemzőket.

Szerződés-jellegű követelménylisták

A követelmények dokumentálásának egyik hagyományos módja a szerződés-jellegű követelménylista. Egy bonyolult rendszerben az ilyen követelménylisták akár több száz oldalig terjedhetnek.

A megfelelő metafora egy rendkívül hosszú bevásárló lista lenne. Az ilyen felsorolások a modern elemzésben nagyon kedvezőtlenek; mivel látványosan sikertelennek bizonyultak céljaik elérésében, de a mai napig találkozhatunk velük.

Előnyei

Biztosítja a követelmények ellenőrzőlistáját.
Biztosítson szerződést a projekt szponzora(i) és a fejlesztők között.
Egy nagy rendszer magas szintű leírást nyújthat, amelyből alacsonyabb szintű követelményeket lehet levezetni.

Hátrányai

Az ilyen listák több száz oldalra terjedhetnek. Nem célja, hogy a kívánt alkalmazás olvasóbarát leírásaként szolgáljon.
Az ilyen követelménylisták felsorolják az összes követelményt, ezért kevés a kontextus. Az üzleti elemző a követelmények kontextusát felveheti a kísérő tervdokumentációba.
- Ennek az absztrakciónak nem célja annak leírása, hogy a követelmények hogyan illeszkednek egymáshoz.
- Előfordulhat, hogy a lista nem tükrözi a követelmények közötti kapcsolatokat és függőségeket. Habár a lista megkönnyíti az egyes elemek rangsorolását, egy elem eltávolítása a kontextusból használhatatlanná teheti az egész használati esetet vagy üzleti követelményeket.
- A lista nem váltja ki a követelmények körültekintő felülvizsgálatának szükségességét az érdekelt felekkel annak érdekében, hogy jobban meg lehessen érteni a kívánt rendszer / alkalmazás tervezésének következményeit.
Egy lista létrehozása nem garantálja annak teljességét. Az üzleti elemzőnek jóhiszemű erőfeszítéseket kell tennie egy lényegében átfogó lista felkutatása és összegyűjtése érdekében, és az érdekelt felekre kell támaszkodnia a hiányzó követelmények feltárásában.
Ezek a listák hamis érzetet kelthetnek az érdekelt felek és a fejlesztők között; az üzleti elemzők kritikus fontosságúak a fordítási folyamat szempontjából.
A fejlesztési és tesztelési folyamat megkezdése előtt szinte lehetetlen feltárni az összes funkcionális követelményt. Ha ezeket a listákat változatlan szerződésként kezelik, akkor a fejlesztési folyamat során felmerülő követelmények vitatható változási kérelmet generálhatnak.

Alternatíva a követelménylistára

A követelménylisták alternatívájaként az agilis szoftverfejlesztés felhasználói történetek alapján javasol követelményeket a mindennapi nyelvben.

Mérhető célok

A bevált gyakorlatok a követelmények összeállítását csupán nyomokként veszik fel, és többször felteszik a "miért?" kérdést, amíg a tényleges üzleti célokat fel nem fedezik. Az érdekelt felek és a fejlesztők ezután teszteket dolgozhatnak ki annak mérésére, hogy az egyes célok milyen szintet értek el eddig. Az ilyen célok lassabban változnak, mint a konkrét, de nem mérhető követelmények hosszú listája. Miután meghatározták a kritikus, kimért célok kis csoportját, a gyors prototípus-készítés és a rövid iteratív fejlesztési fázisok már jóval a projekt fele előtt elérhetik az érintettek tényleges értékét.

Prototípusok

A prototípus egy olyan számítógépes program, amely egy másik számítógépes program tulajdonságainak egy részét mutatja be, lehetővé téve a felhasználók számára, hogy egy még nem elkészített alkalmazást vizualizáljanak. A prototípus népszerű formája a makett, amely segít a jövőbeli felhasználóknak és más érdekelteknek képet kapni arról, hogy milyen lesz a rendszer. A prototípusok megkönnyítik a tervezési döntések meghozatalát, mert az alkalmazás szempontjai láthatók és megoszthatók még az alkalmazás felépítése előtt. A felhasználók és a fejlesztők közötti kommunikáció jelentős javulása gyakran tapasztalható a prototípusok bevezetésével. Az alkalmazások korai megtekintése később kevesebb változáshoz vezetett, és ezáltal jelentősen csökkent az összes költség.

A prototípusok lehetnek sík diagramok (gyakran drótvázak), vagy működő alkalmazások szintetizált funkcionalitást használva. A drótvázak különféle grafikai tervdokumentumokban készülnek, és gyakran eltávolítanak minden színt a tervezésről (azaz szürkeárnyalatos színpalettát használnak) olyan esetekben, amikor a végleges szoftverre várhatóan grafikai tervezés kerül. Ez segít megelőzni azt a zavart, hogy a prototípus reprezentálja-e az alkalmazás végső megjelenését.

Felhasználási esetek

A felhasználási eset a rendszer funkcionális követelményeinek dokumentálására szolgáló struktúra, amely általában szoftvereket tartalmaz, függetlenül attól, hogy az új vagy változtatva van-e. Minden egyes felhasználási eset olyan forgatókönyveket tartalmaz, amelyek átadják, hogy a rendszernek hogyan kell interakcióba lépnie egy emberi felhasználóval vagy egy másik rendszerrel egy adott üzleti cél elérése érdekében. A használati esetek általában elkerülik a technikai szakzsargont, inkább a végfelhasználó vagy a domain szakértő nyelvét részesítik előnyben. A felhasználási eseteket gyakran a követelménymérnökök és az érdekelt felek írják társul.

A felhasználási esetek megtévesztően egyszerű eszközök a szoftverek vagy rendszerek viselkedésének leírására. A használati eset szöveges leírást tartalmaz arról, hogy a felhasználók hogyan kívánnak dolgozni a szoftverrel vagy a rendszerrel. A használati esetek nem írhatják le a rendszer belső működését, és nem magyarázhatják meg a rendszer megvalósításának módját sem. Ehelyett bemutatják a feladat végrehajtásához szükséges lépéseket szekvenciális feltételezések nélkül.

Követelmények specifikációja

A követelményspecifikáció a jelenlegi állami üzleti igényeket érintő felfedezési megállapítások szintézise és ezen igények felmérése annak meghatározása érdekében, hogy mi szükséges az igények kielégítéséhez a fókuszban lévő megoldási körben. A felfedezés, az elemzés és a specifikáció elmozdítja a megértést egy jelenlegi állapotból egy jövőbeli állapotba. A követelményspecifikáció kiterjesztheti a megvalósítandó jövő teljes állapotát és mélységét, vagy megcélozhatja azokat a hiányosságokat, amelyeket pótolni kell, például a kiemelt szoftveres rendszerhibákat és a fejlesztéseket. Tekintettel arra, hogy bármely nagy üzleti folyamat szinte mindig szoftvereket, adatrendszereket és technológiákat alkalmaz, a követelmények specifikációja gyakran társul a szoftverrendszerek összeállításával, vásárlásával, felhőalapú számítási stratégiákkal, a termékekbe vagy eszközökbe beágyazott szoftverekkel vagy más technológiákkal. A követelmények specifikációjának tágabb meghatározása bármilyen megoldási stratégiát vagy komponenst tartalmazhat, vagy ezekre összpontosíthat, mint például képzés, dokumentációs útmutatók, személyzet, marketing stratégiák, felszerelések, kellékek, stb.

A követelmények fajtái

A követelményeket több szempontból is kategorizálják. A következők a műszaki irányítással kapcsolatos követelmények általános kategorizálása:^[1]

Vevői követelmények

Ténymegállapítások és feltételezések, amelyek meghatározzák a rendszer elvárásait a misszió célkitűzéseit figyelembe véve, a környezet, a korlátozások, valamint a hatékonyság és az alkalmasság mértékei (MOE / MOS) szempontjából. Az ügyfelek azok, akik ellátják a rendszertervezés nyolc elsődleges funkcióját, különös hangsúlyt fektetve a kezelőre, mint a legfontosabb ügyfélre. Az üzemeltetési követelmények meghatározzák az alapvető szükségletet, és válaszolnak legalább az alábbi felsorolásban feltett kérdésekre:^[1]

Operatív terjesztés vagy telepítés: Hol fogják használni a rendszert?
Küldetés profil vagy forgatókönyv: Hogyan teljesíti a rendszer a küldetését?
Teljesítmény és kapcsolódó paraméterek: Melyek a kritikus rendszerparaméterek a küldetés teljesítéséhez?
Hasznosítási környezetek : Hogyan kell használni a különféle rendszerelemeket?
Eredményességi követelmények: Mennyire kell eredményesnek lennie a rendszernek küldetésének teljesítésében?
Működési életciklus: Meddig fogja használni a rendszert a felhasználó?
Környezet : Milyen környezetekben várható a rendszer hatékony működése?

Építészeti követelmények: Az építészeti követelmények a rendszer szükséges rendszer architektúrájának azonosításával magyarázzák a tennivalókat.
Szerkezeti követelmények: A strukturális követelmények a rendszer szükséges struktúrájának azonosításával magyarázzák a tennivalókat.
Viselkedési követelmények: A viselkedési követelmények a rendszer szükséges viselkedésének azonosításával magyarázzák a tennivalókat.
Funkcionális követelmények: A funkcionális követelmények elmagyarázzák a tennivalókat az elvégzendő szükséges feladat, művelet vagy tevékenység azonosításával. A funkcionális követelmények elemzését a funkcionális elemzés felső szintű függvényeként kell használni.
Nem funkcionális követelmények: A nem funkcionális követelmények olyan követelmények, amelyek konkrét viselkedés helyett kritériumokat határoznak meg, amelyek felhasználhatók a rendszer működésének megítélésére.
Teljesítménykövetelmények: A küldetés vagy funkció végrehajtásának mértéke; általában mennyiség, minőség, lefedettség, időszerűség vagy készültség szempontjából mérve. A követelmény-elemzés során a teljesítmény-követelményeket („milyen jól kell teljesíteni?”) a rendszer életciklus-tényezői alapján interaktív módon fejlesztik az összes azonosított funkcióban; a becslésük bizonyosságának, a rendszer sikere szempontjából kritikus fontosságának és az egyéb követelményekhez való viszonyuk szempontjából jellemzik.
Tervezési követelmények: A termékekre vonatkozó "build to", "code to" és "buy to" követelmények, valamint a műszaki adatcsomagokban és a műszaki kézikönyvekben megfogalmazott folyamatokra vonatkozó követelmények.
Származtatott követelmények: Követelmények, amelyek implicitek vagy átalakultak a magasabb szintű követelményektől. Például a nagy hatótávolságú vagy a nagy sebességre vonatkozó követelmény a kis tömegre vonatkozó tervezési követelményt eredményezhet.
Kiosztott követelmények: Olyan követelmény, amelyet egy magas szintű követelmény több alacsonyabb szintű követelményre történő felosztásával vagy más módon történő felosztásával állapítanak meg. Példa: Ha két alrendszerből áll egy 100 fontos tétel, akkor 70 font és 30 font súlyigényt eredményezhet a két alacsonyabb szintű elemre.

A jól ismert követelmények kategorizálási modelljei közé tartozik a FURPS és a FURPS +, amelyeket a Hewlett-Packard fejlesztett ki.

Követelményelemzési problémák

Az érdekeltek lehetséges problémái

Steve McConnell, a Gyors fejlesztés című könyvében számos módszert ismertet, amelyekkel a felhasználók gátolhatják a követelmények összegyűjtését:

A felhasználók nem értik, mit akarnak, vagy a felhasználóknak nincs világos elképzelésük a követelményeikről
A felhasználók nem kötelezik el magukat az írásbeli követelmények teljesítése mellett
A felhasználók új követelményekhez ragaszkodnak, miután rögzítették a költségeket és az ütemtervet
A felhasználókkal való kommunikáció lassú
A felhasználók gyakran nem vesznek részt a felülvizsgálatokon, vagy nem képesek erre
A felhasználók technikailag kifinomulatlanok
A felhasználók nem értik a fejlesztési folyamatot
A felhasználók nem tudnak a jelenlegi technológiáról

Ez ahhoz a helyzethez vezethet, amikor a felhasználói követelmények folyamatosan változnak, még akkor is, ha a rendszer vagy a termék fejlesztését megkezdték.

Mérnöki / fejlesztési problémák

A mérnökök és fejlesztők által a követelményelemzés során okozott lehetséges problémák a következők:

A kódírás iránti természetes hajlandóság ahhoz vezethet, hogy a követelmények elemzésének befejezése előtt megkezdődik a megvalósítás, ami a kód megváltoztatásához vezethet és a tényleges követelményeknek való megfeleléshez, amint azok megismerése lehetséges.
A műszaki személyzet és a végfelhasználók szókincsei eltérőek lehetnek. Következésképpen tévesen azt hihetik, hogy tökéletes megállapodásban vannak, amíg a készterméket nem szállítják le.
A mérnökök és fejlesztők megpróbálhatják a követelményeket meglévő rendszerhez vagy modellhez igazítani, ahelyett, hogy az ügyfél igényeinek megfelelő rendszert fejlesztenének ki.

Tesztelt megoldások

A kommunikációs problémák egyik megoldási kísérlete az volt, hogy üzleti vagy rendszerelemzési szakembereket alkalmaztak.

Az 1990-es években bevezetett technikák, mint a prototípus, az egységes modellezési nyelv (UML), a felhasználási esetek és az agilis szoftverfejlesztés, szintén a korábbi módszerekkel felmerülő problémák megoldására szolgálnak.

Ezenkívül új alkalmazásszimulációs osztály vagy alkalmazásdefiníciós eszközök léptek a piacra. Ezeket az eszközöket arra tervezték, hogy áthidalják az üzleti felhasználók és az informatikai szervezet közötti kommunikációs szakadékot - és lehetővé tegyék az alkalmazások „tesztpiacát” is, mielőtt bármilyen kódot előállítanának. Ezen eszközök legjobbjai a következők:

elektronikus táblák az alkalmazásfolyamatok felvázolásához és az alternatívák teszteléséhez
képesség az üzleti logika és az adatigények megragadására
nagy hűségű prototípusok előállításának képessége, amelyek szorosan utánozzák a végső alkalmazást
interaktivitás
képesség kontextus követelmények és egyéb megjegyzések hozzáadására
a távoli és elosztott felhasználók képessége a szimuláció futtatására és interakciójára

Lásd még

Hivatkozások

↑ ^a ^b ^c Systems Engineering Fundamentals Archiválva 2011. július 22-i dátummal a Wayback Machine-ben. Defense Acquisition University Press, 2001
↑ Kotonya, Gerald. Requirements Engineering: Processes and Techniques. Chichester, UK: John Wiley and Sons (1998). ISBN 9780471972082
↑ szerk.: Alain Abran: Chapter 2: Software Requirements, Guide to the software engineering body of knowledge, 2004, Los Alamitos, CA: IEEE Computer Society Press (2005. március 1.). ISBN 0-7695-2330-7. Hozzáférés ideje: 2007. február 8. „It is widely acknowledged within the software industry that software engineering projects are critically vulnerable when these activities are performed poorly.”

Bibliográfia

Software & Systems Requirements Engineering: In Practice. New York: McGraw-Hill Professional (2009). ISBN 978-0-07-160547-2
Hay, David C.. Requirements Analysis: From Business Views to Architecture, 1st, Upper Saddle River, NJ: Prentice Hall (2003). ISBN 0-13-028228-6
Laplante, Phil. Requirements Engineering for Software and Systems, 1st, Redmond, WA: CRC Press (2009). ISBN 978-1-4200-6467-4
McConnell, Steve. Rapid Development: Taming Wild Software Schedules, 1st, Redmond, WA: Microsoft Press (1996). ISBN 1-55615-900-5
(2000) „Requirements engineering: a roadmap”. ICSE'00: 35–46. doi:10.1145/336512.336523.
Applied Software Project Management. Cambridge, MA: O'Reilly Media (2005). ISBN 0-596-00948-8
Software Requirements, 3rd, Redmond, WA: Microsoft Press (2013). ISBN 978-0-7356-7966-5

Külső linkek

Peer-review Encyclopedia Entry on Requirements Engineering and Analysis
Védelmi akvizíciós egyetemi érdekeltek követelményeinek meghatározási folyamata
MIL-HDBK 520 Rendszerkövetelmények Dokumentum útmutató

[SEF01-1] Systems Engineering Fundamentals Archiválva 2011. július 22-i dátummal a Wayback Machine-ben. Defense Acquisition University Press, 2001

[2] Kotonya, Gerald. Requirements Engineering: Processes and Techniques. Chichester, UK: John Wiley and Sons (1998). ISBN 9780471972082

[3] szerk.: Alain Abran: Chapter 2: Software Requirements, Guide to the software engineering body of knowledge, 2004, Los Alamitos, CA: IEEE Computer Society Press (2005. március 1.). ISBN 0-7695-2330-7. Hozzáférés ideje: 2007. február 8. „It is widely acknowledged within the software industry that software engineering projects are critically vulnerable when these activities are performed poorly.”

[1]

[2]

[3]