O opisowych metodach zbierania wymagań napisano wiele, eksperymentuję czasami z “tekstami” i nabieram pewnego przekonania: jako opis wymagań, czyli “jak chce to robić” (np. przypadków użycia) raczej nie, jako opis celu działania, czyli “co chce osiągnąć/po co mi to” jak najbardziej. Tak więc opis z ręki zamawiającego jako “wsad do analizy” jak najbardziej, ale user story jako “wymagania”, raczej na pewno nie (czytaj User Story – kłopoty)…

User Story jaki “jak” z reguły niestety stwarza problemy i słusznie zauważono, że:

User Story w postaci: “Obsługa błędów i ich logowanie powinno się odbywać poprzez wspólny mechanizm” jest kiepskim pomysłem. Co prawda widzimy dość jasno, że to wymaganie jest wartościowe, ale czy użytkownik/klient będzie potrafił ocenić jego wartość? Dodatkowo taki zapis zawiera w sobie sugestię na temat implementacji sposobu obsługi błędów – czy z punktu widzenia klienta ma to znaczenie? Pamiętajmy też, że jako analitycy (lub jako product owner w Scrumie) nie chcemy sugerować rozwiązania programistom, którzy często lepiej od nas znają się na technologii, której będą używać. My powinniśmy napisać, co chce osiągnąć użytkownik i pozwolić programistom wybrać najlepszy sposób implementacji rozwiązania. (Wartościowe User Stories ? O wymaganiach).

Moim zdaniem tak zwane user story powinno być napisane: po pierwsze językiem zamawiającego, po drugie wyłącznie o tym co zamawiający rozumie. Dlaczego? Bo tylko wtedy autor tego tekstu – tego “wymagania”, zamawiający – jest w stanie sam ocenić jego “sens i prawdziwość” a także przydatność.  Gdzie tu rola analityka? Analiza to sprowadzenie tych opisów do określonej struktury wraz z określoną logiką – formalizacja. Rolą analityka jest na tym etapie usuwanie niejednoznaczności. Kolejny etap to doprowadzenie dokumentu wymagań do spójności. Jeżeli uznamy, że wymagania to testy, to rolą analityka jest wyspecyfikowanie wymagań w postaci testów (przypominam, że wymagania to warunki jakie musi spełnić coś, by było przydatne do określonego celu), wszędzie tam, że wymagana jest “jakaś logika biznesowa”, należy ją także udokumentować.

Jak słusznie powyżej zauważył autor cytatu, należy “pozwolić programistom wybrać najlepszy sposób implementacji rozwiązania”, ale tu ważna uwaga: implementacja to nie rozwiązywanie problemów biznesowych. Innymi słowy, programista nie może dostać wymagania w postaci “sprzedaż towaru to pobranie go z magazynu”, bo po pierwsze nie wie co to jest “towar” po drugie  nie zawsze jest to pobranie z magazynu. Należy mieć świadomość, że “towar” z perspektywy programisty to “strukturalny opis” i nie on ten opis powinien robić. Kto? Analityk.

Tak wiec powyższe, cytowane user story raczej powinno mieć postać: “celem administratora oprogramowania jest śledzenie zachowania systemu i wychwytywanie zaistniałych błędów w jego zachowaniu, informacje o błędach powinien otrzymywać natychmiast” oraz dodatkowo (robota analityka) powinien istnieć słownik biznesowy z definicją pojęcia “błąd oprogramowania” oraz “natychmiast”. Rolą programisty jest przełożenie tego na język użytego narzędzia (języka programowania) oraz zapewnienie by powstałe oprogramowanie było zgodne z oczekiwanymi wymaganiami jakościowymi (wymaganie poza-funkcjonalne: natychmiast).

Tak więc programista implementuje logikę biznesową, tę musi jednoznacznie udokumentować  analityk, oraz zapewnia uzgodnioną jakość (wymagania pozafunkcjonalne). Ma więc dużo pracy… ale nie powinien podejmować prób wpływu na implementowaną logikę biznesową.

Czyli np. “jako sprzedawca, dostaję od klientów zamówienia, na podstawie których muszę wystawiać faktury VAT”, do tego analityk doda, np. po analizie otrzymanej partii dokumentów, strukturę zamówienia i faktury VAT oraz “algorytm” wyliczenia podatków.

Jeżeli programista zaczyna “lepiej wiedzieć” od zamawiającego, forsując np. prostszą implementację, to znaczy, że przekroczył swoje kompetencje, sam sobie – jako developerowi – robi krzywdę psując to oprogramowanie bo klient i tak prędzej czy później na tych uproszczeniach “polegnie”. Rolą analityka są także ewentualne negocjacje z zamawiającym, uproszczeń lub  rozwinięć tego opisu. Czy analityk może być “pracownikiem” dostawcy? Jak sądzicie?