Szoftverkövetelmény-elemzés példával
Charles Moore
Például a banki alkalmazással összefüggésben a funkcionális követelmény az lesz, amikor az ügyfél az „Egyenleg megtekintése” lehetőséget választja, meg kell tudnia nézni a legutóbbi számlaegyenlegét.
A szoftverigény lehet nem funkcionális, lehet teljesítménykövetelmény is. Például nem funkcionális követelmény, hogy a rendszer minden oldala 5 másodpercen belül látható legyen a felhasználók számára.
Szóval alapvetően szoftverigény a
- Funkcionális ill
- Nem működőképes
szükség amit be kell építeni a rendszerbe. A szoftverigényt általában nyilatkozatok formájában fejezik ki.
Követelmények típusai
- Üzleti követelmények: Magas szintű követelményekről van szó, amelyek a projektek üzleti esetéből származnak. Például egy mobil banki szolgáltatási rendszer banki szolgáltatásokat nyújt Délkelet-Ázsiában. India esetében a számlaösszesítés és az átutalás az üzleti követelmény, míg Kínában a számlaösszesítés és a számlafizetés üzleti követelmény.
| Ország | Banki funkciókat vagy szolgáltatásokat nyújtó vállalat |
|---|---|
| India | Számlaösszesítő és pénzátutalás |
| Kína | Számlaösszefoglaló és Bill Fizetés |
- Archiszerkezeti és tervezési követelmények: Ezek a követelmények részletesebbek, mint az üzleti követelmények. Meghatározza az üzleti követelmény megvalósításához szükséges átfogó tervezést. Oktatási szervezetünk számára az építészeti és tervezési felhasználási esetek a bejelentkezés, a tanfolyam részletei stb. A követelmények az alábbiak szerint alakulnak.
| Banki használati eset | Követelmény |
|---|---|
| Bill Fizetés | Ez a használati eset leírja, hogy az ügyfél hogyan jelentkezhet be a netbanki szolgáltatásba, és hogyan használhatja a Bill Fizetési lehetőség.
Az ügyfél láthatja a regisztrált számlázók fennálló számláinak irányítópultját. Felveheti, módosíthatja és törölheti a számlázó adatait. Az ügyfél konfigurálhat SMS-t, e-mail értesítést a különböző számlázási műveletekhez. Láthatja a múltban kifizetett számlák történetét. Az esetet banki ügyfelek vagy támogató személyzet kezdi. |
- Rendszer- és integrációs követelmények: A legalacsonyabb szinten rendszer- és integrációs követelményeink vannak. Minden egyes követelmény részletes leírása. Ez lehet felhasználói történetek formájában, amelyek valóban leírják a mindennapi üzleti nyelvet. A követelmények bőséges részletezésűek, hogy a fejlesztők elkezdhessék a kódolást. Itt a példa Bill Fizetési modul, ahol meg kell említeni a hozzáadásának követelményét Biller
| Bill Fizetés | követelmények |
|---|---|
| hozzáad BillERS |
|
Előfordulhat, hogy egyes projektek esetében nem kap semmilyen követelményt vagy dokumentumot. Ennek ellenére vannak más követelményforrások is, amelyeket figyelembe vehet a követelmény vagy információ tekintetében, hogy ezekre a követelményekre alapozhassa szoftverét vagy teszttervét. Tehát a többi követelményforrás, amelyre támaszkodhat
A követelmények egyéb forrásai
- Tudásátadás az adott projekten már dolgozó kollégáktól vagy alkalmazottaktól
- Beszéljen a projektről üzleti elemzővel, termékmenedzserrel, projektvezetővel és fejlesztőkkel
- Elemezze az előző rendszerverziót, amely már be van építve a rendszerbe
- Elemezze a projekt régebbi követelménydokumentumát
- Tekintse meg a korábbi hibajelentéseket, néhány hibajelentést továbbfejlesztési kéréssé alakítanak át, amely a jelenlegi verzióba is beépíthető
- Nézze meg a telepítési útmutatót, ha elérhető, hogy megtudja, milyen telepítésre van szükség
- Elemezze azt a tartományi vagy iparági tudást, amelyet a csapat megvalósítani próbál
Bármilyen forrásból is kapja a követelményt, mindenképpen dokumentálja azokat valamilyen formában, és kérje át a csapat többi tapasztalt és hozzáértő tagjától.
Hogyan elemezzük a követelményeket
Tekintsünk példát egy oktatási szoftverrendszerre, ahol a hallgató különböző kurzusokra regisztrálhat.
Tanulmányozzuk, hogyan elemezzük a követelményeket. A követelményeknek meg kell őrizniük a követelményének szabványos minőségét, a minőségi követelmények különböző típusai közé tartozik
- Atomic
- Egyedülállóan azonosítva
- teljes
- Következetes és egyértelmű
- Nyomon követhető
- Elsőbbséget élvez
- Tesztelhető
Értsük meg ezt egy példával, az itt látható táblázatban három oszlop található,
- Az első oszlop azt jelzi, hogy „minőségi követelmény”
- A második oszlop azt jelzi, hogy „rossz követelmény némi problémával”
- A harmadik oszlop megegyezik a második oszloppal, de – „jó követelménysé alakítva”.
| Követelmény Minőség | Példa rossz követelményre | Példa a jó követelményre |
|---|---|---|
| Atomic |
|
|
| Egyedülállóan azonosítva | 1- A hallgatók iratkozhatnak be alapképzésre1- A hallgatók iratkozhatnak fel posztgraduális képzésekre |
|
| teljes | A professzor felhasználó felhasználónevének, jelszavának és egyéb releváns információinak megadásával jelentkezik be a rendszerbe | A professzor felhasználó felhasználónevének, jelszavának és tanszéki kódjának megadásával jelentkezik be a rendszerbe |
| Következetes és egyértelmű | Egy hallgatónak van alapképzési vagy posztgraduális képzése, de mindkettő nem. Egyes kurzusok egyetemi és posztgraduális hallgatók számára is nyitottak lesznek | Egy hallgatónak vagy egyetemi vagy posztgraduális diplomája van, de mindkettő nem |
| Nyomon követhető | Fenntartja a hallgatói információkat a BRD req.ID-hez leképezve? | Tanulói információk karbantartása – Leképezve a BRD-req ID 4.1-hez |
| Elsőbbséget élvez | Regisztrált hallgató – 1. prioritású Felhasználói információk megőrzése – 1. prioritású kurzusok felvétele – 1. prioritású Jelentéskártya megtekintése – 1. prioritás | Regisztráció Hallgatói prioritás 1 Felhasználói információk megőrzése - Prioritás 2 Jelentkezés tanfolyamokra - Prioritás 1 Jelentéskártya megtekintése - Prioritás3 |
| Tesztelhető | A rendszer minden oldala elfogadható időn belül betöltődik | A hallgatók regisztrációja és a kurzusok felvétele a rendszer oldalai 5 másodpercen belül betöltődnek |
Most ismerjük meg ezeket a követelményeket részletesen, kezdve ezzel Atomic.
Atomic
Tehát minden egyes követelménynek atomosnak kell lennie, ami azt jelenti, hogy nagyon alacsony részletszintűnek kell lennie, és nem lehet összetevőkre szétválasztani. Itt láthatjuk a követelmények két példáját, a címen Atomic és egyedileg azonosított követelményszintek.
Folytassuk tehát az oktatási tartomány rendszerépítési példájával. Itt a rossz követelmény az, hogy „A hallgatók beiratkozhatnak alap- és posztgraduális képzésekre”. Ez rossz követelmény, mert nem atomi, mert két különböző entitásról beszél, egyetemi és posztgraduális képzésről. Tehát nyilvánvalóan ez nem jó, hanem rossz követelmény, tehát a levelezés jó követelménye az lenne, ha két követelményre különítenék el. Tehát az egyik az alapképzésre, míg a másik a posztgraduális képzésekre való beiratkozásról beszél.
Egyedülállóan azonosított
Hasonlóképpen a következő minőségi követelmény az egyedi azonosítás ellenőrzése, itt két külön követelményünk van, de mindkettőnek ugyanaz az ID#1. Tehát, ha az ID#-ra hivatkozva hivatkozunk követelményünkre, de nem világos, hogy pontosan melyik követelményre hivatkozunk, dokumentumra vagy a rendszer más részére hivatkozunk, mivel mindkettőnek ugyanaz az ID#1-je. Tehát egyedi azonosítókkal elválasztva, így jó követelmény lesz újra visszaküldeni az 1-es kurzus beiratkozásaként, és két feltétele van: 1.1 id az alapképzésre való beiratkozás, míg az 1.2 id a posztgraduális képzésekre való beiratkozás.
teljes
Ezenkívül minden követelménynek teljesnek kell lennie. Például itt a rossz követelmény szerint a „professzor felhasználó bejelentkezik a rendszerbe a felhasználónevének, jelszavának és egyéb releváns információinak megadásával”. Itt a többi lényeges információ nem egyértelmű, ezért a többi lényeges információt megfelelő követelményként kell megfogalmazni, hogy a követelmény teljes legyen.
Következetes és egyértelmű
Ezután minden követelménynek következetesnek és egyértelműnek kell lennie, így például itt vannak olyan követelmények: „Egy hallgatónak van alapképzése vagy posztgraduális képzése, de mindkettő nem” ez az egyik követelmény, és van egy másik követelmény is, amely szerint „Egyes kurzusok legyen nyitott az alap- és posztgraduális hallgatók számára egyaránt”.
A probléma ebben a követelményben az, hogy az első követelménytől kezdve úgy tűnik, hogy a kurzusok két kategóriába sorolhatók a posztgraduális képzések és a posztgraduális képzések alatt, és a hallgató választhat kettő közül, de nem mindkettőből. De ha más követelményt olvasunk, az ütközik az első feltétellel, és azt mondja, hogy egyes kurzusok posztgraduális és egyetemi hallgatók számára is nyitva állnak.
Tehát kézenfekvő ezt a rossz követelményt jó követelménysé alakítani, amely a következő: „A hallgatónak vagy alapképzési vagy posztgraduális képzése van, de mindkettő nem”. Ez azt jelenti, hogy minden kurzus alapképzésként vagy posztgraduálisként lesz megjelölve
Nyomon követhető
Minden egyes követelménynek nyomon követhetőnek kell lennie, mert már vannak különböző szintű követelmények, már láttuk, hogy a csúcson üzleti követelmények voltak, majd vannak építészeti és tervezési követelmények, amelyeket rendszerintegrációs követelmények követnek.
Most, amikor az üzleti követelményeket építészeti és tervezési követelményekké alakítjuk át, vagy az építészeti és tervezési követelményeket rendszerintegrációs követelményekké alakítjuk, nyomon követhetőnek kell lennie. Ez azt jelenti, hogy képesnek kell lennünk minden egyes üzleti követelményre, és leképeznünk a megfelelő egy vagy több szoftver architektúra és tervezési követelményre. Tehát itt van egy példa a rossz követelményre, amely így szól: „A hallgatói adatok karbantartása – a BRD-req ID-hez leképezve?” a követelményazonosító itt nincs megadva.
Tehát jó követelményre konvertálva ugyanezt mondja, de a 4.1 követelményazonosítóval van leképezve. Tehát a feltérképezésnek minden egyes követelményhez ott kell lennie. Ugyanúgy van magas és alacsony szintű leképezési követelményünk, a leképezés ott van a rendszer és az integrációs követelmény között is a kódhoz, amely ezt a követelményt megvalósítja, valamint van egy leképezés a rendszer és az integrációs követelmény között a tesztesethez, amely teszteli az adott követelményt. .
Tehát ez a nyomon követhetőség az egész projektre kiterjed
Elsőbbséget élvez
| Elsőbbséget élvez | Regisztrált hallgató – 1. prioritás A felhasználói információk 1. prioritása Jelentkezzen tanfolyamokra – 1. prioritás Jelentéskártya megtekintése – 1. prioritás |
Regisztráljon tanulói prioritást 1 A felhasználói információk 2. prioritása Jelentkezzen tanfolyamokra – 1. prioritás Jelentéskártya megtekintése – Prioritás3 |
Ezután minden követelménynek prioritást kell adni, így a csapatnak van iránymutatása, hogy melyik követelményt tudja először megvalósítani, és melyiket tudja később. Itt láthatja a rossz prioritást, hogy regisztrálja a hallgatót, karbantartja a felhasználói információkat, és minden követelmény 1-es prioritást kapott. Mindennek nem lehet egyforma prioritása, ezért a követelmények prioritást adhatnak. Tehát a jó követelmény példa itt a hallgató regisztrálása és a kurzusok beiratkozása az 1-es legmagasabb prioritást kapja, míg a felhasználói adatok karbantartása alább a 2-es prioritású, majd a jelentéskártya megtekintése 3-as prioritású.
Tesztelhető
| Tesztelhető | A rendszer minden oldala elfogadható időn belül betöltődik | A hallgatók regisztrációja és a kurzusok felvétele a rendszer oldalai 5 másodpercen belül betöltődnek |
Minden egyes követelménynek tesztelhetőnek kell lennie, itt a rossz követelmény az, hogy „a rendszer minden oldala elfogadható időn belül betöltődik”. Most két probléma van ezzel a feltétellel, először is, hogy minden oldal azt jelenti, hogy több oldal is lehet, ami felrobbantja a tesztelési erőfeszítéseket. A másik probléma az, hogy azt írja, hogy az oldal elfogadható időn belül fog betölteni, most mi az elfogadható időkeret? Kinek elfogadható. Tehát a nem tesztelhető argumentumot át kell alakítanunk tesztelhető argumentummá, amely konkrétan megmondja, hogy melyik oldalon beszélünk „hallgató regisztráció és kurzusok beiratkozása oldalakról”, és megadjuk az elfogadható időkeretet is, ami 5 másodperc.
Következtetés
Így tehát minden egyes követelményt megfelelő szinten kell megvizsgálnunk. Például, ha egy szoftvert fogunk építeni a rendszer- és integrációs követelmények tekintetében. Meg kell vizsgálnunk a szoftverkövetelmény-specifikációkban vagy felhasználói történetekben megadott rendszer- és integrációs követelményeket, és minden egyes követelményminőségre alkalmazni kell. Ezután ellenőrizze, hogy minden egyes követelmény atomi, egyedileg azonosított-e, teljes-e és így tovább.