a szoftverfejlesztés izgalmas folyamat lehet a kreatív problémamegoldásban, tervezésben és tervezésben. De a fényes alkalmazások és a polírozott weboldalak alatt a kevésbé szexi, mégis annyira fontos állványzat található, amely lehetővé teszi a jó szoftvereredményeket: a dokumentációt.

A dokumentáció biztosítja, hogy a csapatok és az egyes érdekelt felek ugyanazon az oldalon legyenek egy termék vagy szoftver alkalmazás céljaival, hatókörével, korlátaival és funkcionális követelményeivel kapcsolatban.

sajnos, a folyamat létrehozása, dokumentálása ezeket a követelményeket lehet unalmas, zavaró, rendetlen.

szoftverkövetelmények a dokumentumok gyorsan hosszú, nehéz, szöveges dokumentumokká válhatnak, így különösen sebezhetővé válnak a hibákkal, következetlenségekkel és félreértelmezésekkel szemben. Emiatt a dokumentumok írása és használata időigényes lehet, és költséges (és elkerülhető) tervezési hibákhoz vezethet.

tehát mit kell tenniük a termékmenedzsereknek, a szoftvercsapatoknak és az üzleti vezetőknek?

bár a szoftverfejlesztési megközelítések esetében nincs mindenki számára megfelelő szabály, vannak módok a hibák csökkentésére, időmegtakarításra és hatékony eredmények elérésére.

Az alábbiakban végigsétálunk a szoftverkövetelmények dokumentumainak céljain és előnyein, valamint néhány olyan bevált gyakorlaton,amelyek segítenek a folyamat elejétől a végéig.

mik azok a szoftverkövetelmények?

a szoftverkövetelményekről szóló dokumentum (más néven szoftverkövetelmények specifikációi) olyan dokumentum vagy dokumentációkészlet, amely felvázolja egy szoftveralkalmazás jellemzőit és tervezett viselkedését.

más szóval, a szoftverkövetelmények dokumentum (SRD) leírja az üzleti vagy szervezet megértését a végfelhasználó (általában az ügyfél) igényeiről és függőségeiről, valamint a rendszer bármely korlátozásáról.

mit tartalmaz az SRD?

míg az SRD egy projekt hatókörének kezelésére szolgáló tervrajzként működik, végül csak egy rendszer funkcionális és nem funkcionális követelményeit határozza meg. A dokumentum nem vázolja fel a tervezési vagy technológiai megoldásokat. Ezeket a döntéseket később a fejlesztők hozzák meg.

egy jól megírt SRD-nek:

• a problémát kezelhető részekre kell törnie.
• referenciaként szolgál a teszteléshez és érvényesítéshez.
• tájékoztassa a tervezési előírásokat (azaz az SRD-nek elegendő információt kell tartalmaznia a szoftver követelményeiről a hatékony tervezés érdekében).
• visszajelzést ad az ügyfélnek (végfelhasználó).

az SRD bemutatja az ügyfélnek, hogy szervezete megérti a megoldandó problémát, valamint azt, hogy miként kezelheti ezeket a problémákat szoftveres megoldásokkal. Mivel az ügyfelek gyakran közvetlen érdekeltek, különösen fontos, hogy a dokumentációt egyértelműen laikus megfogalmazásban dolgozzák ki (elkerülve a technikai zsargont).

ismét az SRD írásának módja attól függ, hogy csapata vagy szervezete milyen megközelítést és módszert alkalmaz. Azonban a szabványok IEEE szervezet azt javasolja, tipikus SRDs ki kell terjednie az alábbi témakörökre:

• Felületek
• a Funkcionális Képességek
• Teljesítmény Szintek
• adatszerkezetek/Elem
• Biztonsági
• Megbízhatóság
• Biztonság/Adatvédelmi
• Minőségű
• Korlátokkal, illetve a Korlátozások

Ha ezek a témák egyértelműen foglalkozott, majd felvázolta a dokumentációt, akkor egy teljesebb képet a szükséges információkat, hogy fejleszteni kell a kérelmet.

hogyan köröm a szoftver követelmények dokumentum

bármilyen megközelítést, hogy a dokumentáció, kövesse ezeket a legjobb gyakorlatokat, hogy hozzon létre egy hatékony és hatékony SRD.

szervezze meg

a játék neve szervezet. Mielőtt elkezdené ténylegesen dokumentálása, győződjön meg róla, hogy indul egy szervezet stratégia az összes dokumentumot, beleértve, ahol a docs tárolják, hogyan lehet biztosítani a következetesség, és hogyan közreműködők és együttműködők könnyen tartani dokumentumokat up-to-date. Ahhoz, hogy hatékony legyen, egy szoftverkövetelményekről szóló dokumentumot kell megszervezni és tisztázni. Sok szervezet a ház sablonjaira támaszkodik, hogy fenntartsa a következetességet a projektek között. Sablonok egy nagyszerű módja annak, hogy időt takaríthat meg (csak töltse ki az előre szervezett szakaszok), és konzisztens marad a dokumentációs folyamat.

a dokumentumsablonok azonban gyakran megerősítik a hosszú, szöveges nehéz követelmények problémáját. Annak elkerülése érdekében, hogy elakadjon a szövegoldalakon, fontolja meg a dokumentációs folyamat vizuális adatokkal történő kiegészítését.

biztosítani kell a követelmények teljes

