Szoftverkövetelmény-elemzés példával
Charles Moore
⚡ Okos összefoglaló
A szoftverkövetelmény-elemzés funkcionális és nem funkcionális állításokra bontja az érdekelt felek igényeit, üzleti, architektúrális és rendszerszinten rangsorolja azokat, majd mindegyiket minőségi attribútumok alapján ellenőrzi, hogy tesztelhető, tracmegvalósítható, priorizált specifikáció.
A szoftverkövetelmény egy funkcionális vagy nem funkcionális igény, amelyet meg kell valósítani a rendszerben. A funkcionális azt jelenti, hogy egy adott szolgáltatást nyújt a felhasználónak.
Például egy banki alkalmazás kontextusában a funkcionális követelmény az, hogy amikor az ügyfél az „Egyenleg megtekintése” lehetőséget választja, képes legyen megtekinteni a legfrissebb számlaegyenlegét.
Egy szoftverkövetelmény lehet nem funkcionális is, például egy teljesítménykövetelmény. Például egy nem funkcionális követelmény előírhatja, hogy a rendszer minden oldalának 5 másodpercen belül be kell töltődnie a felhasználók számára.
Szóval alapvetően szoftverigény a
- Funkcionális vagy
- Nem működőképes
szükség amit be kell építeni a rendszerbe. A szoftverkövetelményeket általában utasítások formájában fejezik ki.
Követelmények típusai
Üzleti követelményekEzek a projekt üzleti tervéből vett magas szintű követelmények. Például egy mobilbanki szolgáltató rendszer Délkelet-Ázsiában nyújt banki szolgáltatásokat. India esetében az üzleti követelmény a számlaösszesítő és a pénzátutalás, míg Kína esetében a számlaösszesítő és a számlafizetés.
| 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 Költségek |
Archiszerkezeti és tervezési követelményekEzek a követelmények részletesebbek, mint az üzleti követelmények, és meghatározzák a megoldás architektúráját. Meghatározzák az üzleti követelmény megvalósításához szükséges általános tervet. Egy oktatási szervezet esetében a tipikus architektúrai és tervezési felhasználási esetek közé tartozik a bejelentkezés, a kurzus részletei és a beiratkozás. A követelmény az alábbiak szerint alakul.
| Banki használati eset | Követelmény |
|---|---|
| Bill Költségek | 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 megtekintheti a regisztrált számlázók kiegyenlítetlen számláinak irányítópultját. Az ügyfél hozzáadhat, módosíthat és törölhet egy számlázó adatait. Az ügyfél SMS- és e-mail-értesítéseket konfigurálhat a különböző számlázási műveletekhez. Az ügyfél megtekintheti a korábban kifizetett számlák előzményeit. Ezt a használati esetet banki ügyfelek vagy ügyfélszolgálati személyzet indítja el. |
Rendszer- és integrációs követelményekA legalacsonyabb szinten a rendszer- és integrációs követelmények találhatók. Ez részletes leírást ad minden egyes követelményről. Felhasználói történetek formájában rögzíthetők mindennapi üzleti nyelven. A követelmények bőségesen tartalmaznak részleteket, így a fejlesztők elkezdhetik a kódolást. A Bill Az alábbi fizetési modul példa a számlázó hozzáadásának követelményét mutatja be.
| Bill Költségek | követelmények |
|---|---|
| hozzáad BillERS | Közműszolgáltató neve, Kapcsolati ügyfélszám, Automatikus fizetések – Igen/Nem, Teljes összeg kifizetése Bill – Igen/Nem, automatikus fizetési limit – Ne fizessen, ha Bill meghaladja a meghatározott összeget |
Előfordulhat, hogy egy projekthez nem kapsz semmilyen követelményt vagy dokumentumot, amellyel dolgozhatnál. Még ebben az esetben is vannak más követelményinformációs források, amelyekre támaszkodhatsz a szoftver vagy a tesztterv alapjául. Az alábbiakban felsoroljuk a további követelményforrásokat, amelyekre támaszkodhatsz.
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élje meg a projektet az üzleti elemzővel, a termékmenedzserrel, a projektvezetővel és a fejlesztőkkel
- Elemezze a rendszer korábbi, már megvalósított verzióját
- A projekt régebbi követelménydokumentumainak elemzése
- Revkorábbi hibajelentések megtekintése; egyes hibajelentéseket fejlesztési kérésekké alakítottunk át, amelyek a jelenlegi verzióban is megvalósíthatók
- Ellenőrizze a telepítési útmutatót, ha van ilyen, hogy megtudja, milyen telepítésekre van szükség.
- Elemezze a csapat által megvalósítani kívánt szakterületet vagy iparági ismereteket
Bármelyik követelményforrást is használja, dokumentálja azokat egy megosztott formátumban, és kérje meg tapasztalt csapattagok véleményét.
Hogyan elemezzük a követelményeket
Vegyünk egy oktatási szoftverrendszer példáját, ahol a hallgatók különböző kurzusokra regisztrálhatnak.
Vizsgáljuk meg, hogyan elemezhetjük a követelményeket. Minden követelménynek meg kell felelnie egy sor szabványos minőségi tulajdonságnak, amelyek a következőket tartalmazzák:
- Atomic
- Egyedülállóan azonosítva
- teljes
- Következetes és egyértelmű
- Tracehető
- Elsőbbséget élvez
- Tesztelhető
A következő táblázat három oszloppal szemlélteti az egyes attribútumokat:
- 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 ugyanazt a követelményt mutatja, „jó követelménnyé alakítva”.
| Követelmény Minőség | Példa rossz követelményre | Példa a jó követelményre |
|---|---|---|
| Atomic | A hallgatók alap- és posztgraduális képzésekre iratkozhatnak be | A hallgatók alapképzésben részt vehetnek. A hallgatók posztgraduális képzésben részt vehetnek. |
| Egyedülállóan azonosítva | 1- A hallgatók alapképzésben részt vehetnek. 1- A hallgatók posztgraduális képzésben részt vehetnek. | Kurzusbeiratkozás. A hallgatók alapképzéses kurzusokra iratkozhatnak be. A hallgatók posztgraduális kurzusokra is beiratkozhatnak. |
| 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 |
| Tracehető | 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 adatok karbantartása – 1. prioritás. Kurzusok beiratkozása – 1. prioritás. Értékelőlap megtekintése – 1. prioritás | Hallgató regisztrálása – 1. prioritás. Felhasználói adatok karbantartása – 2. prioritás. Kurzusok beiratkozása – 1. prioritás. Értékelőlap megtekintése – 3. prioritás |
| 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 |
Értsük meg részletesebben ezeket a tulajdonságokat, kezdve azzal, hogy Atomic.
Atomic
Minden követelménynek atomi szintűnek kell lennie, ami azt jelenti, hogy a legalacsonyabb részletességi szinten kell szerepelnie, és nem bontható tovább összetevőkre. A következő példák az atomi és a nem atomi követelményeket hasonlítják össze.
Folytatva az oktatási területi rendszer példáját: Itt a rossz követelmény a következő: „A hallgatók beiratkozhatnak alap- és posztgraduális kurzusokra”. Ez egy rossz követelmény, mert nem atomi – két különböző entitást, alap- és posztgraduális kurzusokat kever össze. A megfelelő jó követelmény két követelményre osztja szét. Az egyik követelmény az alapképzési kurzusokra való beiratkozást, a másik pedig a posztgraduális kurzusokra való beiratkozást fedi le.
Egyedülállóan azonosított
A következő minőségi attribútum az egyedi azonosító. A rossz példában két különálló követelmény ugyanazzal az 1. azonosítószámmal rendelkezik. Ha egy csapat egy követelményre az azonosítójával hivatkozik, akkor nem világos, hogy melyikre gondol. A jó követelmény az 1. szakasz – Kurzusbeiratkozás – alá csoportosítja őket, az 1.1. (alapképzési kurzusokra való beiratkozás) és az 1.2. (posztgraduális kurzusokra való beiratkozás) alkövetelményekkel.
teljes
Minden követelménynek teljesnek kell lennie. Például itt a rossz követelmény azt mondja ki, hogy „a professzor felhasználója a felhasználónevének, jelszavának és egyéb releváns információknak a megadásával jelentkezik be a rendszerbe”. Az „Egyéb releváns információk” homályos. Egy teljes követelmény pontosan felsorolja azokat a mezőket, például a tanszékkódot, amelyeket a professzornak meg kell adnia.
Következetes és egyértelmű
Minden követelménynek következetesnek és egyértelműnek kell lennie. A rossz példában az egyik követelmény kimondja, hogy „A hallgatónak vagy alapképzésben, vagy posztgraduális képzésben kell részt vennie, de nem mindkettőben”, míg egy másik szerint „Néhány kurzus mind az alapképzésben, mind a posztgraduális képzésben részt vevő hallgatók számára nyitott lesz”.
Az első követelmény azt sugallja, hogy a kurzusokat két kizárólagos kategóriába sorolják, de a második követelmény ellentmond ennek, mivel bizonyos kurzusokat mindkét csoport számára megnyit.
A jó követelmény feloldja az ellentmondást azáltal, hogy egyértelműen kimondja, hogy minden kurzust vagy alapképzésben, vagy mesterképzésben kell megjelölni, és egy hallgató csak egy kategóriába tartozó kurzusokra iratkozhat be.
Tracehető
Minden követelménynek meg kell felelnie trachasználható, mivel a követelmények több szinten léteznek: üzleti, építészeti és tervezési, valamint rendszer- és integrációs szinten.
Amikor egy üzleti követelményt építészeti és tervezési követelménnyé, vagy építészeti és tervezési követelményt rendszer- és integrációs követelménnyé alakítunk, tracA használhatóságot meg kell őrizni. Minden üzleti követelménynek egy vagy több építészeti és tervezési követelményhez kell megfeleltetni. A rossz példában, a „Hallgatói információk karbantartása – BRD követelményazonosítóhoz van rendelve?”, a követelményazonosító hiányzik.
A jó követelmény ugyanazt az állítást rögzíti, de explicit módon megfelelteti magát a BRD 4.1-es azonosítójú követelménynek. Minden követelménynek tartalmaznia kell egy tracteljesítőképességi térképpingA rendszer- és integrációs követelményeknek meg kell felelniük az azokat megvalósító kódnak és az azokat ellenőrző teszteseteknek is.
TracA teljesítőképesség tehát a projekt teljes folyamatában végponttól végpontig érvényesül.
Elsőbbséget élvez
Minden követelményt rangsorolni kell, hogy a csapat tudja, mit kell először megvalósítani, és mi várhat. A rossz példában a Hallgató regisztrálása, a Felhasználói adatok karbantartása, a Kurzusok regisztrálása és a Jelentés megtekintése mind 1-es prioritásúra van állítva. Minden nem lehet 1-es prioritású, ezért a követelményeket reálisan kell rangsorolni. A jó példa a Hallgató regisztrálása és a Kurzusok regisztrálása funkcióknak adja a legmagasabb, 1-es, a Felhasználói adatok karbantartása funkcióknak a legmagasabb, a Jelentés megtekintése funkcióknak pedig a legmagasabb prioritást.
Tesztelhető
Minden követelménynek tesztelhetőnek kell lennie. A rossz példa, miszerint „a rendszer minden oldala elfogadható időkereten belül betöltődik”, két okból sem tesztelhető. Először is, az „minden oldal” több tucat oldalt jelenthet, ami felduzzasztja a tesztelési erőfeszítéseket. Másodszor, az „elfogadható időkeret” nincs meghatározva – kinek elfogadható, és milyen viszonyítási alaphoz képest? A jó követelmény mindkét problémát megoldja az adott oldalak elnevezésével („hallgatók regisztrálása és kurzusok beiratkozása oldalak”), és egy mérhető, 5 másodperces cél kitűzésével.
