#termékcímke
a szoftverkövetelmények specifikációja (SRS dokumentum) leírja, hogyan kell egy szoftverrendszert fejleszteni. Egyszerűen fogalmazva, az SRS mindenki számára biztosítja az adott projekt ütemtervét.
kiváló minőségű meghatározásokat kínál a szoftver funkcionális és nem funkcionális specifikációihoz, valamint tartalmazhat olyan használati eseteket is, amelyek bemutatják, hogy a felhasználó hogyan lépne kapcsolatba a rendszerrel a befejezés után.,
Megjegyzés: hadd segítsen írni egy szoftver követelmények specifikáció. Kérjen hívást a CTO-val az űrlap kitöltésével.
Tartalomjegyzék
miért fontos az SRS dokumentum?
tegyük fel, hogy egy konkrét megjelenésű és funkcionalitású csevegőalkalmazást szeretne létrehozni, és azt szeretné, ha kifejezetten a vállalkozásokra irányulna. Úgy érzi, hogy kivághatja azokat az extra funkciókat, amelyeket a kereskedelmi csevegőalkalmazások használnak a nyilvánosság felhívására, és a vállalkozásokra vonatkozó funkciókra összpontosíthat. De nem vagy Fejlesztő.,
tehát ki kell szerveznie az alkalmazás fejlesztését. De azt is meg kell győződnie arról, hogy bárki is bérel, hogy az ötletét valósággá tegye, pontosan tudja, mit próbál elérni. Anélkül, hogy minden részletet, hogy befejezze az alkalmazást, idő, költség gyorsan kap ki a kezét. A fejlesztőknek rossz irányba kell fordulniuk, ha a késztermék nem egyezik meg a fejedben lévő képpel.
egy SRS dokumentum arra kényszeríti Önt, hogy az ötletet papírra tegye, hogy lefedje ezeket a részleteket. Ezt az ötletet olyan nyelvre kell lefordítania, amelyet a fejlesztők megértenek., Egy SRS dokumentum leírja, hogy mit akar az ügyfél, és mit fognak nyújtani a fejlesztők. Ez az írásbeli megállapodás az alkalmazás minden részletéről.
egyértelmű követelménykészlet biztosítja, hogy a fejlesztői csapat olyan szoftvert hozzon létre, amely megfelel az ügyfelek igényeinek. Az SRS segít a munka költségeinek becslésében és a projekt hatókörének lefedésében. Ez is ad kódolók egy ötlet a tech stack lesz szükségük, és segít nekik megtervezni a munkájukat, de ez még nem minden:
- tervezők kap projekt betekintést SRS dokumentumokat, így azok megfelelnek a design a használati eset.,
- A tesztelők megkapják az üzleti igényeknek megfelelő tesztesetek létrehozására vonatkozó irányelveket.
- a végfelhasználók az SRS-t használják a szoftver megértéséhez.
- áttekintést nyújt a befektetők számára a rendszer jellemzőiről, így befektetési döntéseket hozhatnak.
az SRS azért fontos, mert egyetlen információ-és elvárásforrás, amely megakadályozza a projektmenedzserek, fejlesztők, tervezők és tesztelők közötti félreértéseket.
mit tartalmaz az SRS?,
az SRS-nek elegendő információval kell rendelkeznie a fejlesztők számára a leírt szoftver befejezéséhez. Nem csak a fejlesztés alatt álló szoftver leírását tartalmazza, hanem azt is, hogy milyen célt szolgál: mit kell tennie a szoftvernek, és hogyan kell végrehajtania.,a szoftver, vagy mi a dolga
a Különbség A Funkcionális, mind a Nem-funkcionális Követelmények
a Funkcionális követelményeket a célok, az új rendszer tervezésekor., Leírják, hogy a rendszer hogyan fog működni, hogy segítsen a felhasználó feladatait. Meghatározzák, hogy a rendszer hogyan fog reagálni a felhasználói adatokra, valamint részletesen ismertetik a számításokat, az adatbevitelt és az üzleti folyamatokat. A funkcionális követelményeket az alkalmazás funkcióinak, valamint a felhasználó igényeinek részletes leírásával tekintheti meg. A funkcionális követelmények teljesítése nélkül a rendszer nem fog működni.
míg a funkcionális követelmények meghatározzák, hogy egy rendszer mit csinál, a nem funkcionális követelmények leírják, hogy a rendszer hogyan fogja megtenni. A nem funkcionális követelmények nem befolyásolják az alkalmazás funkcionalitását., Még a nem funkcionális követelmények teljesítése nélkül is a rendszer elvégzi a kívánt feladatokat.
a nem funkcionális követelmények azért is fontosak, mert meghatározzák a felhasználói élményt befolyásoló általános jellemzőket. Ahelyett, hogy a felhasználói igényekre összpontosítanának, a felhasználói elvárásokra összpontosítanak, és olyan témákat ölelnek fel, mint a teljesítmény, a biztonság, a megbízhatóság, a rendelkezésre állás és a használhatóság.,
Hogyan írjunk egy Szoftverkövetelmény specifikációs dokumentumot
a legjobb, ha megszervezzük az SRS dokumentum írásához használt folyamatot, kezdve egy csontvázzal és általános információkkal a fejlesztendő szoftverről, majd befejezzük a részletek hozzáadásával a vázlat elkészítéséhez. Íme hat lépés az SRS-dokumentum létrehozásában:
Szerezd meg a szoftverkövetelmények specifikációs dokumentumát
segítettünk 200 + vállalatnak szoftvertermékeik elkészítésében. Bérelje fel üzleti elemzőnket 6 éves szakértelemmel, hogy SRS-t írjon az Ön számára.,
kérés SRS
hozzon létre egy vázlatot
a folyamat első lépése az SRS vázlatának létrehozása. Ezt saját maga hozhatja létre, vagy egy meglévő SRS sablont használhat kiindulási pontként. Itt van egy alapvető példa egy SRS vázlat:
Letöltés az ebook
- Bevezető
- a Célra
- célközönség
- Tervezett alkalmazás
- Hatálya
- Meghatározások
- Általános Leírás
- Felhasználói Igények
- Feltételezések, illetve Függőségek
- Rendszer Funkciók, illetve Követelményeket
- a Funkcionális Követelmények
- Külső Felület Követelmények
- Rendszer Jellemzői
- a Nem-funkcionális Követelmények
adjuk meg a Cél
Ha egy vázlatot kell részletezni., Kezdje azzal, hogy meghatározza a termék célját az SRS bevezetésében. Itt leírja a kívánt közönséget, valamint azt, hogy hogyan fogják használni a terméket. Így kell felépítenie a célt:
- határozza meg a termék hatókörét
- írja le azt az értéket, amelyet
- megmutatja, ki fogja használni a szoftvert
- részletezze, hogyan segít a tervezett felhasználók munkájában
áttekintést ad
a termék céljának meghatározása után összefoglalja, hogyan fog működni., Itt ad egy általános leírást a szoftver funkcióiról, valamint arról, hogy azok hogyan felelnek meg a felhasználó igényeinek.
leírja azokat a feltételezéseket is, amelyeket a termék funkcionalitásával kapcsolatban tesz, bármi, ami a jelenlegi tech ökoszisztémában függ.
írja le a funkcionális és nem funkcionális követelményeket
most, hogy megírta az általános információkat, itt az ideje, hogy pontosabb legyen. Az áttekintés kitöltése a funkcionális és nem funkcionális követelmények kidolgozása előtt utalást ad arra, hogy a részletek kitöltése közben biztosan megfeleljen a felhasználó alapvető igényeinek.,
a rendszer követelményeinek ez a részletes leírása az SRS-dokumentum legfontosabb eleme. Ismertesse a funkcionális követelményeket elég részletesen, hogy a fejlesztők munkához juthassanak, valamint a nem funkcionális követelményeket, például a biztonsági előírásokat és a teljesítményt.
itt adja hozzá a használati eseteket annak élénk leírásához, hogy a felhasználó hogyan fog kölcsönhatásba lépni a rendszerrel. Ez az, ahol a projekt célkitűzései részletesek, és mérni fogja, hogy a projekt halad a fejlesztés során.,
kiegészítő adatok hozzáadása
az SRS-dokumentum tervezetének elkészítésének utolsó lépése minden olyan részlet hozzáadása, amely segíthet a fejlesztőknek befejezni a munkát függelékek, kifejezések szójegyzékei és referenciák formájában.
jóváhagyás megszerzése
miután elegendő részletet adott hozzá az SRS-hez, hogy leírja, mit kell tennie a rendszernek, itt az ideje, hogy az érdekelt felek jóváhagyják a dokumentumot.
valószínűleg prezentációt kell készítenie a fejlesztési folyamatban részt vevő embereknek., Kérhetnek változtatásokat, és a végleges jóváhagyás előtt az érdekelt felek visszajelzései alapján frissíteniük kell az SRS-dokumentumot.
Ez jó jel. Ez azt jelenti, hogy mind a fejlesztők, mind az érdekelt felek pontosabbá teszik a dokumentumot, így a projekt kevésbé szeretne elindulni.
hogyan kell írni a Szoftverhasználati eseteket SRS
egy használati eset leírja, hogy a felhasználó hogyan fog kölcsönhatásba lépni a rendszerrel. A terméket a végfelhasználó szempontjából egyszerű történet formátumban írja le. A használati esetek kiírása arra készteti Önt, hogy átgondolja, mit fognak tenni a felhasználók a szoftverrel, és hogyan fognak reagálni., Ez a funkcionális követelmények valós vizualizációja.
itt vannak olyan lépések, amelyeket követhet a használati eset megírásához:
- írja le a termék végfelhasználóit.
- összpontosítson az egyik ilyen felhasználóra.
- szakítsa meg a felhasználó interakcióit Használati esetekre. Minden interakció egy használati eset.
- írja le az egyes használati esetek eseménysorozatát.
- írja le a felhasználó műveleteinek részletes leírását, valamint azt, hogy a rendszernek hogyan kell reagálnia.
- bontsa ki az egyes használati eseteket alternatív felhasználói műveletekkel és rendszerválaszokkal.
- ismételje meg az 1-6-ot minden végfelhasználó típus esetében.,
melyek a nagy SRS jellemzői?
vannak olyan sajátosságok, amelyeknek minden SRS-nek rendelkeznie kell. A lista áttekintésével és az SRS-hez való összehasonlításával biztosíthatja, hogy hasznos dokumentum legyen minden érdekelt fél számára.
Explicit
az SRS dokumentumnak könnyen érthetőnek kell lennie. Semmi sem lehet homályos, így nincsenek félreértések az érdekeltek között.,
mérhető
az SRS dokumentumban szereplő követelményeknek mérhetőnek kell lenniük, így a késztermék validálható és ellenőrizhető a specifikációk alapján.
Complete
az SRS dokumentumnak elegendő információval kell rendelkeznie ahhoz, hogy a fejlesztőcsapat befejezze a terméket, valamint a tesztelők számára annak igazolására, hogy a termék hiba nélkül megfelel a felhasználó igényeinek.
életképes
a követelményeknek illeszkedniük kell a jelenlegi környezet valóságához, beleértve a költségvetést, az ütemtervet és a technológiát. Nem függhetnek a közelgő technológiai áttörésektől.,
rugalmas
mivel a dolgok megváltozhatnak a munkakörnyezetben, az SRS-dokumentumnak elég rugalmasnak kell lennie a frissítések engedélyezéséhez. Ne adjon hozzá felesleges információkat több szakaszhoz, amelyeket minden módosítással frissíteni kell.
ellenőrizhető
a fejlesztőcsapat minden tagjának hozzáférnie kell a dokumentumhoz, hogy minél gyakrabban hivatkozhassanak rá. A követelményeknek pontosnak kell lenniük, hogy a csapattagoknak ne kelljen további részleteket kérniük. Mindegyiknek rendelkezésre kell állnia az SRS dokumentumban.,
következetes
a követelményeknek illeszkedniük kell egymáshoz. A követelmények dokumentumának egyik szakasza nem ütközhet a másikkal. A dokumentumot következetesen kell formázni, és ugyanazt a terminológiát kell használni.
nincs végrehajtási korlátozás
az SRS dokumentumnak elég részletesnek kell lennie a munka befejezéséhez, de nem szabad túlságosan specifikusnak lennie, mert ez korlátozhatja a fejlesztést. A fejlesztés nagy része olyan harmadik féltől származó szolgáltatásoktól függ, amelyeket a fejlesztők nem tudnak ellenőrizni.,
pontos
a követelmények dokumentumban szereplő céloknak pontosnak kell lenniük a félreértések elkerülése érdekében. Kerülje a következőket:
- kiskapuk: “az alkalmazásnak 3 másodperc alatt kell betöltenie, ha meg lehet csinálni.”
- kétértelműség: “az MVP terméket a lehető leggyorsabban fel kell szabadítani.”
- szubjektivitás: “a felhasználói felületnek felhasználóbarátnak kell lennie.”
- Superlatives: “ez a legjobb alkalmazás az osztályában.”
- összehasonlító: “ennek az alkalmazásnak jobbnak kell lennie, mint a Slack.,”
A Software Requirement Specification (SRS) Example
itt van egy levágott példa egy SRS dokumentumra egy eChat nevű vállalati csevegőalkalmazáshoz:
Bevezetés
Ez a dokumentum részletezi az “eChat” fejlesztésére vonatkozó projekttervet.”
az “eChat” – on dolgozó fejlesztőknek, tervezőknek és tesztelőknek, valamint projektbefektetőknek szánják., Ez a terv tartalmazza összefoglalása:
- hogy a rendszer függvény
- a projekt hatókörét a fejlesztési szempontból
- a technológia fejlesztése a projekt, meg
- a mutatókat használják, hogy meghatározzák a projekt előrehaladását
- Általános Leírás
a Vállalatoknak szükségük van a távoli kommunikációs eszköz, főleg most, hogy egyre több ember dolgozik otthon. A probléma az, hogy a legtöbb vállalat ennek megvalósításához több alkalmazást használ: egyet szöveges csevegésre, egyet videocsevegésre, egyet konferenciákra és találkozókra., az “eChat” megoldja ezt a problémát azáltal, hogy ezeket a funkciókat egy alkalmazásban egyesíti.
bemutatkozó füzet Letöltése
az Ügyfelek
A vásárlók lesz enterprise vállalatok. Nem fogja megcélozni a nagyközönséget.
funkcionalitás
- a felhasználóknak képesnek kell lenniük arra, hogy regisztráljanak az enterprise LDAP fiókokkal.,a
- felhasználóknak képesnek kell lenniük arra, hogy ad hoc csevegőcsoportokat hozzanak létre, amelyek felhasználói csoportokból állnak, és privát üzeneteket küldjenek az egyes felhasználóknak.
- a felhasználóknak képesnek kell lenniük szöveges csevegésekre, amelyeket szálakra bonthatnak.
- az alkalmazásnak képesnek kell lennie arra, hogy egyszerre akár 100 felhasználó Csoportos videocsevegését kezelje.
Platform
Az alkalmazás a React Native-ban kerül kifejlesztésre, hogy lehetővé váljon egy webes alkalmazás, egy iOS mobilalkalmazás és egy Android mobilalkalmazás létrehozása.
Ezek az alkalmazások csatlakozni fog a REST API beépített .,NET Core adatok tárolására és lekérésére egy MySQL adatbázisból.
A hitelesítés a meglévő LDAP-telepítéseken keresztül történik.
fejlesztési feladatok
az “eChat” csapat fejlesztői felelősek az alkalmazás összes kódjának megírásáért, az adatbázis fejlesztéséért, valamint a kiadások kezeléséért.,
felhasználói osztály és jellemzők
lesz egy admin nevű felhasználói osztály, amely jogosultsággal rendelkezik az alkalmazás összes funkciójának eléréséhez, beleértve:
- csatornák létrehozása, ahol több felhasználó kölcsönhatásba léphet
- ezeknek a csatornáknak a nyilvánosságra hozatala az egész társaság vagy magánszemély számára
- ezeknek a csatornáknak a Törlése
- archiválása
a szokásos felhasználók hozzáférhetnek az alkalmazás összes funkciójához, kivéve a fent felsoroltak.,
rendszerjellemzők
funkcionális követelmények
- a felhasználóknak képesnek kell lenniük arra, hogy ad hoc csevegőcsoportokat hozzanak létre, amelyek felhasználókból állnak, és privát üzeneteket küldjenek más felhasználóknak.
- a felhasználóknak képesnek kell lenniük szöveges csevegésekre, amelyeket szálakra bonthatnak.
- a csevegéseket határozatlan időre archiválni kell, hogy a felhasználók hivatkozhassanak a korábbi csevegésekre.
- a felhasználóknak referenciaként képesnek kell lenniük fájlok feltöltésére a csevegésekre.
- külső interfész követelmények
felhasználói felületek
- Front-end szoftver: React Native
- Back-end szoftver:.,s operációs rendszereken keresztül az alapértelmezett böngésző
- iPhone
- Android
- a Nem-Funkcionális Követelmények
Teljesítmény-Követelmények
- Az alkalmazás kell a terhelést, mind a használható 3 másodpercen belül
- Az alkalmazás frissíteni kell a felületet, kölcsönhatás 2 másodpercen belül
- Az adatbázisban kell normalizált, hogy megakadályozza a felesleges adatokat, illetve a teljesítmény javítása érdekében
- Az adatbázisban kell elosztani, hogy megakadályozzák a kimaradások
Biztonsági Követelmények
- Adatbázisokat kell használni sharding, hogy felesleges, hogy megakadályozza az adatvesztést.,
- az adatbázisok biztonsági mentését óránként kell elvégezni, és egy hétig kell tartani.
biztonsági követelmények
- a REST API-hoz használt kulcsokat biztonságosan kell tárolni.
- csak a REST API-nak kell tudnia csatlakozni az adatbázisokhoz.
- az adatbázisoknak tűzfal mögött kell lenniük.
szoftverminőségi attribútumok
- elérhetőség: mivel ez az alkalmazás kritikus az üzleti kommunikációhoz, négy kilenc(99,99%) elérhetőséget fogunk elérni.,
- helyesség: az alkalmazásnak soha nem szabad megengednie, hogy bárki elolvassa az adott személynek nem szánt üzeneteket vagy megbeszéléseket.
- karbantarthatóság: az alkalmazásnak folyamatos integrációt kell használnia, hogy a funkciók és hibajavítások leállás nélkül gyorsan telepíthetők legyenek.
- használhatóság: az interfésznek könnyen megtanulhatónak kell lennie bemutató nélkül, és lehetővé kell tennie a felhasználók számára, hogy hiba nélkül elérjék céljaikat.
összefoglaló
egy SRS dokumentum szükséges része egy szoftverfejlesztési projekt megvalósításának., Ez az ütemterv ad irányt mindenkinek, aki részt vesz a projektben, így a végtermék megfelel a felhasználó igényeinek.
a teljes SRS-dokumentum nélkül, mielőtt elindít egy projektet, nehéz lesz megmondani, hogy mikor fejeződik be a projekt, és elkerülheti a fejlesztést a nem kívánt funkciók létrehozásába. Egy SRS dokumentum lehetővé teszi a projekt pontos becslését, valamint a feladatok hatékony hozzárendelését.
SRS-dokumentum létrehozása időigényes, aprólékos folyamat lehet., Szerencsére az érintett csapat több mint 200 vállalatnak segített SRS dokumentumok létrehozásában és új termékek bevezetésében. Készek vagyunk, hogy segítsen a következő szoftver projekt, csak csepp nekünk egy sort.