Üdvözlöm, Ön a requirements analysis szó jelentését keresi. A DICTIOUS-ban nem csak a requirements analysis szó összes szótári jelentését megtalálod, hanem megismerheted az etimológiáját, a jellemzőit és azt is, hogyan kell a requirements analysis szót egyes és többes számban mondani. Minden, amit a requirements analysis szóról tudni kell, itt található. A requirements analysis szó meghatározása segít abban, hogy pontosabban és helyesebben fogalmazz, amikor beszélsz vagy írsz. Arequirements analysis és más szavak definíciójának ismerete gazdagítja a szókincsedet, és több és jobb nyelvi forráshoz juttat.
(informatika) A requirements analysis (követelményanalízis) a szoftverfejlesztési életciklus egyik legkritikusabb fázisa, amelynek célja, hogy meghatározza és pontosan rögzítse a szoftverrel szemben támasztott elvárásokat. Ez a fázis a sikeres projekt kulcsa: ha rosszul végezzük el, az hibás, költséges vagy akár használhatatlan rendszert eredményezhet.
1. Mi az a requirements analysis?
A követelményanalízis során az alábbi kérdésekre keressük a választ:
Mit vár el a megrendelő?
Milyen problémát oldunk meg?
Milyen funkciókat és viselkedést kell megvalósítani?
Milyen nem-funkcionális elvárások (pl. teljesítmény, biztonság, megbízhatóság) vannak?
2. Fő célok
A problématér teljes megértése
A különböző érintettek (stakeholders) igényeinek összegyűjtése
A követelmények pontossá, egyértelművé és tesztelhetővé tétele
A követelmények dokumentálása és jóváhagyatása
3. A folyamat fő lépései
3.1 Követelmények gyűjtése (elicitation)
Az első lépés az információgyűjtés, amikor az elemző a felhasználókkal, megrendelőkkel és technikai szakértőkkel konzultál.
Módszerek:
Interjúk
Kérdőívek
Workshopok
Megfigyelés (pl. jelenlegi rendszer használata)
Dokumentumelemzés
3.2 Követelmények elemzése
Ellenőrizzük az összegyűjtött információk ellentmondásait, hiányosságait, duplikációit. Itt kezdjük el a nyers igényeket rendszerezni és finomítani.
3.3 Követelmények specifikálása
A követelményeket formálisan vagy félformálisan rögzítjük dokumentum formájában.
Példa:
“A rendszernek lehetővé kell tennie a felhasználónak, hogy bejelentkezzen email-cím és jelszó megadásával.”
3.4 Követelmények érvényesítése (validation)
Ellenőrizzük, hogy az elvárások megfelelnek-e a valódi üzleti igényeknek, és nincsenek benne félreértések.
3.5 Követelmények kezelése (management)
A követelmények a projekt során változhatnak – ezek nyomon követéséhez, verziózásához és hatáselemzéséhez szükséges a követelménykezelés.
4. Követelménytípusok
4.1 Funkcionális követelmények
Leírják, mit kell a rendszernek csinálnia.
Példa:
„A rendszer tárolja az ügyfelek megrendeléseit.”
„A felhasználó törölhet saját bejegyzést.”
4.2 Nem-funkcionális követelmények
Leírják, hogyan kell a rendszernek viselkednie.
Típusai:
Teljesítmény (pl. válaszidő < 2 sec)
Megbízhatóság
Biztonság
Skálázhatóság
Hordozhatóság
4.3 Üzleti szabályok
Olyan korlátozások vagy szabályok, amelyeket a szervezet előír (pl. ÁFA-kezelés, könyvelési előírások).
4.4 Felhasználói követelmények
A végfelhasználók szemszögéből írt igények, gyakran informálisabban.
5. Jellemző hibák
Követelmények nem teljesek
Követelmények homályosak („a rendszer legyen gyors”)
Ellentmondó igények több stakeholder között
Technikai megoldás előresietése az igények helyett
Nincs verziókezelés vagy változáskezelés
6. Jó követelmény jellemzői
Egy jó követelmény:
Egyértelmű: nem lehet félreérteni
Tesztelhető: ellenőrizhető, hogy teljesül-e
Konzisztens: nincs ellentmondás más követelményekkel
Teljes: lefedi az adott funkció minden aspektusát
Megvalósítható: reális a technikai és üzleti korlátok között