6 lépés egy SRS dokumentum írásához, amely működik + sablon
a Szoftverspecifikációs dokumentumokat néha olyan tárgyaknak tekintik, amelyeknek csak a fejlesztők számára van értelme. Az SRS dokumentum azonban tovább mehet, és útmutatóvá válhat a marketing szakemberek, az érdekeltek, a tervezőcsapatok, sőt a felhasználók számára is.
ez a cikk elmagyarázza, hogy miért fontos a szoftverdokumentáció, és hogyan kell megírni az SRS dokumentumot, hogy gyakorlati útmutató legyen minden csapatszakértő számára.
mi az SRS dokumentum és miért számít?
az SRS (software requirement specification) dokumentum egy olyan műtárgy, amely tartalmazza a jövőbeli termékekre vonatkozó követelményeket, elvárásokat és szabványokat. Ez kiterjedhet szöveges dokumentumokra, táblázatokra, sémákra, precedensekre és egyéb elemekre, amelyek tisztázzák a termék jövőképét. Más szavakkal, az SRS dokumentum részletes leírást ad arról, hogy a terméknek hogyan kell működnie, és hogyan kell a termékfejlesztő csapatnak végrehajtania.
képzelje el, mint egy hajó építése. Látomása van az árbocról vagy a vitorláról, sőt el is tudja képzelni, hogyan halad át a hullámokon. A hajó vízre helyezéséhez azonban szigorúbb részletekre van szükség.
ugyanez vonatkozik a termékfejlesztésre is. Világos képet kaphat egy olyan alkalmazásról, amelyet építeni szeretne az összes funkcióval, tervezési elemekkel és gombokkal. A funkciók szóbeli leírása azonban nem elegendő ahhoz, hogy a fejlesztők megvalósítsák az ötletet.
ahhoz, hogy az eredmény megfeleljen a fejedben lévő képnek, papíron pontosan meg kell magyaráznia, hogyan kell működnie egy funkciónak. Az SRS dokumentum kiváló eszköz az ilyen technikai részletek leírására.
.jpg)
ki ír SRS dokumentumot?
az SRS dokumentum megírása azt jelenti, hogy a jellemzők, feladatok és célok általános leírását át kell vinni a technikai megvalósítás részletes tervébe.
az SRS dokumentumokat általában termék-és projektmenedzserek vagy üzleti elemzők írják, akik közvetlenül kommunikálnak az ügyfelekkel, vagy akik felhasználói kutatást végeznek (akik szintén drótvázon dolgoznak, és tudják, hogyan kell viselkedni a terméken), és összegyűjtik a jövőbeli termékek követelményeit.
közben ez a dokumentum. A jó SRS dokumentum nem kizárólag technikai jellegű, mivel kiterjed az üzleti célokra, a mutatókra, a felhasználói problémákra, a felhasználói személyekre stb.
3 Miért fontos az SRS dokumentum
tehát az SRS dokumentum teljes értéke egyértelmű. Íme az oka annak, hogy a szoftverkövetelmények specifikációs dokumentumai elengedhetetlenek:
az SRS egy kommunikációs pont
élő dokumentumként az SRS dokumentum kommunikációs platformként szolgál az összes szakember között: Fejlesztők, marketing szakemberek és társalapítók.
az SRS dokumentum részleteinek formális vagy informális magyarázatával a vezetők egyetértenek az ügyfelekkel az eredmények elvárásairól. Eközben, ha a követelmények módosulnak, az ügyfél és/vagy a termék tulajdonosa ellenőrizheti és érvényesítheti azokat a dokumentumban. A fejlesztők pedig felelősek azért, hogy megfeleljenek ezeknek az elvárásoknak.
a funkciók végleges leírása
az SRS dokumentálja a szoftver végleges verzióit, amelyek az ügyfelekkel korábban tárgyalt feltételezésekből származnak. Találkozók és hívások, felhasználói tesztek és interjúk során a termékverziók nagyon gyakran változhatnak. Néha még a termékmenedzserek is eláraszthatják a meglévő termék iterációkat. Az SRS fájl segít egyesíteni ezeket a követelményeket egy szabványba, és kiküszöbölni a termékkövetelményekkel kapcsolatos félreértéseket.
az SRS egy szabványos útmutató a termékfejlesztők számára
a termékkövetelmények leírása mellett az SRS dokumentum útmutatást nyújt a Fejlesztőcsapatnak arról, hogy milyen lépéseket kell követniük egy olyan termék létrehozásához, amelyet az ügyfél akar.
a projekt szervezetétől függően a fejlesztők részt vehetnek vagy nem vehetnek részt a projekt elemző részében. Mindkét esetben meg kell állapítaniuk, hogyan kell működnie a rendszernek, meg kell határozniuk a követelményeket és a kódparamétereket.
Hasonlóképpen, a minőségbiztosítási szakembereknek meg kell érteniük a termék koncepciója mögött rejlő összes technikai szempontot. Így az SRS dokumentáció szabványként szolgál a minőségbiztosítási tesztek tervezéséhez és futtatásához.
végül a tervezők az SRS dokumentumokon keresztül kapnak betekintést a projektbe, hogy a tervet a használati esethez igazítsák.
6 A jó SRS dokumentum írásának lépései
a funkcionális és nem funkcionális követelmények minden SRS-dokumentum nagy részét képezik. A termékmenedzserek nem egyszerűen a semmiből veszik ezeket a követelményeket. Ezek az ügyfelekkel folytatott pontos kommunikáció, valamint a mélyreható felhasználói és műszaki kutatások eredményei. Itt vannak a kiváló SRS dokumentáció írásának fő lépései:
1. lépés. Kommunikáció az érdekelt felekkel
a bizonytalanság első rétegét eltávolítjuk azzal, hogy megkérdezzük az érdekelt feleket a termékkel kapcsolatos elvárásaikról. Persze, egy ilyen interjú csak egy kicsit megérti a követelményeket. Ez azonban még mindig nagyszerű kiindulópont a kutatáshoz.
az Uptech-nél először beszélünk az ügyféllel az értékesítés előtti és a Kick-Off híváskor, amikor megpróbáljuk kitalálni, hogy illeszkedünk-e egymáshoz. Igyekszünk kristályosítani a legcsekélyebb részleteket az ügyfélről, hogy megértse ötletét.
az egyszerű kommunikáció azonban nem ad elegendő információt a termék célközönségéről, kívánságairól és igényeiről. Tehát folytatjuk a felfedezés szakaszát, hogy világossá tegyük.
2. lépés. Discovery Stage
a felfedezés szakaszában kritikus írásban SRS dokumentáció. Ebben a szakaszban lehetőségünk van arra, hogy feltárjuk azt a problémát, amelyet a terméknek meg kell oldania, érdekeit és igényeit. Célunk a felhasználók problémáinak azonosítása és a lehetséges megoldások hipotéziseinek meghatározása. Ilyen megközelítéssel az alkalmazást értékessé tehetjük a felhasználó számára.
használati esetek vs felhasználói történetek
minden felhasználói adat egy SRS-dokumentum részévé válik, mint használati esetek és felhasználói történetek. A két kategória közötti különbség széles körben vitatott a termékfejlesztő közösség körében.
egyszerűen fogalmazva, a felhasználói történetek jobban összpontosítanak az eredményre és az előnyökre, amelyeket a felhasználó egy funkció használata közben kap. Míg a használati esetek részletesebben leírják magát a funkciót.
például a Yaza projekt több felhasználói interjúja után arra a következtetésre jutottunk, hogy az alkalmazásnak csevegnie kell. Tehát egy ilyen eset felhasználói története így hangzik: “felhasználóként beszélgetni akarok egy potenciális háztulajdonossal.”
eközben a történet Használati esete leírja a felhasználó minden lépését a cél eléréséhez – ” felhasználóként hozzá kell adnom egy névjegyet a csevegési listámhoz, és üzenetet kell küldenem neki, hogy…”.
3. lépés. Építsd meg a struktúrát
miután a felfedezés befejeződött, folytatjuk az SRS dokumentáció írását. Először is szükségünk van a dokumentum rövid felépítésére. Az SRS dokumentum tartalma jelentősen eltérhet, de a tipikus SRS dokumentációs struktúra így néz ki:
1. Bevezetés
az intro összefoglalja a dokumentum tartalmát. A következő kérdésekre kell válaszolnia:
- a dokumentum tartalmának rövid leírása;
- a dokumentum tervezett olvasói;
- az Ön által fejlesztett szoftver ötlete;
- tervezett olvasók.
1.1 üzleti célok
állítsa be a projekten elérni kívánt célok listáját, például MVP létrehozása, többplatformos mobilalkalmazás létrehozása vagy webhely indítása.
ezenkívül ennek a szakasznak tükröznie kell vállalkozásának céljait és sikermutatóit. Bár egyesek kizárhatják ezt a részt a dokumentumból, feltétlenül meg kell jelölni ezeket a dolgokat, mivel ezek közvetlenül befolyásolják a kutatást és a fejlesztést.
1.3 Rendeltetésszerű használat
hogyan képzeli el, hogy az egyén használni fogja a terméket? Milyen funkciókat biztosít az ilyen típusú használathoz? Ismertesse az összes lehetséges módot, amellyel egy személy használhatja a terméket bármilyen felhasználói szerepkörben.
1.4 hatókör
ez a rész leírja az ötlet megvalósításához szükséges munka körét.
1.5 definíciók és betűszavak
ez a dokumentum meghatározza a dokumentumban használt kifejezések definícióit, hogy biztosítsa a felhasználók teljes megértését.
2. Általános leírás
itt van az a rész, ahol elmagyarázza az alkalmazás ötletét, honnan származik, és miért lehet érdekes a felhasználók számára.
2.1 felhasználói igények
egy mindenki számára épített szoftver senkit sem szolgál. De ha pontosan tudod, hogy ki a célközönséged, hol dolgoznak, és a fájdalmaik, akkor nagyobb esélyed lesz arra, hogy olyan alkalmazást szállítson, amelyet a felhasználók széles körben elfogadnak.
3. Rendszer Jellemzők és követelmények
itt az ideje, hogy felvázolja a jövőbeli szoftver műszaki követelményeit. Ismertesse azokat a funkciókat, amelyeket a termék tartalmaz, valamint a termékek minőségét meghatározó szabványokat.
3.1 funkcionális követelmények
a funkcionális követelmények olyan rendszerspecifikációk, amelyek nélkül a szoftver nem fog megfelelően működni. A szoftver funkcióinak meghatározása meghatározza, hogyan fogják azokat tovább megvalósítani.
3.2 nem funkcionális követelmények
míg a funkcionális követelmények meghatározzák, hogy mi lesz a rendszer funkciója, a nem funkcionális követelmények meghatározzák, hogy a rendszer hogyan fogja megvalósítani ezeket a funkciókat, például a Befejezés sebességét.
3.3 Tech Stack
a tech stack szoftver vagy projekt létrehozására és futtatására használt technikai megoldások összessége. Fontos, hogy jelezze azt az SRS dokumentumban, mivel meghatározza az összes többi technikai részletet.
.jpg)
4. lépés. Készítsen általános leírást
mielőtt belemerülne a termék részleteibe, adjon általános áttekintést az alkalmazás főbb jellemzőiről. Egyszerűen magyarázza el az alkalmazás célját, funkcióit, és hogyan oldja meg a felhasználó problémáját.
5.lépés. Define Functional and Non-Functional Requirements
az SRS dokumentum magja általában a termék funkcionális és nem funkcionális követelményeiből áll. Ezekkel a specifikációkkal további részleteket ad hozzá az Általános áttekintéshez, és így végigvezeti a csapatot az alkalmazás MŰSZAKI specifikációin.
a funkcionális és nem funkcionális követelmények közötti különbség egy másik ragaszkodási pont a termékfejlesztő közösségben. Ebben a cikkben megosztottuk a témával kapcsolatos szakértelmünket.
6.lépés. Győződjön meg arról, hogy az ügyfél ugyanazon az oldalon
a jóváhagyás a fejlesztés nagyon várt része. Az ügyfél szerkesztései azonban néha megtagadhatják a projekt egy bizonyos pontján befejezett munka teljes mennyiségét.
a nyomás elkerülése érdekében javasoljuk, hogy fogadja el a kitöltött SRS dokumentáció kis részeit, ahelyett, hogy egyszerre egy teljes dokumentumcsomagot nyújtana be. Ez segít bizonyos problémák gyors megoldásában, és kevésbé zavaró.
Szakértői tippek a nagyszerű SRS dokumentáció megírásához
időbe telik, hogy élesíteni a készség az írás kiváló SRS dokumentáció. Tapasztalataink alapján összeállítottuk az SRS dokumentáció írásával kapcsolatos szakértői tippek listáját. Tehát itt van néhány betekintést, hogy teszi a SRS dokumentáció hatékony:
legyen egyszerű
ez aligha titok, de egyszerű dolgok uralják a világot. Ez minden bizonnyal igaz bármilyen típusú dokumentációra, amelyen dolgozik. Az SRS a jövőbeli termék egységes leírása az egész csapat számára. Ez azt jelenti, hogy az SRS dokumentum nyelvének, szerkezetének és megfogalmazásának a lehető leglakonikusabbnak kell lennie.
tartalmazza az üzleti célokat
bár az SRS dokumentum elsősorban a technikai jellemzőkre összpontosít, beleértve az üzleti célokat is jó gyakorlat. Az SRS dokumentum a Fejlesztőcsapatnak szóló utasítás, a termékösszefoglaló pedig a termékhez kapcsolódó nem technológiai szakemberek számára. Továbbá, beleértve az üzleti követelményeket, például a mutatókat és célokat, az SRS-t egységes eszközzé teszi az egész csapat számára.
felhasználói adatok hozzáadása
a felfedezési szakasz általában a legértékesebb információkat tárja fel a felhasználóról. Ha ezt az információt hozzáadja az SRS dokumentumhoz, az hasznos dokumentum lesz a tervező és fejlesztő csapat számára.
kezelje az SRS-t Élő dokumentumként
az SRS-dokumentumnak nem szabad statikusnak lennie, még akkor sem, ha összeállította a projekthez szükséges összes csomagot. Az agilis ökoszisztémákban a projektek minden elhaladó iterációval új funkciókat szereznek. Minden ilyen módosítást és módosítást közölni kell az SRS dokumentumban, és egyeztetni kell az ügyféllel.
következtetés
az SRS dokumentumok írása mélyreható kutatást, elemzést és erőfeszítést igényel. Azonban egy átfogó SRS dokumentum, amely magában foglalja az üzleti jellemzőket, a technikai részleteket és a felhasználói adatokat, lenyűgöző termékkel jár, amely megfelel mind az ügyfél, mind a felhasználók elvárásainak.
az Uptech ötéves tapasztalattal rendelkezik a virágzó startupok termékeinek gyártásában. Tudjuk, hogyan tárhatjuk fel a felhasználók igényeit, és hogyan tehetjük az SRS documentet hatékony projektmenedzsment eszközzé a porral borított papírok helyett.
F. A. Q.
mi az SRS?
az SRS egy alkalmazás vagy szoftver műszaki előírásainak és követelményeinek részletes leírását tartalmazó dokumentum. Az SRS arra is utasítja a fejlesztőket, hogyan valósítsák meg a termék ötletét az ügyfél elvárásainak megfelelően.
mi az SRS dokumentum célja?
az SRS dokumentum célja, hogy műszaki leírást adjon a termék jellemzőiről, műszaki és nem műszaki követelményeket adjon meg, és útmutatást adjon a Fejlesztőcsapatnak a megvalósításhoz.
ki írja az SRS dokumentumokat?
a csapat összetételétől függően az SRS dokumentumokat általában:
- termékmenedzser;
- projektmenedzser;
- üzleti elemző;
- Műszaki Mérnök.