egy követelmény, hogy” teljes”, tartalmaznia kell az összes szükséges információt a követelmény végrehajtásához. Ez azt jelenti, hogy amikor a tervezők, fejlesztők megy, hogy építsenek ki a funkció, akkor nem maradt, hogy feltételezések vagy találgatások a követelmény.

például tegyük fel, hogy egy weboldalt fejleszt. Az egyik felvázolt követelmény az, hogy mi történjen hiba esetén. A hiányos követelmény mondhat valamit, mint például: “hiba esetén a rendszernek zökkenőmentesen kell kilépnie.”

ebben az esetben a “simán” nincs meghatározva, és az értelmezésre marad. Ez a kétértelműség a kívánt eredmények félreértelmezéséhez vezethet (és több munkát kell visszamenni és megjavítani).

ennek elkerülése érdekében írjon be egy teljes követelményt, amely meghatározza, hogy néz ki egy sikeres funkció:

“hiba esetén a rendszernek hibaoldalt kell mutatnia a következő üzenettel:

Uh-oh! Úgy tűnik, valami elromlott. Kérjük, próbálja újra néhány perc múlva. Ha a probléma továbbra is fennáll, vegye fel a kapcsolatot Ügyfélszolgálatunkkal [email protected]. ”

a teljes követelmény meghatározásával kevesebb a kétértelműség és egyértelmű eredmény a fejlesztő csapat számára.

Hogy követelményeknek tesztelhető

Ez egy meglehetősen elterjedt szabvány, mégis túl gyakran szervezetek nem írja követelményeket, amelyek teljes mértékben megfelelnek ez a szabály.

a követelményeket ellenőrizni kell. Ellenkező esetben nem lehet objektív módon tudni, hogy a követelményt kielégítően hajtották-e végre.

minden követelményt ír, győződjön meg róla, hogy érvényesített keresztül egy vagy több a következő módon:

• Ellenőrzés
• Bemutató
• Séta
• Tesztelés

Magas szintű követelményeket gyakran vetik a vizsgálat, illetve a felhasználói tesztelés, így általában támaszkodni több általános előírások. De az alacsonyabb szintű követelmények, amelyek szoftvervizsgálaton mennek keresztül, valószínűleg részletesebb specifikációkra lesz szükségük.

implementációs-semleges funkcionális követelmények alkalmazása

amint azt korábban megjegyeztük, az SRD nem tervezési dokumentum. Nem határozza meg, és nem is szabad, hogy a funkcionális követelményeket tervezési szempontból hogyan kell megvalósítani.

ezért minden funkcionális követelménynek megvalósítás-semlegesnek kell lennie. Más szavakkal, a követelményeknek meg kell jelölniük, hogy mit kell tennie a rendszernek, de nem azt, hogy hogyan kell csinálni.

a megvalósításnak számos előnye van-semleges követelmények, beleértve:

• hatékonyabb tervezési folyamat
• Módosítható követelmények, amelyek nem függnek a konkrét végrehajtási design
• Kevesebb konfliktus eredő követelmények a szembenálló megvalósítás részleteit

Minden megszorítások végrehajtási fenn kell tartani a nem-funkcionális követelmények a rendszer.

értékelje dokumentációt az érdekelt felekkel

amikor az összes szoftverkövetelményt dokumentálták, minden érintett fél értékelje a végső dokumentációt a fejlesztés megkezdése előtt.

az Érdekeltek tartalmaznia kell a tervezők, fejlesztők, tesztelők, aki majd érvényesíti a követelményeknek, mérnökök, végfelhasználói képviselői, illetve az ügyfél.

azáltal, hogy minden érdekelt fél felülvizsgálja és jóváhagyja a dokumentációt a fejlesztés megkezdése előtt, javítja az elégedettséget a csapatok között, és növeli annak valószínűségét, hogy a követelmények kielégítik igényeiket.

Help szoftverfejlesztők és csapataik ugyanazon az oldalon maradnak folyamatábrák segítségével, amelyek hatékonyan és elegánsan leképezik a szoftverkövetelmények specifikációit. Keressen egy diagramming megoldást, amely segíthet:

• rendszerezze a követelményeket egy folyamatábra, hogy az összetevők elkülönüljenek, a függőségek egyértelműek legyenek, az érdekelt felek pedig nyilvánvalóak.
• a swimlanes használatával vizuálisan leírhatja, hogy mely csapatok felelősek az egyes követelménykészletekért.
• gyorsan módosíthatja a követelményeket vagy más adatokat, mivel a projekt igényei fejlődnek.
• Link adatok (beleértve a további dokumentumokat), hogy támogassa és tájékoztassa a folyamatban lévő projekt.
• ossza meg a dokumentációt (és minden változást) azonnal az érintett felekkel.

a dokumentációnak nem kell házimunkának lennie. A Lucidchart segítségével könnyen dokumentálhatja a folyamatokat, a felhasználói történeteket, valamint a szoftverkövetelményeket egy helyen. A követelmények specifikációinak vizuális meghatározásával Ön és csapata gyorsan képes lesz információt találni és cselekedni, miközben csökkenti a hibák, következetlenségek és félreértelmezések lehetőségeit.

kezdje el dokumentálni a

láthatóságot szerezni a meglévő műszaki rendszerekben a Lucidchart segítségével.

Ismerje meg, hogyan