Razem czy osobno?

Najlepiej jest, aby analiza problemu i synteza wymagań dla systemu były osobnym zadaniem. Truizmem byłoby powiedzieć, że taka analiza powinna zostać wykonana przed rozpoczęciem prac nad systemem. Natomiast nie jest już tak oczywiste, czy analiza wymagań i sformułowanie specyfikacji systemu powinny być elementem osobnego kontraktu i czy ich wykonawcy powinno przysługiwać osobne wynagrodzenie.

W większości umów podpisywanych w Polsce dominuje podejście, które można by nazwać asekuranckim. Zamawiający chce po prostu mieć "system" jako całość, zaś rozbicie prac na elementy pozostawia wykonawcy. Niechętnie też płaci za specyfikację, czyli coś, czego nie można jeszcze w żaden sposób wykorzystać, co najczęściej ma postać grubych ksiąg zawierających opisy słowne i diagramy, rzadziej także software'owe prototypy. Specyfikacja i synteza wymagań nie są przez większość odbiorców systemów informatycznych uważane za osobny produkt i jako takie nie stanowią przedmiotu procedur przetargowych i pozycji na fakturach.

Podejście takie opóźnia konieczne płatności i stawia zamawiającego w teoretycznie korzystniejszej sytuacji, bo w przypadku niewywiązania się dostawcy z którejś z faz projektu nie ponosi on straty finansowej (kwoty, którą już wpłacił).

Jednak komfort ten jest pozorny, a ryzyko duże. Może bowiem się zdarzyć, że dostawca nie rozumie biznesu, który ma informatyzować. Nie ma nic gorszego niż kosztowny, zaawansowany system, który jednak robi co innego niż chciał zamawiający. Dobrze zrobiona analiza pozwala rozpoznać taki problem bardzo wcześnie i uniknąć kosztownych błędów.

Przede wszystkim wyodrębnienie specyfikacji wymagań jako osobnego produktu uniezależnia odbiorcę od dostawcy. Kto powiedział, że ta sama firma, która opracowała specyfikację, musi wykonać projekt? Na przykład w inżynierii budowlanej i automatyzacji procesów przemysłowych regułą jest, że jedna firma tworzy założenia, inna projekt, a jeszcze inna jest generalnym wykonawcą. Dlaczego tak samo nie miałoby być w inżynierii systemów informatycznych?

Rzeczywistość projektowa

Doświadczenia polskie są jednak już wystarczająco bogate, aby dostrzec poważne wady takiego podejścia. Najbardziej spektakularnym przykładem na niebezpieczeństwa związane z nieoddzieleniem analizy wymagań od procesu tworzenia i wdrażania systemu oraz związanym z tym totalnym uzależnieniem od jednego dostawcy jest projekt Kompleksowego Systemu Informatycznego ZUS. Pomimo ogromnej kwoty kontraktu i zaangażowania doświadczonego wykonawcy, projektu nie zakończono, a kolejne terminy jego uruchomienia były wielokrotnie odkładane.

Byłoby nadużyciem stwierdzić, że przyczyny porażki tego projektu leżą wyłącznie w źle przeprowadzonej fazie analitycznej. Są także inne, głębsze przyczyny, ale o tym wielokrotnie szczegółowo pisano. Jednakże jasne jest, że spośród czynników leżących poza technologią, w sferze organizacji, prawidłowo przeprowadzona analiza ma znaczenie kluczowe.