ez az oktatóanyag elmagyarázza, hogy mi a Követelményelemzés, a Követelményelemzés lépései, példái és céljai az SDLC Követelménygyűjtésének:
a szoftverfejlesztés egy hatalmas feladat, amely egy működő szoftverterméket hoz létre.
a Szoftver Termék épül, mint egy az ügyfél követelmény. Leginkább ez a szoftver termék megfelel annak, amit a végfelhasználó/felhasználó elvárt, míg néha ez a termék nem felel meg teljes mértékben annak, amit az ügyfél/végfelhasználó elvárt.
mi a Követelményelemzés?
értsük meg a Követelményelemzést egy példa segítségével.
vevői / Végfelhasználói elvárások:
ügyfél / végfelhasználó fogadása:
mivel a fenti képekből elemezheti, hogy a végtermék eltér az ügyfél elvárásaitól. Ennek számtalan oka lehet, azaz. az ügyféligények helytelen végrehajtása, hibás tervezés, a programozók és a minőségi csapat helytelen megértése stb.
amint azonban láthatja, legyen az bármilyen oka a helytelen termékszállításnak, az elsődleges ok a követelmény. Ezért, ha a követelmények helyes megértése, rögzítése, megvalósítása és tesztelése megtörtént volna, az segített volna enyhíteni a hibás és hiányos termékszállítást az ügyfél/végfelhasználó számára.
a jó termékszállítás előfeltétele a megfelelő követelménygyűjtés, az összegyűjtött követelmények hatékony vizsgálata, végül pedig az egyértelmű követelménydokumentáció. Ezt az egész folyamatot Követelményelemzésnek is nevezik a szoftverfejlesztés életciklusában (SDLC)
Követelményelemzési szakaszok / lépések
mint látható, a Követelményelemzés az SDLC első tevékenysége, amelyet funkcionális specifikáció követ stb. A követelményelemzés létfontosságú lépés az SDLC – ben, mivel rezonál az elfogadási teszteléssel, amely kritikus fontosságú a termék ügyfelek általi elfogadása szempontjából.
ebben az oktatóanyagban elmagyarázzuk, hogyan történik a követelményelemzés az SDLC – ben. Látni fogjuk a különböző lépéseket, eredményeket, kihívásokat és korrekciós intézkedéseket a követelményelemzésben.
követelmény elemzés kezdődik:
- Követelménygyűjtés, amelyet kiváltásnak is neveznek.
- ezt követi az összegyűjtött követelmények elemzése annak érdekében, hogy megértsük e követelmények lehetséges termékké történő átalakításának helyességét és megvalósíthatóságát.
- és végül az összegyűjtött követelmények dokumentálása.
#1) Követelménygyűjtés
annak biztosítása érdekében, hogy a fent említett lépések megfelelően végrehajtásra kerüljenek, világos, tömör és helyes követelményeket kell összegyűjteni az ügyféltől. Az ügyfélnek képesnek kell lennie arra, hogy megfelelően meghatározza követelményeit, és az üzleti elemzőnek képesnek kell lennie arra, hogy összegyűjtse azt ugyanúgy, ahogy az ügyfél szándékozik közvetíteni.
sokszor nem lehetséges, hogy a követelménygyűjtést az üzleti elemzők hatékonyan végzik az ügyféltől. Ennek oka lehet, hogy sok ember függ a várható végterméktől, eszközöktől, környezettől stb. Ezért mindig jó ötlet bevonni az összes érdekelt felet, akik befolyásolhatják vagy befolyásolhatják a végterméket.
a lehetséges érdekelt felek csoportja lehet szoftverminőségi mérnök (mind QC, mind QA), bármely harmadik fél szállító, aki támogatást nyújthat a projektben, végfelhasználó, akinek a terméket szánják, szoftverprogramozók, a szervezeten belüli másik csapat, aki modult vagy szoftverplatformot, szoftverkönyvtárakat stb. termékfejlesztésre.
példa: egy szervezetben olyan ADAS terméket fejlesztenek ki (surround-view camera system egy tekintélyes OEM számára), amelyhez Autosar stack és Bootloader bináris fájlokra van szükség, amelyeket egy másik szállítótól kapnak.
a különböző érdekelt felek bevonása a követelménygyűjtési szakaszba segít megérteni az egymástól való különböző függőségeket, és minden lehetséges jövőbeli konfliktus elkerülhető.
néha jó ötlet elkészíteni a tervezett termék prototípusát, és megmutatni az ügyfélnek. Ez egy kiváló módja annak, hogy közölje az ügyfelekkel, hogy milyen terméket várnak, és hogyan nézhet ki később. Ez segít az Ügyfélnek az elvárt termék megjelenítésében, és segít abban, hogy világos követelményeket állítson fel.
ez a prototípus létrehozása kétféle terméktől függ:
- hasonló termék, amelyet az ügyfelek terveztek, létezik a szervezeten belül.
- új terméket kell kifejleszteni.
(i) az első esetben könnyebb megmutatni az ügyfélnek, hogyan nézne ki a végtermék, és hogyan fejlesztenék. Az autóipari ADAS – ban meg lehet mutatni az ügyfeleknek egy másik, már piacon lévő terméket, amelyet a szervezeten belül fejlesztettek ki.
például egy OEM (GM, Volkswagen, BMW stb.) és bemutatható egy másik OEM-nek.
Felhívjuk figyelmét, hogy nem bölcs dolog bemutatni a terméket/proto terméket a fejlesztés alatt álló ügyfélnek, mivel ez sértheti a titoktartási megállapodást, amelyet egy másik ügyféllel írtak alá, akinek a terméket fejlesztik. Ez szükségtelen jogi csetepatéhoz is vezethet.
egy másik példa lehet a szervezet által kifejlesztett infotainment rendszer, amely már a piacon van. Az üzleti elemzők és a szervezeten belüli egyéb érdekeltek tervezhetnek egy workshop demót az ügyfél számára, bemutatva az infotainment rendszereket kézzelfogható HMI-vel, eszközcsatlakozó portokkal, homokozóval stb.
ez segít az ügyfélnek abban, hogy megértse, hogyan néz ki a végtermék, és sokkal világosabban adja meg igényeit.
(ii) a második eset úgy érhető el, hogy egyszerű kódolással és összeszereléssel létrehozunk egy alapvető munkamodellt (itt többnyire a szoftverprogramok hardveresen vannak kódolva), vagy létrehozunk egy folyamatábrát vagy diagramot, amely meggyőzheti az Ügyfelet a termék kinézetéről.
mindenesetre légtelenítő lenne a követelménygyűjtési folyamat számára, mivel az ügyfél most már tudja, mit akar.
az üzleti elemző most szervez formális követelmény kiváltó ülések, ahol minden érdekelt fél lehet meghívni, és így feljegyezni a különböző követelmények által nyújtott ügyfél (egyes esetekben, ha az érdekelt felek több számban, külön írástudó lehetne kinevezni jegyzet le vevői követelmények vagy felhasználói történeteket, hogy az üzleti elemző tudott koncentrálni moderáló értekezlet).
az összegyűjtött követelmények lehetnek felhasználói történetek (agilis fejlesztés során), használati esetek, ügyfél természetes nyelvű dokumentumok, diagramok, folyamatábrák stb. A felhasználói történetek egyre népszerűbbek a modern szoftverfejlesztési életciklusban. A felhasználói történetek alapvetően az ügyfelek bemeneteinek halmaza a természetes nyelvükön.
Követelménygyűjtési példa: az ADAS surround-view kamerarendszerben az egyik lehetséges felhasználói történet a következő lehet: “felhasználóként látnom kell, mi van az autóm visszapillantójában”.
sok” miért ” kérdést lehet feltenni az egyes felhasználói történeteken, amelyek segítenek az ügyfélnek abban, hogy részletesebb információkat nyújtson a követelményről.
a fenti felhasználói történetben, ha egy ügyfél azt mondja: “felhasználóként látnom kell, mi van az autóm visszapillantójában”, feltesz egy kérdést, hogy” miért “adhatna”felhasználóként, látnom kell, mi van az autóm visszapillantójában, hogy biztonságosan parkolhassak”.
a “miért” kérdés feltevése szintén segít az objektív és atomi követelmények megteremtésében az ügyfél által adott humongous természetes nyelvi nyilatkozatokból. Ez könnyen megvalósítható később a kódban.
a követelmény összegyűjtésének másik módja használati esetek formájában van. A felhasználási eset lépésről lépésre történő megközelítés egy bizonyos eredmény eléréséhez. Ez nem mondja meg, hogy a szoftver hogyan fog működni a felhasználói bemeneten, inkább azt mondja, mi várható a felhasználói bemenetektől.
példa:
#2) elemezve összegyűjtött követelmények
post követelmény összegyűjtése, elemzése követelmény kezdődik. Ebben a szakaszban a különböző érdekeltek ülnek és ötletbörzét tartanak. Elemzik az összegyűjtött követelményeket, és keresik azok megvalósíthatóságát. Beszélgetnek egymással, és minden kétértelműség megoldódik.
ez a lépés a következő fő okok miatt fontos a követelményelemzési folyamatban:
(i) Az Ügyfél olyan követelményeket nyújthat be, amelyeket a különböző függőségek miatt lehetetlen megvalósítani.
példa: az ügyfelek kérhetik a kamerarendszer térhatású megtekintését egy visszapillantó kamera funkcióval, amely segít az autó parkolásában. Az ügyfél kérheti a pótkocsi vonóhorog funkcióját is, amely a hátsó kamerát is használja.
ha az ügyfél azt állítja, hogy a parkolást segítő visszapillantó kamerának kivétel nélkül mindig működnie kell, akkor a pótkocsi funkció soha nem fog működni, és fordítva.
(ii) lehet, hogy egy üzleti elemző másképp értette az ügyfél követelményét, mint ahogy egy programozó értelmezte volna.
mivel a programozók MŰSZAKI szakértőként gondolkodnak, mindig lehetséges, hogy az ügyfelek igényeit helytelenül alakítják át funkcionális specifikációkká, amelyeket később helytelenül készítenek az architektúrára és a tervezési dokumentumokra, majd a kódra. A hatás exponenciális, ezért ellenőrizni kell.
lehetséges javító intézkedés lehet a szoftverfejlesztés agilis módszerének követése, az ügyfél által biztosított használati esetek követése stb.
#3) az elemzett követelmények dokumentálása
a követelmények elemzése után a követelménydokumentáció megkezdődik. A követelmények elemzéséből különböző típusú követelmények származnak.
néhány ezek közül:
(i) ügyfél követelmény specifikáció.
(ii) szoftver architektúra követelmény.
példa:
(iii) szoftver tervezési követelmény.
példa:
(iv) funkcionális követelmény specifikáció (közvetlenül az ügyfél specifikációiból származik.)
példa: “amikor a felhasználó megérinti a Bluetooth ikont az Infotainment HMI-N, A Bluetooth képernyőnek meg kell jelennie”
(v) nem funkcionális követelmény specifikáció (azaz. teljesítmény, stressz, terhelés stb.).
példa: “lehetővé kell tenni 15 Bluetooth-eszköz párosítását az infotainment rendszerrel a rendszer teljesítményének romlása nélkül”.
(vi) felhasználói felület követelményei.
példa: “A Tuner FM képernyőn egy gombot kell biztosítani a különböző állomások kiválasztásához”
a fenti követelményeket a követelménykezelő eszközök, például az IBM DOORS, A HP QC rögzítik és dokumentálják. Néha a szervezetek egyedi igénykezelő eszközökkel rendelkeznek a költségek csökkentése érdekében.
vizsgáljuk meg most az üzleti követelmények Szoftverkövetelményekké történő átalakításának folyamatát (funkcionális és nem funkcionális).
üzleti követelmények átalakítása Szoftverkövetelményekké
üzleti követelmények, amint azt fentebb tárgyaltuk, magas szintű követelmények, amelyek arról beszélnek, hogy a végfelhasználó mit akar a szoftverrendszer meghatározott műveletétől. A teljes szoftverrendszer ezen követelmények alapján történő fejlesztése nem lehetséges, mivel a szoftverrendszer vagy komponens megvalósításának részletes leírása nem szerepel.
így az üzleti követelményeket részletesebb szoftverkövetelményekre kell bontani, amelyek tovább részletezik a funkcionális és nem funkcionális követelményeket.
ehhez a következő lépéseket kell követni:
- bontsa le a magas szintű üzleti követelményeket a részletes felhasználói történetekre.
- folyamatábra levezetése a tevékenységek áramlásának meghatározására.
- olyan feltétel biztosítása, amely igazolja a származtatott felhasználói történeteket.
- drótváz diagramok az objektumok munkafolyamatának magyarázatához.
- a nem funkcionális követelmények meghatározása az üzleti követelményekből.
kezdjük egy példával autóipari Infotainment rendszer.
az üzleti követelmény azt mondja:”a végfelhasználónak képesnek kell lennie a navigációs widget box elérésére az Infotainment rendszer HMI-jéből, és képesnek kell lennie a célcím beállítására”.
tehát a fent felsorolt lépések végrehajthatók:
#1) bontsa le a magas szintű üzleti követelményeket a részletes felhasználói történetekre.
alakítsuk át ezt az üzleti követelményt egy magas szintű felhasználói történetté: “felhasználóként képesnek kell lennem hozzáférni a navigációs widget dobozhoz, hogy megadhassam a célcímet”. Ez a felhasználói történet elmondja, mire van szüksége a végfelhasználónak. Megpróbáljuk meghatározni, hogyan kell végrehajtani ezt a követelményt.
kezdjük azzal, hogy lehetséges kérdéseket teszünk fel ennek a felhasználói történetnek, azaz.
- kik a felhasználók?
- Hogyan érhetem el a navigációt a fedélzeten (SD-kártyáról) vagy okostelefonról?
- milyen típusú célbejegyzéseket adhatok meg?
- be kell-e engednem a rendeltetési helyre akkor is, ha az autó parkolóban van?
ezek részletesebb szintű felhasználói történetek, amelyek magas szintű felhasználói történetekből származnak, és segítenek nekünk abban, hogy jobban megismerjük üzleti követelményeinket.
ezen a ponton felvehetjük az egyik felhasználói al-történetet, és elkezdhetjük a kihallgatást. Vegyük (nem. 3):
- megadhatom a rendeltetési hely bejegyzéseit, például a földrajzi koordinátákat, a postai címet, a Beszédfelismerésen keresztül stb.?
- szükségem van GPS-re a Földrajzi koordináták megadásához?
- megadhatom az aktuális célcímet a címek előzményeiből történő kereséssel?
#2) folyamatábra levezetése a tevékenységek áramlásának meghatározásához.
most láthatjuk, hogy az üzleti követelmény nagyon részletes használati esetekre van bontva, amelyeket a folyamatábrában az alábbiak szerint lehet megjelölni:
#3) olyan feltételek biztosítása, amelyek igazolják a származtatott felhasználói történeteket.
láthatjuk, hogy részletesebb információk jelennek meg a magas szintű üzleti követelmények részletes, alacsony szintű felhasználói történetekre és a folyamatábra lebontása miatt. Ebből a folyamatábra, megkaphatjuk a megvalósításhoz szükséges technikai részleteket, ti.
- a képernyő betöltési ideje a célbejegyzés megjelenítéséhez 1 másodperc.
- a célbejegyzés billentyűzetének alfanumerikus karakterekkel és speciális szimbólumokkal kell rendelkeznie.
- a GPS bekapcsoló/kikapcsoló gombjának jelen kell lennie a navigációs cél beviteli képernyőn.
a fenti információk megfelelnek a felhasználói történeteknek, és lehetővé teszik a követelmény diszkréten és mérhetően történő tesztelését, elkerülve a követelményekkel való összetévesztést, miközben szolgáltatásként alkalmazzák.
#4) drótváz diagramok az objektumok munkafolyamatának magyarázatához.
a fenti Használati esetből levezetünk egy drótváz diagramot, amely világosabbá teszi a felhasználói felületet.
#5) a nem funkcionális követelmények meghatározása az üzleti követelményekből.
elengedhetetlen, hogy a részletes szoftverkövetelmények a magas szintű üzleti követelményekből származzanak, de sok esetben csak a funkcionális követelményeket azonosítják, amelyek megmondják, hogy a rendszer hogyan viselkedik egy adott felhasználói bemenethez/művelethez.
a funkcionális követelmények azonban nem tisztázzák a rendszerek teljesítményét és más minőségi paramétereket, például a rendelkezésre állást, a megbízhatóságot stb.
példák:
a) a fenti autóipari infotainment rendszer példáját vesszük.
ha az autó vezetője(végfelhasználója) zenét játszik le USB-ről, és a navigációs útmutatás folyamatban van, akkor Bluetooth-on keresztül bejövő hívást is kap kihangosító módban, majd a CPU-és RAM-fogyasztás maximális szintre növekszik, mivel több folyamat fut a háttérben.
ezen a ponton, ha a vezető megérinti az infotainment rendszer érintőképernyős felületét, hogy elutasítsa a bejövő hívásokat automatikus válasz SMS-ben (ugyanúgy, mint a mobiltelefonjainkban), a rendszernek képesnek kell lennie erre a feladatra, és nem szabad lefagynia vagy összeomlania. Ez a rendszer teljesítménye, amikor a terhelés nagy, és teszteljük a rendelkezésre állást és a megbízhatóságot.
b) egy másik eset a stressz forgatókönyv.
Vegyünk egy példát, az infotainment rendszer kap back to back SMSs (talán 20 SMS belül 10 mp) keresztül csatlakoztatott Bluetooth telefon. Az Infotainment rendszernek képesnek kell lennie az összes bejövő SMS kezelésére, és soha ne hagyja ki az Infotainment HMI bejövő SMS-értesítéseit.
a fenti példák olyan nem funkcionális követelmények esetei, amelyeket nem lehetett kizárólag funkcionális követelményekkel tesztelni. Bár néha az ügyfelek elmulasztják ezeket a nem funkcionális követelményeket. A szervezet felelőssége, hogy ezeket az információkat megadja nekik, amikor egy terméket az ügyfélnek szállítanak.
a nem funkcionális követelmények megértése esetek
az alábbi táblázat ismerteti a nem funkcionális követelményeket:
| SL no | funkció / használati eset | CPU terhelés(max.) | RAM használat (max. 512 MB-ból) | teljesítményparaméterek |
|---|---|---|---|---|
| 1 | Max nem. az Infotainment rendszerhez párosítható Bluetooth eszközök | 75% | 300 MB | 10 Bluetooth-eszköz |
| 2 | ideje letölteni az 2000 telefonos névjegyeket az Infotainment rendszerben a Bluetooth párosítás és kapcsolat után | 90% | 315 MB | 120 másodperc |
| 3 | ideje, hogy átvizsgálja az összes rendelkezésre álló FM állomások Tuner infotainment rendszer | 50% | 200 MB | 30 másodperc |
nem funkcionális követelmények, ellentétben a funkcionális követelményekkel, vegye teljes életciklusa a projekt kap végre, mivel azok végrehajtása fokozatosan megfelelő agilis Sprint vagy különböző iterációkban.
tehát így vezetjük le a szoftverkövetelményeket az üzleti követelményekből.
különbség az üzleti követelmények és a szoftverkövetelmények között
fentebb láttuk, hogyan lehet A szoftverkövetelményeket a magas szintű üzleti követelményekből levezetni. A szoftverkövetelmények lehetővé teszik a programozó és a tesztmérnök számára a rendszer fejlesztését és hatékony tesztelését. Tehát most már tudjuk, hogy az üzleti követelmények magas szintű ügyfelek természetes nyelvi követelményei, míg a szoftverkövetelmények részletes alacsony szintű követelmények, amelyek segítenek a szoftverrendszer megvalósításában.
nézzük meg a két követelménytípus közötti részletes különbséget.
| üzleti követelmények | szoftverkövetelmények |
|---|---|
| ezek a magas szintű követelmények az ügyfél azt mondja, hogy ” mit ” rendszer kell tennie. Ezek a követelmények nem mondják, hogy” hogyan ” kell működniük a követelményeknek. | az ügyfelek igényeinek “hogyan” aspektusára koncentrálnak. Ezek a követelmények magyarázzák a rendszer működését/megvalósítását. |
| ezek a követelmények a szervezet üzleti céljával foglalkoznak. példa: a felhasználónak képesnek kell lennie a navigációs célállomás beállítására. |
ezek a követelmények magyarázzák a követelmények műszaki know-how-ját. példa: amikor a felhasználó rákattint a navigációs cél ikonjára, az adatbázisnak be kell töltenie a felhasználó által megadandó cél adatait. |
| az üzleti követelmények a szervezet előnyeire összpontosítanak. példa: a felhasználó tájékozódjon a navigációs funkció frissítéséről a kereskedőtől az Infotainment rendszerben, ha nincs navigáció a rendszeren, és a felhasználó megérinti a navigációs ikont. |
a szoftverkövetelmények az üzleti követelmények végrehajtási részleteivel foglalkoznak a rendszerben. példa: amikor a felhasználó az Infotainment rendszer navigációs ikonjára kattint, API-hívást kell kezdeményezni a Felhasználónak a rendszerfrissítésre vonatkozó üzenet megjelenítéséhez. |
| az üzleti követelményeket általában természetes nyelven vagy magas szintű felhasználói történetekkel írják. | a szoftverkövetelmények funkcionálisak és nem funkcionálisak. példa: a nem funkcionális követelmények a teljesítmény, a stressz, a hordozhatóság, a használhatóság, a memória optimalizálása, a megjelenés stb. |
következtetés
a Követelményelemzés minden SDLC modell gerince.
a követelményelemzés során elmulasztott és az Egységtesztelés során Elkapott probléma több tízezer dollárba kerülhet egy szervezetnek, és ez a költség több millió dollárhoz vezethet, ha visszahívásként érkezik a piacról (2017-ben az USA feltöltött légzsák gyártója, a Takata 1 milliárd dolláros bírságot kapott a felrobbanó légzsákok miatt).
a szervezet végül olyan kárelhárítási feladatokat végezne, mint a kiváltó okok elemzése, az 5 miért dokumentumok elkészítése, a hibafa elemzése, a 8D dokumentum stb. ahelyett, hogy a szoftverfejlesztésre és a minőségre koncentrálna.
a legrosszabb esetekben a szervezetet az ügyfél által benyújtott jogi perekbe vonják, ha az érintett szolgáltatás biztonsággal / biztonsággal kapcsolatos, például biztonsági hozzáférés, légzsák, ABS (blokkolásgátló fékrendszer) stb.