Specifikáció: hogyan?

Móna Dániel · 2021.08.24.

Mire jó a specifikáció? Hogyan írjunk specifikációt?

A nagy házi feladat 2-es mérföldkövénél, a specifikációban kell leírni azt, hogy pontosan hogyan fog kinézni a program, amit házi feladatként szeretnél elkészíteni. Ez többek közt azért is fontos, mert értékelési szempont, hogy a program teljesíti-e a specifikációját. Ugyanakkor ha most programozol először vagy még nem igazán tervezted előre a programjaidat, nem biztos, elsőre tiszta, hogy mi ez és miért kell egyáltalán.

1. Mire jó a specifikáció?

Specifikációt azért kell készíteni, mert az iparban ha programot írsz, leggyakrabban nem magadnak írod, hanem valaki másnak. Ez legfőképpen azt jelenti, hogy ilyenkor kezdetben nem a te tiszted tisztában lenni azzal, hogy mik az elvárások a programmal szemben: hogyan várja a bemenetét, mit kell csinálnia vele, milyen kimenetet adjon, milyen hibákat kell lekezelnie, és így tovább. Ezeket az elvárásokat ideális esetben a megrendelőnek kellene tudnia, azaz annak, aki a program elkészítését várja tőled. Ebben kell a megrendelőnek és a programozónak egyetértenie. A specifikáció pedig pontosan ez: a programmal szembeni elvárások összessége.

Persze sokszor van az, hogy távol állunk az ideális esettől. A megrendelő nagyon gyakran nem is tud programozni, így segítség nélkül nem is igazán tudja pontosan összeszedni az igényeit. Ezért aztán különösen fontos, hogy a megrendelő és a programozó közösen megbeszélve írásba foglalják a programmal szembeni elvárásokat. Ahol pedig a félreértésnek akár a lehetősége megjelenik, válasszanak a lehetséges alternatívák közül, a választást pontosításként rögzítve a specifikációban.

Előkerül emellett a specifikáció akkor is, amikor két programozó ugyanazon a programon dolgozik. Ilyenkor a benne leírt elvárások biztosítják azt, hogy ők ketten (vagy többen) ne álljanak hozzá véletlenül lényegesen máshogy a program elkészítéséhez, ne legyen ilyen természetű zűrzavar.

Összegezve tehát a jól megírt specifikáció garantálja, hogy a programozók biztosan egyazon feladat megoldásán dolgozzanak és ez a megoldás az elvárt megoldás legyen. Vagyis az, amit a megrendelő szeretne.

2. Hogyan írjunk specifikációt?

A specifikáció jóságát a következők határozzák meg:

  • Elég részletesen ír olyan dolgokról, amikről írnia kell.
  • Nem hagy ki olyat, amiről írnia kell.
  • Nem ír olyanról, amiről nem kellene írnia.

Részletesség

A programozás nagy házihoz specifikációt írni abból a szempontból talán furcsa, hogy most lényegében egyszerre vagy a megrendelő és a megvalósító programozó is. Viszont amikor a specifikációt készíted, mégis érdemes ezt a két szerepet gondolatban különválasztanod: helyezd magad képzeletben a megrendelő szerepébe és gondold végig azt, hogy egy másik programozó el tudná-e pontosan a te elvárásaidnak megfelelően készíteni a programodat, ha csak a specifikációt kapná róla kézhez. Erre utal a legfontosabb tételmondat a pontosított specifikációról szóló követelményekben:

A pontosított specifikáció részletességére jellemző, hogy ha két külön programozó elkészíti a programot ugyanabból a specifikációból, de egymástól függetlenül dolgozva, akkor kívülről nézve nagyon hasonló programoknak kell keletkezniük.

Ami a probléma, hogy nem mindig gondolunk bele, hogy egy másik programozó hozzánk képest mennyire máshogy gondolkodhat. Biztosan (a program kifelé látszó viselkedését tekintve) ugyanúgy valósítaná meg azt, hogy „a program menüvezérelt és a következő menüpontok vannak: [...]”? Vagy hogy „a program az adatokat fájlba tudja menteni”?

Egy konkrét példa. Egy program rövid feladatleírása többek közt tartalmazza azt, hogy a program mentse fájlba az adatokat, amikkel dolgozik. Bár akár a megrendelőnek, akár a programozónak felületesen belegondolva nyilvánvalónak tűnhet, mit jelent ez – valójában itt számos dolgot félre lehet érteni. Pontosan milyen adatokat is mentünk? Hogyan nézzen ki a mentésfájl, mondjuk A␣B␣C formátumú sorok, ahol A, B és C a különböző adatfajták és egy szóköz, vagy inkább valahogy máshogy? Automatikusan mentsen a program kilépéskor, vagy erre mindig a felhasználónak kelljen utasítania? Az ilyen és ehhez hasonló dolgokat mind-mind meg kell határozni, rögzíteni kell a specifikációban.

