Szoftver-követelményspecifikáció: minta és kitöltési útmutató kkv-knak

Mi az a követelményspecifikáció, és miért érdemes megírni?

A szoftver-követelményspecifikáció (angolul software requirements specification, SRS) egy rövid, közérthető dokumentum arról, mit kell tudnia a rendszernek, kik használják, milyen adatokkal dolgozik, és miből látszik, hogy elkészült. Nem kell hozzá informatikusnak lenned: aki a folyamatot ismeri, az tudja a legjobban megírni.

Három dolgot nyersz vele. Először: összehasonlítható ajánlatokat — ha minden fejlesztő ugyanazt a leírást kapja, az árak és a határidők ugyanarra a munkára vonatkoznak. Másodszor: fix árú ajánlatot — amit pontosan le lehet írni, arra pontosan lehet árat adni. Harmadszor: kevesebb vitát az átadáskor — az elfogadási feltételek előre rögzítik, mikor kész a munka.

Követelményspecifikáció vagy rendszerterv?

A kettőt gyakran keverik. A követelményspecifikáció a megrendelő oldaláról írja le az elvárásokat: mit és miért. A rendszerterv a fejlesztő dokumentuma: adatbázis-szerkezet, architektúra, technológia, képernyőtervek — vagyis hogyan. A jó sorrend: előbb te megírod a specifikációt, a kiválasztott fejlesztő pedig erre építi a rendszertervet, és azt veletek együtt hagyja jóvá.

A minta 12 fejezete — mit írj bele?

A mintánk fejezetrendje az ISO/IEC/IEEE 29148 követelmény-specifikációs szabvány szokásos tartalmát követi, kkv-méretre egyszerűsítve. Egy kisebb projekthez 3–6 oldal bőven elég.

1. Alapadatok: projektnév, verzió, ki dönt és ki a napi kapcsolattartó. Ha nincs egyértelmű döntéshozó, a projekt is lassú lesz.
2. Cél és háttér: milyen problémát old meg a szoftver, és mihez képest mérjük a javulást — például heti rögzítési idő vagy hibás számlák száma.
3. Felhasználók és jogosultságok: szerepkörönként, mit csinál a rendszerben, mit láthat és mit nem. Ebből lesz később a jogosultsági rendszer.
4. A mai folyamat: lépésről lépésre, ki csinálja, milyen eszközzel, és hol akad el. Ez a fejezet mutatja meg, hol hoz időt az automatizálás.
5. Funkcionális követelmények: felhasználói történetekként, elfogadási feltétellel és prioritással (lásd lent).
6. Adatok és adatköltöztetés: milyen adatokkal dolgozik a rendszer, honnan jönnek ma, mennyi van belőlük, és mit kell átköltöztetni.
7. Integrációk: számlázó, webshop, könyvelés, futárszolgálat, NAV — irány, adat, időzítés, és van-e dokumentált API vagy tesztkörnyezet.
8. Nem funkcionális követelmények: sebesség, rendelkezésre állás, biztonság, adatvédelem, mentés, eszközök, akadálymentesség.
9. Az első változat határai: mi van benne, mi jöhet később, és mi nem része a projektnek.
10. Elfogadás és átadás: tesztesetek elvárt eredménnyel, valamint az átadandók — forráskód, dokumentáció, hozzáférések, felhasználási jog, betanítás.
11. Ütemezés és keret: mérföldkövek és opcionálisan egy költségkeret-sáv, ami segít a terjedelmet reálisan kijelölni.
12. Nyitott kérdések: amire még nincs válasz. Ezeket az első egyeztetésen érdemes tisztázni.

Felhasználói történet és elfogadási feltétel: így fogalmazz

A funkciókat ne listaként („legyen benne ajánlatkészítés”), hanem felhasználói történetként írd le: „Mint [szerepkör], szeretném [funkció], hogy [üzleti haszon].” Így a fejlesztő azt is érti, miért kell a funkció — és gyakran egyszerűbb megoldást is tud javasolni rá.

Minden történethez tartozzon egy elfogadási feltétel: egy ellenőrizhető mondat, amiből eldől, hogy a funkció kész. A prioritáshoz a MoSCoW-módszer a legegyszerűbb: M (Must) nélküle nem élesíthető, S (Should) fontos, C (Could) jó, ha van, W (Won’t) most nem készül.

Ami a legtöbb specifikációból kimarad

• A nem funkcionális elvárások. Hány ember dolgozik egyszerre a rendszerben? Kell-e hétvégi támogatás? Mennyi ideig őrizzük a mentéseket? Ezek nélkül két ajánlat ugyanarra a funkciólistára is nagyon különböző rendszert takarhat.
• A kivételek. Mi történik sztornónál, részteljesítésnél, ha ugyanaz a rendelés kétszer érkezik, vagy ha a számlázó nem érhető el? A kivételek kezelése sokszor több munka, mint a fő folyamat.
• Az adatköltöztetés. A régi Excel-táblák tisztítása és átemelése önálló feladat; ha kimarad, az indulás csúszik. Erről a 7 jel, hogy a céged kinőtte az Excelt cikkünk is ír.
• Az adatvédelem. Ha személyes adatot kezel a rendszer, a GDPR 25. cikke szerint a beépített adatvédelmet már a tervezéskor figyelembe kell venni: ki fér hozzá, meddig őrizzük, mikor töröljük.
• A fiókok és jogok tulajdona. Kié lesz a domain, a tárhely, a szolgáltatói fiókok és a forráskód? Ezt a ki a forráskód tulajdonosa útmutatónk részletezi.
• A „nem része” lista. Ha nem írod le, mi nem készül el az első változatban, mindenki mást fog érteni rajta.

Mekkora legyen, és ki írja?

Egy kisvállalati CRM-hez, ügyviteli modulhoz vagy integrációhoz 3–6 oldal elég; egy nagyobb rendszernél inkább több rövid specifikáció működik, modulonként. Ne a hosszúság legyen a cél, hanem hogy egy kívülálló is ugyanúgy értse.

Írja az, aki a folyamatot a legjobban ismeri, és nézze át az, aki a pénzről dönt. Ha elakadsz, az is jó kiindulás, ha a 2., 4. és 5. fejezetet kitöltöd: ebből egy tapasztalt fejlesztő már tud kérdezni. Ha a 12 kérdést a fejlesztőnek is fel akarod tenni, a szoftverfejlesztő cég választásáról szóló cikkünk segít.

Ügyfélkezelésről szól a projekt? Az egyedi CRM-fejlesztés oldalunkon a bevezetés menetét is leírtuk. Ha meglévő rendszereket kötnél össze, a rendszerintegráció oldalon az integrációs kérdéseket gyűjtöttük össze, a kalkulátorainkkal pedig a CRM-adminisztráció vagy a kézi számlázás idejét is felmérheted.