Figyelem!
Ez a rész nem a dokumentumhoz tartozik, hanem tartalmának, szerepének, a RUP-on belül elfoglalt helyének leírására szolgál.
A Software követelmény specifikáció (Software Requirements Specification, SRS) dokumentum a RUP legelső (kiindulási, inception) fázisában elkezdett, és a következő (kidolgozásai, elaboration ) fázisban részletesebben kidolgozott dokumentum, amely a tervezéshez szükséges részletességgel foglalja össze a rendszerrel szemben támasztott funkcionális és nem funkcionális a követelményeket.
Fő célja a rendszer által biztosítandó szolgáltatások leírása.
A dokumentum olvasóközönsége: a megrendelő képviselői (hogy megbizonyosodjanak, valóban a megfelelő rendszer fog készülni), és a fejlesztő gárda minden szereplője. Mivel a részletes követelmény specifikáció újabb és újabb szakterületi fogalmakat tár fel, a dokumentum írása során a szógyűjtemény (Glossary) is általában folyamatosan bővül.
A dokumentumban leírtak fogják szolgáltatni azokat az információkat, amelyek alapján azonosíthatók
a rendszer objektumai és az azokat leíró osztályok, a közöttük levő kapcsolatok (a rendszer statikus modellje),
a rendszer viselkedése (a rendszer dinamikus modellje),
a rendszer működése során végrehajtandó számítások (a rendszer funkcionális modellje)
Az alábbiakban ennek a dokumentumnak egy kitöltési útmutatóval ellátott, a RUP ajánlásához képest némileg leegyszerűsített mintáját adjuk meg.
Egy konkrét fejlesztés esetén a magyarázatok kitörlésével, illetve a felesleges címek elhagyásával kaphatjuk meg a dokumentum vázát.
A vonatkozó szakirodalom könnyebb megértése és az angol nyelven dolgozó csoportok kedvéért minden cím után eltérő betűtípussal megadom a cím szokásos angol megfelelőjét is.
Történet
|
Dátum |
Verzió |
Leírás |
Szerző |
|---|---|---|---|
|
2005. 03. 08. |
1.0 |
Kezdeti verzió |
Ficsor Lajos |
|
2005. 03. 23. |
1.1 |
Kisebb javítások, a címek angol megfelelői |
Ficsor Lajos |
|
2006. 03.09. |
1.2 |
html formátum |
Ficsor Lajos |
A vonal után kezdődik a dokumentum minta
Történet
|
Dátum |
Verzió |
Leírás |
Szerző |
|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
A lenti tartalomjegyzék az aktuális tartalomnak megfelelően módosítandó!
Tartalomjegyzék
9. On-line dokumentáció és Help rendszer
10. Felhasznált kész komponensek
11.1. Felhasználói interfészek
11.2. Hardware interfészek
11.3. Software interfészek
11.3. Kommunikációs interfészek
12.1. Kötelezően alkalmazandó szabványok
12.2. Választás alapján alkalmazott szabványok
Introduction
Overview
Ennek a fejezetnek a célja a készülő alkalmazás szempontjából fontos általános körülmények összefoglalása. Ez nem konkrét követelményeket tartalmaz, hanem azok hátterét világítja meg, segítve a következő fejezetekben részletezett információk megértését. Ide tartozhatnak olyan információk, mint például:
a termék környezete,
legfontosabb funkciók,
a felhasználók jellemzői,
korlátozások,
feltételezések és függőségek,
a követelmények csoportosításának szempontjai.
Specific Requirements
Ebben az alpontban kell összefoglalni a a rendszerrel szemben támasztott funkcionális követelményeket.
A leírás történhet természetes nyelven és/vagy user case diagramok használatával.
Természetes nyelvi leírás esetén az egyes alpontok egymás után egy-egy követelmény specifikációját tartalmazzák. Szükség esetén a követelmények a rendszer fő szolgáltatásai, funkcionális moduljai mentén csoportosíthatók.
Use case diagramok használata esetén a use case modell alapvetően use case csomagok sorozata. A csoportosítás ilyenkor a csomagok segítségével történik, és egy-egy alpont egy csomagra vonatkozik. Egy alpont ilyenkor az alábbiakat tartalmazza:
Egy use case diagram.
A diagramon szereplő valamennyi aktor felsorolása, és pontos definíciója (ha a dokumentumban már korábban előfordult, akkor a pontos hivatkozás a definícióra).
A diagramon szereplő valamennyi use case felsorolása, és pontos definíciója. Egyszerű esetben ez lehet természetes nyelvi leírás, bonyolultabb esetben egyéb UML eszköz. (pl. szekvencia diagram vagy együttműködési diagram.) Minden use case leírás az alábbiakat kell hogy tartalmazza, egy – egy alpontban:
A use case neve.
Rövid leírás.
Prekondíciók (előfeltételek): azon feltételek felsorolása, amelyeknek teljesülnie kell, mielőtt a use case által jelzett tevékenység elkezdődik.
Post kondíciók : annak leírása, hogy milyen állapot következik be a use case végén.
Szokásos működés (Main Flow): azok az események / folyamatok, amelyek a use case „szokásos” körülmények közötti működését jellemzik. (Például egy pénzfelvételnél a kártya beolvasása, pin kód beadása stb.)
Alternatív esetek (Alternate Flows): azok az események / folyamatok, amelyek előfordulhatnak, és ezért kezelendők, de nem a „szokásos” működéshez tartoznak. (Például a pénzfelvételnél a kuncsaft helytelen pin kódot ad meg.)
Kivételes esetek (Exception Flows): azok a lehetséges forgatókönyvek, amelyek váratlanul bekövetkezhetnek. (Például a pénzfelvételnél egy olvashatatlan kártya, vagy áramszünet stb.)
A diagramon szereplő use case-ek kapcsolatainak leírása.
És akkor itt jönnek a 3.1, 3.2 stb. alpontok az egyes követelmények és/vagy use case diagramok leírásával.
Usability
Itt kell összefoglalni azokat a nem funkcionális követelményeket (mindegyiket egy-egy alpontban), amelyek a rendszer használhatóságát befolyásolják. Ilyenek lehetnek például:
Mennyi betanulási időre lesz majd szüksége a rendszer hatékony használatához egy kezdő és egy gyakorlott felhasználónak.
Mennyi idő alatt tud egy adott tevékenységet végrehajtani egy átlagos felhasználó a jelenlegi módszerrel, meglévő más rendszerek, illetve a fejlesztendő rendszer segítségével.
Melyek azok a rendszer tulajdonságok, amelyek segíthetik a kezdő felhasználót a gyors betanulásban?
Milyen egyéb lehetőségek állnak rendelkezésre (vagy kérhetők a fejlesztőktől ingyen vagy külön díjazás fejében) a betanulás elősegítésére (tréningek, dokumentációk, könyvek, demonstrációs prototípus stb.)
Mennyire hasonló vagy eltérő a felhasználói felület, annak használati módja a felhasználók által már korábban is használt alkalmazásokkal összehasonlítva?
Ha a leendő alkalmazással párhuzamosan más alkalmazásokat is fognak használni a felhasználók a munkájuk során, összhangban vannak-e ezek programok a használat (elsősorban a felhasználói felület szempontjából)?
Reliability
A rendszerrel szemben támasztott megbízhatósági követelmények. (Minden követelmény egy alpontban.) Ilyenek lehetnek például:
rendelkezésre állás (pl. %-ban): teljes használhatóság, karbantartási idő, korlátozott használhatóság,
MTBF: (Mean Time Between Failures): hibák között eltelt átlagos idő,
MTTR: (Man Time To Repair): egy hiba utáni javítás átlagos ideje,
A rendszer eredményeinek pontossága, felbontása (ha értelmezhető).
Performance
Itt kell leírni a rendszertől elvárt teljesítmény mutatókat, mindegyiket egy külön alpontban. Ilyenek lehetnek például:
válaszidők (legalább a leggyakrabban használt funkciók esetén),
áteresztőképesség (például tranzakció/mp),
kapacitás (például a kezelt adatbázis max. mérete, feldolgozandó tranzakciók száma, egyidejűleg kiszolgálandó felhasználók száma stb.),
a korlátozott használhatóság idején elvárható / teljesítendő mutatók,
erőforrás igények (processzor sebesség, memória igény, diszk kapacitás, sávszélesség stb.).
Supportability
A rendszer üzembe helyezése után szükséges karbantartási feladatok megkönnyítésére szolgáló követelmények, egy-egy alpontban. Ezek a követelmények vonatkozhatnak mind a termékre, mind a fejlesztés folyamatára. Ilyenek lehetnek például:
a használandó kódolási szabványok, elnevezési konvenciók,
csak a karbantartóknak, illetve üzemeltetőknek szükséges funkciók,
a működés során keletkező naplók (a későbbi hibakeresés vagy finomhangolás elősegítésére),
a karbantartók munkáját segítő segédalkalmazások (például a naplók kiértékelésére).
Design Constrainst
Itt kell felsorolni egy-egy alpontban minden olyan korlátozást, amely a tervezési, esetleg az implementációs munkát befolyásolja. Ilyenek lehetnek például:
a kívánatos architektúrára vonatkozó előírások (például milyen részekből [„tier”] kell felépíteni az alkalmazást),
milyen programozási nyelv(ek)et kell használni,
milyen fejlesztőeszközt kell használni,
milyen újra felhasználható elemek építhetők be az alkalmazásba (komponens- és/vagy osztálykönyvtárak, kész kódok stb.),
milyen fejlesztési módszertant, hogyan kell használni.
Online User Documentation and Help System Requirements
Kellenek-e ilyenek, ha igen, a vonatkozó információk.
Third-party Components
Egy-egy alpontban kell felsorolni az alkalmazásba építendő vásárolt vagy szabad felhasználású elemeket. Vásárlás esetén a részletezni kell a beszerzés körülményeit, a költségeket, a betartandó liceszelési és egyéb szabályokat. Szabad felhasználású elem esetén is fontos a forrás pontos megjelölése, a felhasználás szabályai, az alkalmazásra ebből adódó esetleges következmények, kötelezettségek.
Interfaces
Ebben a fejezetben kell specifikálni a rendszer valamennyi külső kapcsolatát, az ezt biztosító interfészeket.
User Interfaces
Ebben az alpontban kell leírni a felhasználói interfészre vonatkozó követelményeket. Ilyenek lehetnek például:
használandó szabvány vagy kvázi-szabvány, stílus,
a különböző felhasználói csoportok (munkakör, gyakorlottság stb. szerint) elvárásai,
a leglényegesebb user interface elemek tervei.
Hardware Interfaces
Ha vannak a rendszerben speciális kezelendő hardware elemek.
Software Interfaces
Ha a rendszernek más rendszerekkel az üzembe helyezés után, vagy belátható időn belül majd a kapcsolatot kell tartania más rendszerekkel, itt kell megadni a kapcsolat kiépítéséhez szükséges részletességű információkat.
Communications Interfaces
Ha a rendszernek valamilyen kommunikációs csatorna vagy csatornák segítségével kell kapcsolatot tartania a felhasználókkal vagy más rendszerekkel. (Például internetes, mobiltelefonos kliens stb.)
Applicable Standards
A fejlesztés során vagy az alkalmazás készítése és üzemeltetése, használata során betartandó előírások (technikai vagy szakterületi szabványok, törvények stb.) Célszerű lehet az alábbi csoportosítás.
Valamilyen szintű előírás miatt. (Például törvényi előírás stb.)
Optional Standars
A fejlesztők vagy a felhasználók által valamilyen okból önként vállalt előírások.
Appendix
Főleg hosszabb dokumentumok esetén ide kerülhet minden olyan információ, ami a dokumentum áttekinthetőségét segíti (pl. tárgymutató, irodalomjegyzék, egyéb források megjelölése), illetve a fejlesztés egyéb, kapcsolódó dokumentumaira való hivatkozás.