Fejlesztési specifikáció: mit írj le ajánlatkérés előtt?

Így készíts használható fejlesztési specifikációt: üzleti cél, folyamatok, jogosultságok, elfogadási feltételek és összehasonlítható ajánlatok.

Buda Sándor · 2026-09-08

„Kellene egy rendszer, amiben minden egy helyen van.” Ez érthető üzleti igény, de fejlesztési ajánlatot nehéz rá adni. Az egyik kivitelező egyszerű nyilvántartásra gondol, a másik jogosultságkezelésre, automatizálásra és több külső rendszer összekötésére. A beérkező árak ezért nem feltétlenül ugyanarról a feladatról szólnak.

A fejlesztési specifikáció ezt a bizonytalanságot csökkenti: leírja, kinek, milyen munkát, milyen szabályok szerint kell elvégeznie a készülő szoftverben. Nem kell programozónak lenned hozzá. Az ajánlatkérés előtt elsősorban a saját működésedet, a problémákat és az elvárt eredményt kell világossá tenned. Az alábbi útmutató ehhez ad kitölthető gondolatmenetet, példát és átadási ellenőrzőlistát.

Mi a fejlesztési specifikáció, és meddig kell elmenned?

A specifikáció közösen értelmezhető követelményleírás. Nem pusztán funkciólista, nem látványterv, és nem a teljes program előzetes leírása. Akkor hasznos, ha a megrendelő és a fejlesztő ugyanazt érti a feladat alatt, és később ellenőrizhető, hogy az elkészült működés megfelel-e a megbeszélteknek.

Érdemes megkülönböztetni az ajánlatkérő briefet és a részletes specifikációt. Az előbbi az üzleti célt, a fő folyamatokat, a korlátokat és a nyitott kérdéseket foglalja össze. Az utóbbi már a működési szabályokat, kivételeket, adatokat és elfogadási feltételeket is részletezi. Az ajánlatkéréshez nem szükséges minden képernyőt véglegesíteni, de a nagy bizonytalanságokat láthatóvá kell tenni.

Az üzleti folyamatokra szabott szoftverfejlesztés előkészítésében ezért a cél és a munkafolyamat tisztázása megelőzi a technológiai döntést. A „milyen rendszer készüljön?” kérdésre jobb válasz az elvégzendő munka leírása, mint egy keretrendszer neve.

1. A problémát írd le, ne csak a kívánt funkciót

Kezdd azzal, mi történik ma. Ki indítja a folyamatot, milyen adatokkal dolgozik, hol várakozik, és hol kell ugyanazt az információt újra beírni? Ha csak annyit írsz, hogy „automatikus riport kell”, nem derül ki, milyen döntést kell támogatnia, ki használja, és miért nem megfelelő a jelenlegi kimutatás.

Egy használható problémafelvetés például így hangzik: az ügyintéző három külön táblázatból állítja össze a nyitott munkák listáját, ezért a vezető nem látja, melyik feladat vár ügyfél-visszajelzésre. Az elvárt eredmény egy olyan közös nyilvántartás, amelyből az aktuális állapot külön egyeztetés nélkül megállapítható. Ez már segít a fejlesztőnek megérteni a feladatot.

A siker jelét is nevezd meg. Lehet kevesebb dupla rögzítés, rövidebb ügyintézés vagy pontosabb státuszkövetés. Először mérd fel a jelenlegi állapotot; a kívánt javulást ne bizonyíték nélküli ígéretként, hanem később ellenőrizendő célként rögzítsd. Ha még nincs adat, azt is írd bele.

2. Nevezd meg a felhasználókat és a jogosultságokat

A „felhasználó” túl tág fogalom. Más feladatot végez az ügyintéző, a csoportvezető, a külső partner és a rendszergazda. Szerepkörönként írd le, ki mit láthat, létrehozhat, módosíthat, jóváhagyhat és exportálhat. Külön kérdés, hogy csak a saját ügyeihez, a csoportjához vagy minden adathoz hozzáfér-e.

