Követelmények helyett elvárások!

A szoftverfejlesztési projektek egyik kulcsfontosságú területe a követelmények helyes meghatározása. Azt is tudjuk, hogy az egyedi fejlesztési projektek bukását leggyakrabban a hibás követelményelemzésre vezetik vissza. De vajon miért olyan nehéz feladat a követelmények helyes feltárása, dokumentálása és az ezeket kielégítő rendszer lefejelsztése? Szerintem a válasz az, hogy a követelmények nem a természetes gondolkodás kellékei. A követelmények részben a környezeti kényszerek, részben a megrendelők adott pillanatban, adott információk alapján kialakított elvárásainak rögzített leképezése. A gond az, hogy ezek mind változnak. A környezeti feltételek változásával nem nagyon tudunk mit kezdeni, azok a projekttől teljesen függetlenek, néha előre láthatók, néha nem. Ilyenek tipikusan az adott projekt környezetét befolyásoló jogszabályok, és az üzleti környezet változása.

A követelmények merevek, az elvárások élők

Sokkal izgalmasabb a megrendelői elvárásokat elemezni. Azok ugyanis a projekt hatókörén belül helyezkednek el. A megrendelő végsősoron dönthet arról, hogy ragaszkodik az adott elvárásához, vagy sem. Itt szándékosan az elvárás szót használom. A követelmények ugyanis az elvárásokból származnak. A követelmény kifejezés azt sugalja, hogy valami statikus dologról van szó, amit csak rögzíteni kell és onnantól ismerjük. Éppen ez a probléma vele! A megrendelőt ugyanis nem érdeklik a követelmények. A megrendelőnek elvárásai vannak, amiknek megfelelő rendszert akar látni. Az üzleti megrendelő szemében a követelmény csak egy szükséges rossz, amibe az előzetes követelményspecifikáción alapuló fejlesztési kultúra belekényszeríti a tervezhetőség látszatának fenntartása érdekében. A valós igények az elvárásokban bújnak meg. Az elvárások pedig a megismerés során folyamatosan változnak. Az elkészítendő rendszerrel kapcsolatos ismeretek bővülése pedig folyamatos. Az elemzési, tervezési szakaszban nemcsak a fejlesztők, de az üzleti megrendelők is folyamatosan formálják a fejlesztendő rendszerről kialakított képüket. A vízesés modellben alkalmazott követelménykezelési módszerek problémája tehát nem abban rejlik, hogy hibásan alkalmazzuk őket, hanem abban, hogy eredendően téves elképzelésből indulnak ki. Az elvárások ugyanis természetüknél fogva többnyire nem statikusak, tehát nem is rögzíthetők. A megoldás tehát nem az, hogy egyre komplexebb követelményelemzési és dokumentációs technikákat dolgozunk ki hanem az, hogy megtanuljuk követni a az elvárások változását. A hatékony elváráskezeléshez vezető legjobb út az, ha pontosan megértjük a fejlesztendő rendszer célját és üzleti környezetét. Ekkor az energiánkat nem a követelmények rögzítésére, hanem a problémák megoldására fókuszálhatjuk. A követelmények komplex rögzítésére és dokumentálására fordított energia nagy részét hasznosabb lenne olyan tevékenységekre fordítani, melyek során a fejlesztő csapat megértheti a megrendelői elvárásokat és az azok megött meghúzódó okokat. A jó rendszer elkészítéséhez a fejlesztő teamnek mindenképpen meg kell ismernie a megrendelő üzleti környezetét, ha rögzítjük a követelményeket, ha nem.

Az információmegosztás módszerei

Ambler W. Scott készített egy felmérést arról, hogy az egyes kommunikációs formák milyen mértékben járulnak hozzá ahhoz, hogy a fejlesztők megértsék a rendszerrel szemben támasztott elvárásokat. Az egyes kommunikációs formák hatékonyságát -5 és +5 közötti skálán lehetett osztályozni. A negatív értékek nagyjából azt jelentik, hogy az adott kommunikációs módszer inkább hátráltatja a megértést, mintsem javítja azt. A felmérésben az egyes információátadási módszerek hatékonyságát a csapaton belüli, valamint a csapat és a megrendelő közötti kommunikációban is vizsgálták. Érdemes megfigyelni, hogy az egyetlen negatív eredményt a részletes specifikáció kapta.

Egy figyelemreméltó példa

Szintén érdekes tanulsággal szolgál a Toyotánál alkalmazott követelménykezelési módszer. A Toyotánál alapszabály, hogy minden elvárásrendszernek el kell férnie egy A3-as oldalon. A Toyota Prius fejlesztésébe a Toyota hatalmas összegeket fektetett be úgy, hogy az autóval szembeni elvárásokat mindössze 5 pontban foglalták össze (relatív tágas belső tér; magas üléspozíció; jó aerodinamika; 20km/liter fogyasztás; kicsi, horizontálisan elhelyezett motor fokozatmentes automata váltóval). A követelmények gyűjtése helyett a prototípusok előállítására és tesztelésére helyezték a hangsúlyt. A gyakorlati megvalósítással szemben semmilyen megkötést nem alkalmaztak. A hybrid hajtás például a projekt során kialakított megvalósítási döntés volt, sehol nem szerepelt az eredeti elvárásokban. Érdemes elgondolkodni azon, hogy a világ legnagyobb és legnyereségesebb autógyára miért ezeket a módszereket alkalamzza? Ha jobban belegondolunk, egy új típus fejlesztése egy ugyanolyan kockázatos befektetés, mint egy új szoftver kifejlesztése. Ha a Toyota felismerte, hogy fölösleges előzetesen "agyonspecifikálni" a terméket, akkor miért ne tehetnénk mi is ugyanezt?