Előzetes követelményelemzés

Az előzetes követelményelemzést gyakorlatilag az előrejelezhetőség iránti jogos igényünk miatt alkalmazzuk. Végsősoron logikus feltételezés, hogy ha tudom azt, hogy mire van szükségem, akkor el tudom képzelni, hogy azt hogyan valósítom majd meg. Ezt az elképzelést aztán konkrét tervekké tudom formálni, amikből előrejelezhetem a projekt várható pénzügyi és egyéb kereteit. Annak érdekében, hogy az előrejelzésem a lehető legpontosabb legyen, annyi információt próbálok begyűjteni a megvalósítandó rendszerről, amennyit csak lehet. Ez a gondolat motiválja az új szoftver kifejlesztése és bevezetése előtt álló szervezeteket arra, hogy a projektet megelőzően hónapokat, akár éveket töltsenek a követelmények részletes meghatározásával. Nem egy olyan projekttel találkoztam, ahol az előkészítési fázis elvitte a projektre rendelkezésre álló idő felét, vagy akár kétharmadát is. A probléma ott van, hogy ezzel alig jutottak közelebb az összehasonlítható ajánlatokhoz, vagy a pontosabb becsléshez. Az előrejelzhetőségről szóló előző bejegyzésemben ennek a hátteréről írtam.

Ha az előzetes követelményelemzés hasznát vizsgáljuk, az eredmény sajnos még ennél is kiábrándítóbb. Nemcsak, hogy nem jutunk sokkal közelebb a projekt kereteinek megbecsléséhez, de még abban sem lehetünk biztosak, hogy az elvárásainkat kellő alapossággal megismertük. A Standish Group által közölt "Chaos report" ebben a kérdésben is elgondolkodtató eredményre jutott. Azt vizsgálták, hogy az előzetes követelményelemzés alapján fejlesztett rendszerek funkcióit milyen arányban használják a valóságban. (Részletesebben Ambler W. Scott ír a témáról) A jelentés konklúziója elég nyilvánvaló:

• Az elkészült funkciók közel 2/3-át soha, vagy nagyon ritkán használják
• A gyakran, vagy állandóan használt funkciók az összes szolgáltatás 20%-át teszik ki

Ez az eredmény pénzügyi szemléletre fordítva azt jelenti, hogy az előzetes követelményspecifikáció alapján fejlesztett rendszerekre fordított költségek legalább fele teljesen kidobott pénz, azaz tiszta veszteség. Megítélésem szerint a veszteség még ennél is nagyobb, ugyanis a követelményspecifikációban rögzített, de nem megvalósított funkciók különböző tervekben történő részletes kidolgozásának költségei itt nem látszódnak.

Ez a pazarlás egyébként kódolva van a bemerevített (prediktív) szoftverfejlesztési módszertanok alkalmazása során. Mivel a szállító kötve van a szerződésben vállalt költség és időkeretekhez, ezért erős változáskezelési eljárásokat alkalmaz annak érdekében, hogy a követelményspecifikációban megfogalmazott funkciókon kívül semmi új ne kerülhessen a projekt szkópjába. Ezt a megrendelő nyilvánvalóan csak úgy tudja kezelni, ha a követelményspecifikációban minden elképzelhető igényt rögzít. Olyanokat is, amikre egyébként nincsi is szüksége. Ki tudja, még jól jöhet... A változáskezelési eljárások alkalmazásának van még egy kellemetlen hatása: a megrendelőt távol tartja attól, hogy a később felismert (esetleg fontos) igényeit beépíthesse a rendszerbe.