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.

Jarosław Żeliński

Jarosław Żeliński: autor, badacz i praktyk analizy systemowej organizacji: Od roku 1991 roku, nieprzerwanie, realizuje projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzi samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzi wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie.) Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów. Prawa autorskie: Zgodnie z art. 25 ust. 1 pkt. 1) lit. b) ustawy o prawie autorskim i prawach pokrewnych zastrzegam, że dalsze rozpowszechnianie artykułów publikowanych w niniejszym serwisie jest zabronione bez indywidualnej zgody autora (patrz Polityki Strony).

Ten post ma 3 komentarzy

  1. “szczegóły są potrzebne tylko tam, gdzie są potrzebne szczegóły”

    “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.”

    Pytanie czy można “trafić” w dobre szczegóły nie zanurzając analizy w kontekście. W kontekście rozumianym jako odpowiedź na pytanie “dla kogo powstają artefakty analityczne, kto będzie z nich korzystał?” Zwykle artefakty te są inputem dla developerów, więc jeżeli cały proces wytwarzania angażowałby stronę develoeprską, to wówczas mogliby oni się wypowiedzieć, które zagadnienia są znane, a które wymagają uszczegółowienia.

    Tak właśnie wygląda to w Domain Driven Design, gdzie na wspólnej (w miejscu i czasie) sesji modelowania pojawiają się Eksperci Domenowi i Modelarze. Czyli mamy tu nieco inne podejście do odpowiedzialności. Zależnie od natury projektu Analityk może być po jednej albo drugiej stronie, ale modelarze to strona wytwórcza.

    1. Jarek Żeliński

      Sławek poruszyłeś ważną rzecz: kontrakt analityka z developerem. Ale co zrobić gdy nie znam developera bo np. będzie przetarg? Moim zdaniem jedynym sensownym rozwiązaniem jest to, co się robi na etapie poprawnej analizy przypadków użycia. Nie mogę w projekcie poprzestać na nazwaniu aktora, muszę go scharakteryzować. Permanentnie niestety obserwuję w dokumentacjach listę aktorów i żadnej informacji o tym co każdy aktor potrafi. Prosty przykład: jeżeli nie wiem jaką wiedzą dysponuje Fakturzysta nie mam pojęcia jak zaprojektować mu scenariusz. Księgowa wystawi fakturę na pustej kartce papieru bez problemu, ale zatrudniony na umowę zlecenia student historii nie koniecznie. Ten sam use case będzie (powinien) zupełnie inaczej wyglądał dla każdego z tych aktorów.

      Podobnie, bez wiedzy kim jest “mój klient”, nie mam żadnych podstaw by określić zakres i produkt projektu analitycznego o wdzięcznej nazwie “analiza i specyfikacja wymagań”. Dlatego każda moja umowa zawiera zapis: oczekiwania wobec developera (opis jego minimalnych kompetencji) bez czego moim zdaniem, żadna analiza nie ma sensu bo albo jest zbyt ogólna albo zbyt szczegółowa albo w ogóle niezrozumiała (pół biedy jeżeli to jedyne jej wady :)). To temat rzeka.

      I tu mamy zalety DDD: narzucenie tej konwencji opisuje i analityka i developera (mają znać i stosować). Narzucenie wzorca MVC wskazuje jasne granice kontraktu analityk-developer-designer: analityk tworzy Model, designer “ekrany” (View) a developer implementuje całość.

      W DDD, moim zdaniem, “piękne” jest to, że od razu wiadomo gdzie wpisać i czemu przypisać “metody” czyli szczegóły. Praktykuję ostatnio takie podejście:
      – tworzę model dziedziny zgodny z DDD (czasami prościej: ICONIX)
      – do klas entity/agregat linkuję wzory dokumentów (ekranów, ale raczej listę pól niż szczegółowe mock-up’y – to robota designera)
      – jeżeli nazwa metody nie określa w sposób oczywisty tego co ma się wydarzyć (np. Wylicz podatek VAT, dodaj wartości itp..;)) to dokumentuję metodę tablicą decyzyjną, diagramem algorytmu, inne zależnie od potrzeby.

      Nie jest to na pewno gotowa recepta na sukces ale pozwala ogarnąć zjawisko. Jak jednak słusznie zauważyłeś: dialog analityk – developer jest potrzebny (nie da się i nie ma sensu próba udokumentowania wszystkiego), dlatego moim zdaniem autor projektu (analityk) powinien być cały czas dostępny dla developera. To czy analityk/modelarz jest po stronie wytwórczej zależy moim zdaniem wyłącznie od kontraktu i ryzyka. Ta kompetencja jest samodzielna. Architekt budowlany może być zarówno po stronie inwestora jak i po stronie developera, to tylko kwestia umowy i ryzyk.

Dodaj komentarz

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.