Nem szükséges elsőre bonyolult jogosultsági mátrix. Egy rövid szerepleírás is elég kiindulópont: az ügyintéző rögzíthet munkát; a vezető új felelőst jelölhet ki; a partner csak a saját megrendelése állapotát követheti. A határhelyzeteket viszont ne hagyd ki: mi történik kilépő kollégánál, helyettesítésnél vagy áthelyezett ügyfélnél?

Ügyféladatoknál a rendszerhatárok is fontosak. Ha már működik ügyfélkezelő és értékesítési rendszer, tisztázd, mely adatokat tartjátok ott nyilván, és melyek kerülnek az új alkalmazásba. Két párhuzamos ügyféllista létrehozása önmagában nem oldja meg az információhiányt.

3. Egy teljes munkafolyamatot mutass be

A menüpontok felsorolása helyett vezess végig egy konkrét ügyet a kezdetétől a lezárásig. Mi váltja ki a folyamatot? Milyen adat nélkül nem lehet továbblépni? Ki kap értesítést? Mikor változik az állapot? Mit tekintetek befejezett munkának? A fejlesztő ebből érti meg az egyes funkciók kapcsolatát.

Egy munkalapkezelőnél például: az ügyintéző létrehozza a munkalapot, kiválasztja az ügyfelet és a helyszínt, a vezető felelőst rendel hozzá, a munkatárs elvégzi és dokumentálja a feladatot, majd az ügyintéző lezárja. Már ebből látszik, hogy az ügyfél, a helyszín, a felelős és a státusz nem független adatmezők.

A kivételes esetek is a feladat részei

Mi történik, ha az ügyfél lemondja a munkát, hiányzik egy szükséges adat, vagy tévesen zárnak le egy ügyet? Ki nyithatja újra, és megmarad-e az előzmény? Nem kell minden elképzelhető hibát felsorolni, de a gyakran előforduló kivételeket és a nagy következménnyel járó eseteket érdemes külön leírni. Ezek az ajánlatot és a tesztelést is befolyásolják.

4. Írd le, mikor tekinthető késznek egy funkció

A „legyen kereső” nem elegendő elfogadási feltétel. Mely adatokra kereshetünk? Teljes név kell, vagy névrészlet is működik? Mit lát a felhasználó, ha nincs találat? Megjelenhet-e olyan rekord, amelyhez nincs hozzáférése? A követelmény akkor ellenőrizhető, ha egy konkrét próbával el lehet dönteni, teljesült-e.

Használhatsz egyszerű mondatszerkezetet: adott egy helyzet, a felhasználó elvégez egy műveletet, a rendszer pedig a megadott eredményt adja. Például: ha az ügyintéző megnyitja a nyitott munkák listáját és felelősre szűr, csak az adott felelőshöz rendelt, még nem lezárt munkalapokat látja. Az üres eredményhez érthető tájékoztatás tartozik.

Minden fontos funkcióhoz legyen legalább egy normál és egy hibás vagy hiányos bemenetet vizsgáló példa. Ezek nem helyettesítik a fejlesztői teszteket, de jó alapot adnak az üzleti átvételhez. A vállalati oldalon is jelöld ki, ki jogosult megállapítani, hogy a működés megfelel.

5. Gyűjtsd össze az adatokat és az integrációkat

Írd össze a kezelt adatköröket: ügyfél, kapcsolattartó, termék, munkalap, dokumentum, státusz, megjegyzés. Mindegyiknél legyen világos, honnan származik az adat, ki módosíthatja, és mely mezők kötelezők. Ha régi rendszerből költöztettek, ne csak az adatmennyiséget említsd: a minőség, a hiányzó mezők és a duplikációk is számítanak.

Az ajánlatkéréshez készíts személyes és bizalmas adatoktól megtisztított mintát. Egy valódi szerkezetet követő, fiktív sorokkal kitöltött táblázat sok kérdést tisztázhat. Éles ügyféllistát, jelszót vagy hozzáférési kulcsot ne küldj körbe az ajánlatkérő dokumentumban. A szükséges hozzáférések átadását később, megfelelő csatornán rendezzétek.

