Tworząc post z wielką listą zbierania wymagań biznesowych spotkałem się z bardzo pozytywnym odbiorem. Dlatego powstaje kolejny post z serii. Tym razem obszarem listy jest walidacja wymagań biznesowych. Przedstawiam listę technik walidacji wymagań które znam. Standardowo jak widzisz że jakiejś brakuje to zapraszam do kontaktu 🙂

Walidacja wymagań biznesowych – spis technik

Checklist based reading

Checklista to zestaw pytań na które można odpowiedzieć tak/nie. Walidacja wymagań biznesowych w tej technice polega na tym że osoba czytająca wymagania ma przed sobą przygotowaną checklistę z pytaniami na które musi odpowiedzieć. Jest to technika wpół ustrukturyzowana ponieważ nie mówi czytającemu jak ma czytać daną dokumentację wymagań. Aby ułatwić można dodać krótką instrukcję.

Chceklisty powinny być utrzymywane na bieżąco, checklisty powinny być zwięzłe i najlepiej znajdywać się na jednej stronie ale też powinny nie być zbyt ogólnikowe

Prototypowanie

Prototypowanie to przedstawienie interesariuszom prototypu w celu identyfikacji wszystkich brakujących lub źle sprecyzowanych wymagań. Prototypy mogą być:
-Rysowane na kartce
-Tworzone w aplikacjach do prototypowania
-Tworzone w aplikacjach do rysowania grafiki

Bardzo ważnym punktem w przypadku prototypowania jest zaznaczenie interesariuszom że widok może wyglądać inaczej niż jest przedstawione na obrazku.

Przejście przez(walk-through)

Jest to lżejsza wersja inspekcji. Polega na takim samym przeglądzie wymagań ale nie ma takich sztywnych ról przeglądania wymagań(przeważnie przeglądający, autor, ten co notuje i moderator). Celem jest wyłapywanie dziur w wymaganiach oraz wyrównanie wiedzy o wymaganiach pomiędzy uczestnikami.

Podczas sesji walk-through uczestnicy dyskutują o prezentowanych wymaganiach których kolejność przygotował moderator. Często rolę moderatora(oraz notującego) pełni analityk. Dobrym pomysłem jest włączenie nagrywania co sprawia że nie trzeba notować.

Tworzenie manuali użytkownika

Stworzenie podstawowych instrukcji użytkownika dla nowo-tworzonego systemu potrafi znaleźć odpowiednie luki w wymaganiach dzięki temu że podchodzimy do każdego kroku w procesie w sposób bardzo szczegółowy. Tłumaczymy każdy krok osobie która nie zna systemu i kontekstu co pozwala na wyłapywanie kolejnych luk i nową perspektywę wymagań.

Tworzenie unhappy path

Happy path to domyślny scenariusz wykorzystania developowanego oprogramowania bez żadnych wyjątków po drodze. Przykładowo w przypadku wybierania pieniędzy z bankomatu użytkownik prawidłowo wpisał pin, miał pieniądze na koncie, karta bankomatowa miała prawidłowy termin ważności oraz w bankomacie była gotówka.

Więc my dla walidacji wymagań biznesowych staramy się wymyślić wszystkie możliwe sytuacje które mogą pójść nie tak aby stworzony przez nas system był „idiotoodporny”. Dzięki temu walidujemy wymagania ponieważ większość z nas wpada w heurystykę że zawsze wszystko idzie zgodnie z planem.

Walidacja wymagań biznesowych oparta na modelu

To chyba najbardziej znana metoda. Walidacja wymagań biznesowych pojawia się na samym początku pracy analityka z wymaganiami. W większości przypadków tworzymy model w celu poukładania wymagań w głowie no a przy okazji model ma taką specyfikę że jest szczery. Jest na tyle szczery że wyłapie każdą niespójność która się pojawia w naszym procesie i naszych wymaganiach.

Jednak sam model nie wystarczy w walidacji i trzeba go wspierać innymi technikami. Model ma to do siebie że upraszcza rzeczywistość a wymagania mają to do siebie że nie są(i nie mogą) być ogólnikowe i uproszczone.

Obserwacje jako weryfikacja istniejących wymagań

Każdy widząc ten punkt puknął się w czoło. Przecież obserwacje służą temu żeby zbierać wymagania. Walidacja wymagań biznesowych i obserwacje się do siebie nie dodają! A jednak! Często jest tak że interesariusz opowiada o swoim procesie, o tym jak wygląda jego praca i co robi.

Czasem doświadczenie podpowiada że to że dany interesariusz opowiada o czymś co nie jest zbytnio spójne z rzeczywistością. Wtedy bardzo dobrym sposobem na weryfikację wymagań jest wykonanie obserwacji użytkowników końcowych w tzw. „polu” lub „na linii frontu” aby potwierdzić to że dana konfiguracja wymagań jest odpowiednia.

Kwestionariusze

Kolejna technika która jest podawana jako technika zbierania wymagań. Często jest tak że grupa użytkowników końcowych jest liczona w tysiącach. Wtedy interesariuszami przeważnie są managerowie średniego i wysokiego szczebla a nie ludzie odpowiedzialni za realną pracę z systemem.

