A szoftverfejlesztési folyamat követelményszakaszának előállítása az Szoftverkövetelmények specifikációi (SRS) (más néven a követelmények dokumentumát ). Ez a jelentés megalapozza a szoftverfejlesztési tevékenységeket, és akkor készül, amikor a teljes követelményeket előhívják és elemzik. SRS egy formális jelentés, amely a szoftver reprezentációjaként szolgál, amely lehetővé teszi az ügyfelek számára, hogy ellenőrizzék, hogy az (SRS) megfelel-e az igényeiknek. Ezenkívül tartalmazza a rendszer felhasználói követelményeit, valamint a rendszerkövetelmények részletes specifikációit.
Az SRS egy adott szoftvertermék, program vagy alkalmazáskészlet specifikációja, amely meghatározott funkciókat hajt végre egy adott környezetben. Több célt szolgál, attól függően, hogy ki írja. Először is, az SRS-t a rendszer kliense írhatja. Másodszor, az SRS-t a rendszer fejlesztője írhatja. A két módszer teljesen különböző helyzeteket hoz létre, és különböző célokat határoz meg a dokumentum számára. Az első eset, az SRS, a felhasználók igényeinek és elvárásainak meghatározására szolgál. A második eset, az SRS, különféle célokra íródott, és szerződéses dokumentumként szolgál az ügyfél és a fejlesztő között.
A jó SRS jellemzői
Egy jó SRS-dokumentum jellemzői a következők:
1. Helyesség: A felhasználói áttekintés az SRS-ben meghatározott követelmények pontosságának biztosítására szolgál. Az SRS-ről azt mondják, hogy tökéletes, ha minden olyan igényt lefed, amely valóban elvárható a rendszertől.
2. Teljesség: Az SRS akkor és csak akkor teljes, ha a következő elemeket tartalmazza:
(1). Minden alapvető követelmény, legyen szó funkcionalitásról, teljesítményről, tervezésről, korlátokról, attribútumokról vagy külső interfészekről.
string formátum java-ban
(2). A szoftver által adott válaszok meghatározása a bemeneti adatok összes megvalósítható osztályára az összes elérhető helyzetkategóriában.
Megjegyzés: Lényeges, hogy mind az érvényes, mind az érvénytelen értékekre adja meg a választ.
(3). Teljes címkék és hivatkozások az SRS-ben szereplő összes ábrára, táblázatra és diagramra, valamint az összes kifejezés és mértékegység meghatározása.
3. Konzisztencia: Az SRS akkor és csak akkor konzisztens, ha az ütközésben nem írják le az egyedi követelmények részhalmazát. Az SRS-ben három lehetséges konfliktustípus létezik:
(1). A valós objektumok megadott jellemzői ütközhetnek egymással. Például,
(a) A kimeneti jelentés formátuma az egyik követelményben táblázatos, a másikban pedig szöveges formában írható le.
(b) Az egyik feltétel előírhatja, hogy minden fénynek zöldnek kell lennie, míg egy másik feltétel szerint minden lámpának kéknek kell lennie.
(2). A két meghatározott cselekvés között ésszerű vagy időbeli ellentmondás lehet. Például,
(a) Egy követelmény meghatározhatja, hogy a program két bemenetet adjon hozzá, egy másik pedig azt, hogy a program megszorozza azokat.
(b) Az egyik feltétel kimondhatja, hogy „A”-nak mindig „B”-t kell követnie, míg a másik megköveteli, hogy „A” és „B” együtt forduljon elő.
(3). Két vagy több követelmény definiálhatja ugyanazt a valós objektumot, de eltérő kifejezéseket használ az objektumra. Például egy program felhasználói beviteli kérését az egyik követelményben „prompt”-nak, a másikban „jelnek” nevezhetjük. A szabványos terminológia és leírások használata elősegíti a következetességet.
4. Egyértelműség: Az SRS egyértelmű, ha minden rögzített követelménynek csak egy értelmezése van. Ez arra utal, hogy minden elemet egyedileg értelmeznek. Abban az esetben, ha több definícióval rendelkező módszert használnak, a követelményjelentésnek meg kell határoznia az SRS-ben szereplő következményeket, hogy világos és könnyen érthető legyen.
5. Rangsorolás fontosság és stabilitás alapján: Az SRS fontossági és stabilitási rangsorolása akkor történik, ha minden követelménynek van egy azonosítója, amely jelzi az adott követelmény jelentőségét vagy stabilitását.
Általában nem minden követelmény egyformán fontos. Egyes előfeltételek elengedhetetlenek lehetnek, különösen az életkritikus alkalmazásokhoz, míg mások kívánatosak lehetnek. Minden elemet azonosítani kell, hogy ezek a különbségek egyértelműek és egyértelműek legyenek. A követelmények rangsorolásának másik módja az, hogy megkülönböztetjük az elemek osztályait alapvető, feltételes és opcionális.
6. Módosíthatóság: Az SRS-t a lehető legnagyobb mértékben módosíthatóvá kell tenni, és bizonyos mértékig képesnek kell lennie a rendszer gyors módosítására. A módosításokat tökéletesen indexelni és kereszthivatkozásokkal kell ellátni.
7. Ellenőrizhetőség: Az SRS akkor helyes, ha a meghatározott követelményeket egy költséghatékony rendszerrel ellenőrizni lehet annak ellenőrzésére, hogy a végső szoftver megfelel-e ezeknek a követelményeknek. A követelmények ellenőrzése felülvizsgálatok segítségével történik.
8. Nyomon követhetőség: Az SRS akkor nyomon követhető, ha az egyes követelmények eredete világos, és megkönnyíti az egyes feltételekre való hivatkozást a jövőbeni fejlesztési vagy bővítési dokumentációban.
A nyomon követhetőségnek két típusa van:
java következő
1. Visszamenőleges nyomon követhetőség: Ez attól függ, hogy minden egyes követelmény kifejezetten hivatkozik a forrásra a korábbi dokumentumokban.
2. Továbbított nyomon követhetőség: Ez attól függ, hogy az SRS minden egyes eleme egyedi névvel vagy hivatkozási számmal rendelkezik.
mátrixszorzás c-ben
Az SRS előre nyomon követhetősége különösen fontos, amikor a szoftvertermék az üzemeltetési és karbantartási fázisba lép. Mivel a kód és a tervdokumentum módosul, meg kell tudni győződni azokról a követelményekről, amelyeket ezek a módosítások érinthetnek.
9. Tervezési függetlenség: Lehetővé kell tenni, hogy a végső rendszerhez többféle tervezési alternatíva közül válasszunk. Pontosabban, az SRS nem tartalmazhat semmilyen végrehajtási részletet.
10. Tesztelhetőség: Az SRS-t olyan módszerrel kell megírni, hogy a jelentésből könnyen lehessen teszteseteket és tesztterveket generálni.
11. Az ügyfél által érthető: Előfordulhat, hogy a végfelhasználó szakértő a saját területén, de előfordulhat, hogy nem rendelkezik számítástechnikai képzettséggel. Ezért a formális jelölések és szimbólumok célját a lehető legnagyobb mértékben el kell kerülni. A nyelvet egyszerűnek és világosnak kell tartani.
12. Az absztrakció megfelelő szintje: Ha az SRS-t a követelmények szakaszára írják, akkor a részleteket egyértelműen meg kell magyarázni. Míg a megvalósíthatósági tanulmányhoz kevesebb elemzés használható. Ezért az absztrakció szintje az SRS céljának megfelelően módosul.
Egy jó SRS dokumentum tulajdonságai
A jó SRS-dokumentum alapvető tulajdonságai a következők:
Tömör: Az SRS-jelentésnek tömörnek, ugyanakkor egyértelműnek, következetesnek és teljesnek kell lennie. A bőbeszédű és irreleváns leírások csökkentik az olvashatóságot és növelik a hibalehetőséget.
Strukturált: Jól felépítettnek kell lennie. A jól felépített dokumentum könnyen érthető és módosítható. A gyakorlatban az SRS-dokumentum több felülvizsgálaton megy keresztül, hogy megfeleljen a felhasználói követelményeknek. A felhasználói igények gyakran egy idő alatt változnak. Ezért az SRS-dokumentum módosításának megkönnyítése érdekében elengedhetetlen, hogy a jelentés jól strukturált legyen.
Fekete doboz nézet: Csak azt kell meghatároznia, hogy mit kell tennie a rendszernek, és tartózkodnia kell attól, hogy megmondja, hogyan tegye ezt. Ez azt jelenti, hogy az SRS-dokumentumnak meg kell határoznia a rendszer külső viselkedését, nem pedig a megvalósítási kérdéseket. Az SRS jelentésnek fekete dobozként kell tekintenie a fejlesztendő rendszerre, és meg kell határoznia a rendszer kívülről látható viselkedését. Emiatt az SRS-jelentést a rendszer fekete doboz-specifikációjaként is ismerik.
Fogalmi integritás: Fogalmi integritást kell mutatnia, hogy az olvasó csak megérthesse. Nem kívánt eseményekre adott válasz: Jellemeznie kell a nem kívánt eseményekre adott elfogadható válaszokat. Ezeket rendszerreakciónak nevezik kivételes körülményekre.
Igazolható: Az SRS-dokumentumban dokumentált rendszer követelményeinek megfelelőnek kell lenniük. Ez azt jelenti, hogy el kell dönteni, hogy a követelmények teljesültek-e egy megvalósításban.