Külső kapcsolatnál nevezd meg a rendszert és az adatátadás célját. Egyszeri import kell, időszakos szinkron vagy azonnali művelet? Ki biztosítja a dokumentációt és a tesztkörnyezetet? Mi történjen elérhetetlenség esetén? Ha ezek még nem ismertek, ne kész tényként szerepeljen az integráció: legyen külön felmérendő tétel.

6. A képernyővázlat mellé működési szabály is kell

A képernyővázlat segít megmutatni, mi kerüljön egy oldalra, de nem magyarázza meg, mi történik a gomb megnyomása után. Egy jóváhagyási gomb mögött lehet egyszerű státuszváltás, értesítés vagy külső rendszerbe történő adatküldés is. Ezeket a viselkedéseket a rajz mellett szövegesen rögzítsd.

Az egyedi webes felület tervezésénél azt is tisztázni kell, milyen eszközön és helyzetben használják a rendszert. Egy irodai adminisztrátornak nagy táblázat segíthet, egy helyszínen dolgozó kollégának néhány könnyen elérhető művelet. A reszponzív megjelenés igényét ezért konkrét munkafeladattal együtt érdemes megfogalmazni.

Nem kell látványtervet készítened, ha ez nem a szakterületed. Egy egyszerű dobozos rajz és néhány megjegyzés megfelelő kiindulópont lehet. A referenciaoldal azt mutassa meg, mely elrendezési megoldás tetszik, ne teljes rendszerleírásként szolgáljon: a látható felületből nem derül ki a háttér működése.

7. A minőségi elvárások legyenek értelmezhetők

A „gyors, biztonságos és könnyen kezelhető” elvárás fontos, de önmagában nem ellenőrizhető. Adj hozzá használati környezetet: várhatóan hányan dolgoznak egyszerre, mennyi adatot kezelnek, mekkora fájlokat töltenek fel, és mely műveletnél okozna fennakadást a várakozás. A pontos műszaki célokat ezek alapján lehet egyeztetni.

Ugyanígy kerüljenek elő a mentések, a visszaállítás, az események naplózása, a támogatott böngészők és a hibajelzés módja. Ne vállalj találomra rendelkezésre állási vagy sebességi számokat. Inkább mondd el, mely folyamat nem állhat le munkaidőben, mekkora kiesés kezelhető kézzel, és kit kell értesíteni probléma esetén.

A hozzáférhetőségi és adatkezelési igényeket se hagyd az átadás végére. A dokumentum nevezze meg az érintett felhasználói köröket és a kezelt adatkategóriákat; az alkalmazandó követelményeket az illetékes szakértőkkel tisztázzátok. Az üzleti specifikáció feladata itt az igények és felelősök láthatóvá tétele.

8. Válaszd szét a biztos és a nyitott tételeket

Egy ajánlatkérésben nem baj, ha vannak kérdések. Az a gond, ha egy feltételezés végleges követelménynek látszik. Használj három egyszerű jelölést: eldöntött, egyeztetendő, későbbi lehetőség. Minden nyitott ponthoz írd oda, ki tud választ adni, és mikorra szükséges a döntés.

A prioritás mellett a kizárásokat is rögzítsd. Ha az első ütem nem tartalmaz online fizetést, mobilalkalmazást vagy automatikus számlázást, ez legyen egyértelmű. A „később jó lenne” funkciók hasznos háttérinformációk, de ne keveredjenek az átadás feltételeivel. Így nem kell minden ajánlattevőnek saját maga kitalálnia a projekt határait.

Ha egy alapvető integráció vagy üzleti szabály tisztázatlan, kérhetsz külön felmérési szakaszt. Ennek is legyen eredménye: például jóváhagyott folyamatleírás, adatlista, fő képernyővázlatok és kockázati jegyzék. A felmérés nem önmagáért készül, hanem a következő döntést és a megalapozott becslést támogatja.

Rövid specifikációs példa: munkalap jóváhagyása

Az alábbi minta szemléltető példa, nem megvalósított ügyfélprojekt. A célja megmutatni, mennyivel több információt ad egy strukturált követelmény, mint az, hogy „kell egy jóváhagyás gomb”. A saját működésed szerint módosíthatod a szabályokat.

