> A może nie potrafisz określić konkretnie co ma być zrobione ?
> A może nie ustaliłeś wymagań funkcjonalnych dla przyszłej aplikacji ?
> A może nie umiesz opisać słownie ale w sposób jednoznaczny każdego z
> przypadków użycia ?
> A może nie wiesz jak ma wyglądać szata graficzna twojego systemu ?
> A może nie określiłeś jeszcze wielu istotnych rzeczy ?
>

[CUT]

Tu akurat sie z toba nie zgodze. Inwestor nie musi wiedziec co konkretnie ma
byc zrobione. Nie musi znac pojeec "Przypadki uzycia" "wymagania
funkcjonalne". Inwestor wie co chce, ale on nie jest inzynierem informacji.
Zadaniem projektatna jest ustalenie tych rzeczy razem z inwestorem. To na
projektancie lezy odpowiedzialnosc za to, aby wymagania funkcjonalne byly
kompletne. Po to siedzi z nim przy piwie i omawia wszystkie aspekty
projektu. Po to przygotowywuje sobie wczesniej pytania, jakie ma zadac
inwestorowi, zeby wyciagnac z niego te wszystkie dane. Mowi sie, ze 50%
projektow upada przez 'bad requirements' - i niestety to jest blad ludzi od
projektowania (zbyt luzne podejscie do tematu i zbytnie zaufanie w wiedze i
swiadomosc inwestora). Projektant czy koder pelni role podrzedna w stosunku
do inwestora.
Przyklad: system informatyczny w ZUS : kto ponosi wine za zle przeprowadzony
proces ustalania wymagan systemu ?
Istnieje grubo ponad 300 oficjalnych standardow dotyczacych procesu
projektowania, tworzenia, wdrazania, konserwacji i rozwoju aplikacji. Zaden
nie przewiduje, aby inwestor przeprowadzal proces ustalania wymagan, czy
tworzenia use case.

To co napisalem, nie zmienia mojego zdania na temat Pana - tworcy watku.
Dalej uwazam, ze temu Panu myla sie priorytety (poprzez wypowiedzi typu -
lolo itp). Pisze to po to, aby uswiadomic wielu tworcom IT, ze sypanie sie
projektu nie zawsze wynika z ulomnosci i glupkowatosci sponsora calej
imprezy.

Pozdrawiam
Tomek