O przetargach napisano tak wiele krytycznych tekstów, więc po co ten? Nie będę się tu pastwił nad nimi. Zastanawia mnie co innego, i tu mała krytyka... W prasie pojawiły się…
Dzisiaj żadnych technicznych mądrości ;) [...] Tak więc wymagania na oprogramowanie to minimalna liczba (specyfikacja) warunków, których spełnienie potwierdza przydatność tego oprogramowania do określonego celu. Oznacza to, że przede wszystkim należy określić cele! Jeżeli nie znajdziemy takiego oprogramowania na rynku, wtedy należy wykonać studium wykonywalności projektu dedykowanego oprogramowania. Jak określać cele? Przypadek użycia, wymagana usługa systemu, to nic innego jak właśnie cel. Celem jest możliwość wystawiania dokumentów XXX, celem jest generowanie raportów kontrolnych wykonania planu produkcji i obciążenia maszyn. Jeżeli system jest duży, celem (jednostka opisu wymagań) jest wsparcie procesu obsługi zamówień (i opis tego procesu jako załącznik). Ale nie jest dobrym celem zakupu oprogramowania: "rozwijana lista kontrahentów na ekranie tworzenia nowej faktury" czy "możliwość wprowadzenia nazwy ulicy, kodu i nazwy miasta w kartotece klienta". Jak mam nadzieję widać, nie bardzo ma sens porywanie się na zakup "wielkiego pakietu zintegrowanego", bo jak tu opracować w rozsądnym czasie i koszcie, specyfikację wymagań? Opracować listę celów wszystkich komórek organizacyjnych???? Jak zagwarantować jej niezmienność (zakres projektu), jeżeli taki projekt trwa np. pięć lat? Życzę powodzenia...
Bardzo często spotykam, pewnie nie ja jeden, specyfikacje wymagań zawierające zapisy "oczekiwań użytkowników". Bardzo często słyszę także, że to przyszły użytkownik oprogramowania powinien być źródłem wymagań. nic bardziej błędnego.. [...] Więc np. wymaganie "system powinien pozwalać na budowanie dowolnych rabatów sprzedaży do stałych klientów" (także cytat z pewnej specyfikacji systemu CRM) jest pustym stwierdzeniem. Po pierwsze jak te rabaty są naliczane, po drugie czy aby na pewno mechanizm pozwala na "dowolne rabaty"... Jak to opisać? Tu powinny się pojawić np. tablice decyzyjne a nie lakoniczne "dowolne rabaty". Na zakończenie uwaga: jeżeli planujemy kupić gotowe oprogramowanie, to ono już (gdzieś tam) istnieje, i specyfikowanie szczegółów opisujących dokładnie elementy pracy z interfejsem użytkownika i enigmatyczne opisy tego jak "system liczy", jest bezwartościowe. Raczej wywoła listę tak zwanych kastomizacji (zwanych gdzieniegdzie zabójcami projektów :)). Tak jednak właśnie wyglądają najczęściej specyfikacje pisane rękami przyszłych użytkowników: opiszą oni to z czym się stykają i co znają ale w ogóle nie opiszą wnętrza, którego najczęściej po protu nie rozumieją (i nie muszą bo to nie ich rola), wtedy specyfikacje systemów CRM pisane rękami przyszłych użytkowników - np. sprzedawców - zawierają właśnie bezwartościowe zapisy w rodzaju: "system powinien pozwalać na budowanie dowolnych rabatów sprzedaży do stałych klientów" a nie zawierają opisu jak te rabaty wyliczać. Odpowiadając na tytułowe pytanie: wymagania (funkcjonalne) realizują się w modelu dziedziny systemu, którego nie zawiera większość znanych specyfikacji wymagań... a warunkiem poprawnego wyboru oprogramowania są oczekiwania co do efektów przetwarzania.