Technika polega na tym że wysyłamy do dużej grupy użytkowników końcowych wymagania z ankietą do wypełnienia w celu dania uwag do dokumentu. Pozwala to na weryfikację tego czy wyobrażenie interesariuszy o pracy użytkowników końcowych pokrywa się z rzeczywistością.

Komentarze

Najstarsza i najczęściej używana technika z racji totalnej wygody dla czytających(bo mają wolną rękę) i analityka(bo nie musi niczego przygotowywać). Wysyłamy do czytających dokument wymagań a oni czytają dokument i dodają do niego komentarze z uwagami.

Są do tego różne nazwy. Ja nazwałem to komentarze z racji komentarzy od czytających dokument.

Tworzenie przypadków testowych

Technika polegająca na tym że weryfikujemy wymagania na podstawie tego że tworzymy przypadki testowe. Przypadki testowe mają taką naturę że tworzący od razu zastanawia się na unhappy path. Co prowadzi do weryfikacji czy wymagania pokrywają wszystkie scenariusze(nawet te głupie). A w 90% przypadków tego nie robią.

Czytanie oparte na perspektywie

Technika polegająca na tym że czytamy dokument z perspektywy różnych ról. Często ta technika jest łączona z innymi technikami np. z walk-through gdzie wymagania są czytane z różnych perspektyw. np:

• użytkownika
• architekta oprogramowania
• testera
• programisty
• klienta

Inspekcja

Jest to uporządkowany przegląd dokumentacji w której są z góry określone fazy pracy z wymaganiami oraz określone role danych uczestników w tym procesie.

Technika ta składa się z

• Planowania(przed spotkaniem ustalamy cel inspekcji, oczekiwany efekt końcowy, oraz role uczestników które mają zostać odegrane)
• Przegląd(Na początku inspekcji autor pokazuje i tłumaczy wymagania każdemu uczestnikowi w celu wyrównania poziomu wiedzy)
• Szukanie luk(w tej fazie każdy uczestnik szuka błędów w wymaganiach i je dokumentuje. Można to robić wspólnie lub indywidualnie)
• Zebranie błędów(w tej fazie zderzamy ze sobą wszystkie błędy jakie się pojawiły i je dokumentujemy)

Role podczas inspekcji

• Organizator(osoba która organizuje i nadzoruję proces)
• Moderator(osoba która moderuje przebieg ćwiczenia)
• Autor(osoba która jest autorem wymagań i je tłumaczy w fazie przeglądu)
• Czytający(osoba która przedstawia wymagania by inspektor nie musiał się na tym skupiać. Często łączone z moderatorem)
• Inspektor(osoby odpowiedzialne za znajdywanie i komunikowanie błędów)
• Notujący

Symulacja

Walidacja polegająca na tym że bierzemy maksymalną liczbę różnych sytuacji które mogą się przydarzyć w codziennym funkcjonowaniu biznesu i przepuszczamy przez to nasze wymagania w kontekście tego jak w danej sytuacji się zachowa projektowany system.

Tak. Dobrze ci się kojarzy z znanym(i ostatnio krytykowanym) gherkinem. Zarzuty że to rozdmuchuje dokumentacje są słuszne. Ale my tutaj mówimy o sprawdzaniu wymagań a nie klepaniu nowych wymagań(a w tym to się sprawdzi bardzo dobrze)

Minimum Viable Product

Niech pierwszy rzuci kamieniem ten który nie robił MVP w korpo które potem okazało się i tak za dużym zakresem i koniec końców nie zostało wdrożone. Sama koncepcja MVP wywodzi się z metodyk Lean i jej definicja w moim(czyli kiepskim) tłumaczeniu to wersja oprogramowania z minimum funkcjonalności która pozwala na zebranie od klientów maksimum informacji przy najmniejszym koszcie developmentu.

Defect based reading

Jest to technika która należy do rodziny technik czytania opartych na scenariuszu. Niektórzy dodają ją do rodzaju technik czytania opartego na perspektywie jednak moim zdaniem jak checklisty wydzielamy to metody „scenariuszowe” tak samo powinny zostać wydzielone.

Technika ta polega na tym że wyróżniamy różnego rodzaju błędy w wymaganiach i każdy czytający skupia się na znalezieniu danego rodzaju błąd. Czyli np. czytasz dokumentację w kontekście znalezienia słów które mają dwuznaczne znaczenie lub czytasz dokumentację w kontekście niekompletności itd.

Rola każdego czytającego jest z góry określona i każdy czytający odpowiada za błędy ze swojej dziedziny.

Czytanie oparte na śledzeniu

Technika polegająca na przeszukaniu wszystkich dostępnych wymagań w danej konfiguracji w celu wyłapania wszystkich luk w śledzeniu pomiędzy wymaganiami. Wyłapujemy wszystkie niespójności w nazewnictwie, wymagania które się duplikują, wymagania które są ze sobą powiązane a nie linkują do siebie itd.

Czytanie kombinowane

Technika polegająca na tym że jest połączone czytanie w kilku oparciach(np. defektach, śledzeniu i perspektywie). Zapewniamy chcecklistę czytającemu tłumaczącą jak czytać, z jakiej perspektywy oraz jakiego błędu szukać. Technika ma polegać na tym że mamy wykorzystać mocne strony każdej techniki omijając słabości innej.