Az elsõ követelmény paradox a következõ:
-
A követelmények stabilnak kell leniük, hogy megbízható eredmény kapjunk.
-
Azonban a követlények mindig változnak.
Bármit is teszel azért, hogy a követelmények teljesek és változatlanok legyenek, meg fognak változni. Nem csak azért, mert az ügyfél meggondolja magát, ahogy látja a kibontakozó eredményt. A fejlesztõk is egyre nagyobb rálátást nyernek és új ötleteik merülnek fel, hogy miknek is kellene lenniük a tényleges követelményeknek. Tehát a követelmények változása egy ismert kockázat. Jobb, mintha figyelmen kívül hagynánk ezt a követelmény paradoxont, használj olyan fejlesztési folyamatot, ami megbirkózik a vele: Evolutionary delivery.
A résztvevõk (stakeholders) válaszai alapján az Evo gyors és gyakori visszajelzést ad ahhoz, hogy ellenõrizni és igazítani lehessen a követelményeken ahhoz, amihez az ügyfélnek ténylegesen a leginkább szüksége van. A ciklusok között kis rések vannak, ahol a résztvevõk kommuikációja, információátadása megengedett, sõt szükséges, hogy a taskok prioritását újra meghatározhassuk.
Ez a második követelmény paradoxon miatt van:
-
Nem akarjuk, hogy a követelmények változzanak
-
De, mivel a követelmények változása egy ismert kockázati tényezõ, próbáljuk kiprovokálni a változást amilyen hamar csak lehet.
Úgy oldjuk meg a követelmény paradoxonokat, hogy stabil követelményeket határozunk meg a fejlesztési ciklus folyamán, miközben explicite felülvizsgáljuk a követelményeket a ciklusok között.