• Cél: csak ellenőrzött munkalap kerülhessen lezárt állapotba.
• Szereplő: a kijelölt csoportvezető a saját csoportjának munkalapjait hagyhatja jóvá.
• Előfeltétel: a munkalap elvégzett állapotú, és minden kötelező mező ki van töltve.
• Művelet: a vezető jóváhagyja vagy indoklással visszaküldi a munkalapot.
• Eredmény: jóváhagyáskor lezárt állapot, visszaküldéskor javítandó állapot és értesítés keletkezik.
• Ellenőrzés: másik csoport munkalapja nem hagyható jóvá; hiányos munkalapnál érthető hibaüzenet jelenik meg.
• Nyitott kérdés: ki helyettesíti a vezetőt szabadság alatt?

Ebből a leírásból már képernyő, jogosultsági szabály és teszteset is tervezhető. A nyitott kérdés pedig nem vész el egy későbbi e-mailben. Ha több hasonló funkciót írsz le, adj nekik rövid azonosítót, hogy az ajánlatban és a hibajegyekben is egyértelműen lehessen rájuk hivatkozni.

Hogyan hasonlítsd össze a kapott ajánlatokat?

Minden ajánlattevő ugyanazt a dokumentumverziót kapja meg. Kérd, hogy külön tüntesse fel a vállalt terjedelmet, a feltételezéseket, a kizárásokat és a tőletek szükséges közreműködést. Ha valaki más működést javasol, annak előnye és hatása is legyen leírva, ne csak a végösszeg változzon.

Az összehasonlításnál nézd meg, szerepel-e a tesztelés, az adatköltöztetés, a betanítás, a dokumentáció és az indulás támogatása. Külön kezeld az egyszeri megvalósítást és az üzemeltetést. A kedvezőbb ajánlat valóban lehet hatékonyabb megoldás, de lehet szűkebb feladat is; ezt a specifikációhoz rendelt vállalásokból lehet megkülönböztetni.

A belső erőforrásokat is tervezd meg. Ki válaszol a kérdésekre, ellenőrzi a mintákat, készíti elő az adatokat és vesz részt a próbákban? Ha a szükséges döntésekre nincs felelős, a fejlesztő akkor sem tud folyamatosan haladni, ha a megvalósítási feladat egyébként világos.

Ajánlatkérés előtti ellenőrzőlista

• Egy mondatban megfogalmazható az üzleti probléma és a várt eredmény.
• Ismertek a felhasználói szerepek és a fontos hozzáférési határok.
• Legalább egy teljes folyamat és annak lényeges kivételei le vannak írva.
• A fő funkciókhoz ellenőrizhető elfogadási feltételek tartoznak.
• Az adatkörök, integrációk és a költöztetés szükségessége látható.
• Elkülönül az első ütem, a későbbi ötlet és a kizárt feladat.
• A nyitott kérdéseknek és az üzleti átvételnek van felelőse.
• Minden ajánlattevő ugyanabból a dátumozott változatból dolgozik.

A specifikáció a fejlesztés során változhat, de a változások ne írják felül észrevétlenül az eredeti megállapodást. Rögzítsétek, mi módosult, miért, milyen hatással van az időre és a terjedelemre, és ki hagyta jóvá. Ez egyszerű döntési naplóval is megoldható; nem a dokumentáció mennyisége, hanem a követhetősége számít.

A jó specifikáció közös megértést teremt

Nem az a cél, hogy ajánlatkérés előtt egyedül megtervezd a teljes szoftvert. Olyan kiindulópontot készíts, amelyből a fejlesztő megérti a működésedet, és meg tudja mutatni, hol hiányzik még döntés. A világos cél, a konkrét folyamat és az ellenőrizhető eredmény többet ér egy hosszú, de bizonytalan kívánságlistánál.

Ha már látod a megoldandó üzleti problémát, de a követelmények még szétszórt jegyzetekben vannak, a következő lépés ezek közös rendszerezése lehet. A BudaWeb egyedi szoftverfejlesztési folyamata felméréssel és specifikációval indul: így a megvalósítás előtt tisztázható, milyen rendszert érdemes felépíteni.