Amikor a specifikációt fogalmazod, folyamatosan arra gondolj, hogyan lehet azt, amit éppen írsz, félreérteni. Ha találsz egy ilyen esetet, akkor rögtön tudni fogod, hol kell pontosítani, hogy a képzeletbeli másik programozó is pontosan azt kódolja majd a specifikáció elolvasása után, amit te szeretnél.

Tartalom: ami kell

A specifikáció tartalma tehát a feladatkiírás a fentieknek megfelelő módon elvégzett részletekbe menő pontosítása. Általánosságban a specifikációból látsszon, hogy felhasználói szemszögből hogyan lehet használni a programot. Kiindulhatsz a minta NHF specifikációjának felépítéséből is. Legyen itt néhány pont gondolatébresztőnek:

  • Menüvezérelt program:
    • Hogyan jelenik meg a menü, hogyan lehet menüpontot választani?
    • Hogyan jelennek meg az egyes funkciók?
    • Hogyan lehet visszakerülni a főmenübe, mikor van vagy nincs rá mód?
    • Hogyan, milyen sorrendben kér be a program adatokat?
    • Milyen formában várja a program az egyes adatokat? (pl. ÉÉÉÉ/HH/NN?)
    • Vállalkozik-e a program hibás bemenet (pl. rossz formátumú adat) lekezelésére? Ha igen, milyen hibákat tud kezelni, hogyan jelzi a hibát? (hibaüzenet, stb.)
    • Milyen az elvárt kimenete az egyes funkcióknak?
  • Játékprogram:
    • Játékszabályok: hogyan zajlik a játék, hogy lehet nyerni, mikor veszítünk? Akkor is, ha egyébként széles körben ismert játékról van szó. Mi van, ha a képzeletbeli programozók eddig valamiért sosem látott kígyós játékot? Ha nem ismeri a kártyajáték szabályait? Ha nem úgy ismeri a szabályait?
    • Milyen nézetek vannak? Pl. főmenü, dicsőséglista, játéknézet... még valami?
    • Mikor, hogyan lehet az egyes nézetekből másikba eljutni? („új játék gombbal indítható...”)
    • Hogyan jelenik meg a pálya? Főleg, ha nem grafikus a program, ekkor milyen szöveges karakter mit reprezentál, stb.
    • Menthető a játékállás? Ha igen, mikor, hogyan?
    • Milyen bemenettel irányítható a játék?
    • Hogyan reagál a játék az egyes bemenetekre?
  • Mi az írt/olvasott fájlok belsejének formátuma? (lásd a fentebbi példát)
  • Vállalkozik-e a program hibás formátumú fájl lekezelésére? Ha igen, mit csinál ilyen helyzetben?

Még egyszer: ezek csak gondolatébresztők, nem feltétlenül csak ezeket, de innen sem feltétlenül mindet kell a specifikációban kifejteni. Feladatfüggően simán lehet olyan dolog, ami fontos és leírandó, de ebben a listában nem szerepel és fordítva, azaz szerepel a listában, de az adott feladathoz nem releváns. A lista nem is jelenti azt, hogy kérdezz–felelek formában kellene a specifikációt megfogalmazni.

Tartalom: ami nem kell

A specifikáció írása közben vedd figyelembe a következőket:

A specifikáció nem megvalósítási terv. Ha ilyeneket vagy ehhez hasonlókat írnál bele, hogy „integerben tárolja”, „dinamikus tömb”, vagy „láncolt listát épít”, akkor töröld is ki rögtön, mert nem feladata a specifikációnak ezeket előírni. Sőt! A megvalósítási részletek a megrendelőnek érdektelenek, őneki csak az a fontos, hogy a program azt csinálja, amit ő akar, számára a hogyan nem érdekes.

Illetve, az előzővel kapcsolatosan: a specifikáció nem szándéknyilatkozat. (Néha kaptunk ilyet is.) Ha ilyeneket írnál, hogy „szeretnék”, „tervezek”, „úgy akarom, hogy”, vagy bármikor ehhez hasonlóan átcsúszik a szöveg egyes szám első személybe, azt töröld is ki, mert a specifikáció nem arról szól, hogy te elmagyarázod a laborvezetőnek, hogy mit akarsz lekódolni. (Személyes konzultáláskor, vagy levélben viszont megteheted! Örülünk a kérdéseknek.) A specifikáció a programról szól, azt mondja meg, hogy a programot milyenre kell megvalósítani.

3. Összefoglalva (TL;DR)

A specifikáció arról szól, hogy elmondja egy másik (képzeletbeli) programozónak, aki elég sok mindent félreért, hogy a programot milyenre kell megvalósítani. A specifikáció akkor jó, ha ebben sikerrel jár.