Dzisiaj żadnych technicznych mądrości ;).

Poprzedni artykuł zaczynał się od słów:

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. (Gdzie się realizują wymagania).

Uważam, że rolą analityka nie jest ZBIERANIE WYMAGAŃ, bo wymagania powinien mieć sponsor projektu (i nie powinny to być np. listy rozwijane w menu)! Rolą analityka jest analiza! Analiza polega na analizie (:)), zrozumieniu analizowanego przedmiotu (firma, zjawisko na rynku, interakcje społeczne – testowanie projektu nowego prawa, itp.).

Tak więc produktem pracy analityka jest przede wszystkim model tego co zostało zanalizowane. Celem jest zrozumienie.

Jak to się ma do oprogramowania? Ma się bardzo, bo należy zamienić (a raczej olać) słowa przyszłego usera „chcemy tak, bo zawsze tak robiliśmy”, na obiektywny i logiczny – zrozumiały – opis tego co jest robione.

A gdzie wymagania? No wymaganie to np. „program ma wspierać wystawianie faktur VAT” ale nie pytam o to „usera”, bo po pierwsze to nie „user” o tym decyduje. Po drugie w poszukiwaniu szczegółów drążę ustawę i ewentualnie konsultuje się z biegłym rewidentem, „usera” w ogóle nie pytam o to jak liczyć podatek VAT i jak obsłużyć magazyn. Dlaczego? Z bardzo prostego powodu: mało kiedy „user” czyta przepisy, wiedzę o fakturowaniu posiada w większości przypadków z krótkich szkoleń lub przelotnych opowieści poprzednika na swoim stanowisku (wiemy jak są przekazywane obowiązki w firmach). Znam tak wiele przypadków błędnego tworzenia dokumentów przez „wieloletnich pracowników z ogromnym doświadczeniem”, że oduczyłem się traktowania ich jako głównego źródła wymagań. Koronnym przykładem była nie tak dawno dla mnie pewna Pani w pewnym urzędzie, tak zwany starszy specjalista, wieloletni pracownik sekretariatu, która zarzekała się, że można podpisywać dokumenty urzędowe przeterminowanym podpisem elektronicznym, i że wystarczy zaznaczyć, kiedy ten podpis stracił ważność. Gdybym na bazie „wiedzy” pozyskanej od tego „usera” przygotował specyfikacje wymagań, to… tragedia. Czy usprawiedliwia kogokolwiek to, że „user tak chciał”? W moich oczach absolutnie nie… W moich oczach sponsor projektu oczekuje ode mnie analizy a nie stenogramów z rozmów!

Jednym z innych przykładów tego jak „user stawia wymagania”, są (proszę wybaczyć słowo) kretyńskie systemy dopuszczające w magazynach ujemne stany magazynowe. To jest niezgodne z prawem! Da się sprzedawać legalnie, nawet towar w drodze, trzeba jednak zrozumieć zjawisko, przepisy i zaproponować legalne rozwiązanie (da się).

W kwestii szczegółowości opisu, bo ta budzi wiele emocji. Powiem przewrotnie tak: szczegóły są potrzebne tylko tam, gdzie są potrzebne szczegóły. Czyli gdzie? Tam gdzie zachodzi ryzyko, że brak tych szczegółów doprowadzi do nieprzydatności systemu ale tylko tam. Nie zapominajmy, że gromadzenie i przetwarzanie tych szczegółów to koszt. Kosztem jest także, usuwanie konsekwencji złego wyboru z powodu braku pewnych szczegółów. Nie ma na to pytanie prostej odpowiedzi, bo każdy projekt jest inny. Inne są wymagania biznesowe, inne ryzyka biznesowe, inne uwarunkowania wewnętrzne (np. już posiadane systemy).

Spotykam się często na konferencjach i szkoleniach z pytaniami o „reguły tworzenia dobrej specyfikacji wymagań”. Obawiam się, że nie nie istnieje taka. Podobnie jak nie istnieje reguła tworzenia dobrych zdjęć, co nie zmienia faktu, że spokojnie można powiedzieć jaką minimalną wiedzę i sprzęt trzeba posiadać, by robić zdjęcia na wysokim poziomie.

Tak więc

Powszechnie uważa się, że analiza wymagań na oprogramowanie to prosty, ale pracochłonny proces prowadzenia wywiadów i skrzętnego zapisywania tego, czego oczekuje przyszły użytkownik. Nic bardziej błędnego ? jest to najgorszy sposób. (A na grzyba nam Pan Analityk?).

więc co z tymi wymaganiami? Przypomnę definicję:

wymaganie ?warunek lub zespół warunków, którym ktoś lub coś musi odpowiadać?

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 dostarczenia 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 stałość (zakres projektu), jeżeli taki projekt trwa np. pięć lat? Życzę powodzenia…

P.S.

Pewne cele są realizowane konkretną metodą, wtedy trzeba dokładnie udokumentować tę metodę. Np. metodę naliczania wynagrodzeń należy dokładnie udokumentować, ale tylko pod warunkiem, że celem jest ta metoda, a nie sam fakt wypłaty „jakichś” wynagrodzeń. Jeżeli metody się zmieniają, wymaganiem nie może być konkretna metoda, a narzędzie (mechanizm dostępny w oprogramowaniu) pozwalające na definiowanie tych metod. Tu jednak należy udokumentować reguły tworzenia tych metod… bo gorąca odradzam wymaganie w postaci „system powinien pozwalać na definiowanie różnych metod naliczenia wynagrodzenia”, bo to po prostu nic nie znaczy.