Każdy z nas zaczynając swoją pracę jako analityk zastanawiał się w jak powinno wyglądać modelowe zbieranie wymagań biznesowych. Każdy z nas zastanawiał się jakich technik zbierania wymagań biznesowych użyć i jakie techniki których zbieranie wymagań biznesowych dotyczy, są skuteczne a jakich jeszcze nie znam.

Dlatego postanowiłem napisać post, gdzie przedstawię wszystkie możliwe techniki zbierania wymagań biznesowych jakie znam i/lub natknąłem się na nie w swojej pracy jako analityk biznesowy. Gorąco zachęcam do komentowania i pisania jakie techniki zbierania wymagań pominąłem bo z pewnością takie są. Chętnie zapoznam się z nową techniką i dodam ją do wpisu 🙂

Spis technik zbierania wymagań biznesowych

1. Wywiad

Technika polegająca na tym że analityk zadaje interesariuszom lub pojedynczemu interesariuszowi z góry przygotowane pytania i dokumentuje odpowiedzi. Pytania które się pojawiają podczas rozmowy można zadawać od razu. Podczas takiej rozmowy analityk może odkryć nowe wymagania których nie był wcześniej świadomy lub uszczegółowić istniejące wymagania.

Technika wywiadu może być stosowana podczas całego procesu tworzenia oprogramowania. Doświadczony analityk kontroluje wywiad i kierunek w którym zmierza cała rozmowa i upewnia się że otrzymał pełną odpowiedź na zadawane przez niego pytania. Największym minusem techniki wywiadu jest fakt że jest ona czasochłonna.

Polecam wpis o dwuznaczności wymagań w technice wywiadu

2. Benchmarking

Technika polegająca na tym że analityk wykonuje porównanie praktyk stosowanych w organizacji z praktykami które są stosowane w najlepszych organizacjach w danej dziedzinie. Najlepsze praktyki mogą być znalezione u konkurencji, w instytucjach rządowych lub stowarzyszeniach dot. danej branży.

Głównym celem benchmarkingu jest ocena efektywności oraz upewnienie się że organizacja pracuje na odpowiednich obrotach. Dodatkową sytuacją gdzie można stosować benchmarking to porównanie standardów zgodności z procedurami czy przepisami. Benchmarking w wielu przypadkach jest inicjatorem zmiany w organizacji.

3. Kwestionariusze

Technika polegająca na tym że Analityk tworzy ankietę z otwartymi lub zamkniętymi pytaniami i przekazuje ją interesariuszom w celu zebrania wymagań. Technika ta jest bardzo dobrym rozwiązaniem gdy potrzebujemy zebrania wymagań z bardzo dużej grupy odbiorców. Kwestionariusze najlepiej sprawdzają się w formie online. Dodatkowym przypadkiem gdy warto stosować kwestionariusze to sytuacja gdy potrzebujemy zebrać wymagania niskim kosztem i w krótkim okresie czasu.

Zaletą tego procesu jest fakt że dopóki tworzymy ankietę na zasadzie zdefiniowanych tematycznie pytań to każdy(nawet ten najmniej wylewny) interesariusz będzie potrafił udzielić nam odpowiedzi. Wadą tego procesu jest fakt że analityk zadaje pytania, więc musi znać otoczenie całego projektu i organizacji, ponieważ pytania przez niego zadawane są do wymagań które już zna lub domniemywa że takie wymaganie może się pojawić.

Dodatkowymi minusami jest fakt że tworzenie ankiet wymaga dużo czasu pracy analityka, może powodować że tworzący ankietę ją stworzy w taki sposób że będzie ona wymuszać pytania w konkretnym nurcie oraz to że podczas wywiadu brakuje interakcji analityk – interesariusz przez co nie ma sytuacji takiej gdzie można podać objaśnienia do zadanego pytania.

4. Obserwacje

Obserwacja polega na tym że specjalista obserwuje i dokumentuje proces i procedury których jest właśnie świadkiem i na ich podstawie tworzy wymagania na system. Często jest to wspomagane naganiami audio i wideo. Technika ta jest super w sytuacji gdzie występują procedury operacyjne które są trudne do opisania słowami i można je dobrze zrozumieć tylko w sytuacji gdzie są one pokazane w sposób fizyczny. Wyróżniamy dwa sposoby obserwacji:

• Obserwacja gdzie specjalista nie zadaje jakichkolwiek pytań tylko jest duchem
• Obserwacja gdzie specjalista aktywnie się uczy, zadaje trudne(lub głupie) pytania po to aby jak najlepiej zrozumieć kontekst biznesowy.

Plusem tej techniki jest fakt że analityk przyjmuje tutaj rolę ucznia a interesariusz rolę nauczyciela co zwiększa zaangażowanie interesariuszy. Problemem tej techniki są sytuacje gdy interesariusz który pokazuje proces niektóre sytuacje uznaje za oczywiste i ich nie tłumaczy co prowadzi do dwuznaczności lub niejasnych wymagań.

5. Analiza dokumentacji

Technika polegająca na tym aby zebrać nowe informacje z istniejących już dokumentów(dokumentacje, procedury, materiały marketingowe, materiały szkoleniowe, raporty, struktura organizacyjna) w organizacji. Technikę można wykorzystać aby zrozumieć kontekst biznesowy lub żeby znaleźć rozwiązania które już są zaimplementowane aby uniknąć wyważania otwartych drzwi. Analiza dokumentacji może także wspomóc w sytuacji gdzie definiowanie obecnych rozwiązań pomija niektóre rozwiązania które były wcześniej zaadresowane i potrzeba ich posiadania nie została przedawniona.

Podczas analizy dokumentacji specjalista podchodzi do niej metodycznie:

1. Najpierw określa czy dokument jest aktualny i prawidłowy
2. Potem definiuje co chce znaleźć w tym dokumencie
3. Potem wykonuje naoczny przegląd dokumentu
4. Następnie wyszukuje po słowach kluczach
5. Następnie notuje odpowiednie wyniki wyszukiwania dokumentu
6. Na koniec oznacza odpowiednie luki w procesie

6. Burze mózgów

Jest to technika która ma na celu stworzenie szerokiej listy opcji do wykonania. Wykorzystuje się ją do zebrania innowacyjnych wymagań, określenia wstępnej wizji dla systemu oraz do zbierania wymagań które są czynnikami entuzjazmu.

Podczas burzy mózgów pomysły są zbierane od uczestników ćwiczenia w określonym okresie czasowym. Pomysły są dokumentowane przez wyznaczoną osobą a następnie po upływie czasu zbierania pomysłów oceniane. Technika jest bardzo skuteczna w momencie gdy uczestnicy są z różnych obszarów biznesowych organizacji. Zagrożeniem dla tej techniki jest sytuacja gdy wśród uczestników są osoby o różnym miejscu w strukturze organizacyjnej.

7. Warsztaty

Warsztaty wymagań to zebranie interesariuszy w jednym miejscu w celu współpracy nad zdefiniowanym celem. Celem może być wiele rzeczy np. planowanie, analiza, wygląd, zakres projektu, zbieranie wymagań biznesowych, modelowanie procesu lub kilka wcześniej wymienionych połączone w jedno. Główne elementy warsztatu to:

• Odpowiednia grupa uczestników
• zdefiniowany cel
• wspólna i aktywna praca uczestników
• zdefiniowany produkt końcowy warsztatów
• osoba która moderuje warsztaty i zachęca do współpracy.

8. Grywalizacja

Technika polega na zaimplementowaniu w istniejącym systemie systemu grywalizacji zachęcającego użytkowników do dzielenia się wymaganiami i pomysłami na rozwój systemu za pomocą elementów grywalizacji (rankingi, odznaki, poziomy.

Grywalizacja z powodzeniem jest też wykorzystywana w zarządzaniu projektami, zarządzaniu backlogiem czy zarządzaniu wymaganiami przez analityka.

9. Prototypowanie

Prototypowanie to technika która służy do zbierania lub walidacji wymagań za pomocą iteracyjnego procesu który ma za zadanie stworzenie modelu lub designu który ma reprezentować wymagania na system(inaczej nazywanego prototypem). Najczęściej prototypowania używa się do tworzenia podstawowych ekranów, optymalizacji UX lub przedstawienia różnych opcji wyglądu ekranu dla użytkownika.

Prototypem może być niedziałające modele, działające pierwsze egzemplarze, cyfrowe aplikacje które mają za zadanie utworzenie wstępnego widoku aplikacji(mockupy, czy lekko upośledzone strony).

10. Zmiana perspektywy

Technika polegająca na tym żeby różni interesariusze(w tym analityk) celowo zmieniają perspektywę swojego myślenia i starają się postawić w interesie innej osoby w celu zebrania innych wymagań. Bardzo często pojawia się to w sytuacji gdy tworzymy user stories i tworzymy uzasadnienie biznesowe w zależności od użytkownika.

Często jako przykład zmiany perspektywy podaje się technikę sześciu kapeluszy. Każdy kapelusz odpowiada za dany sposób postrzegania rzeczywistości. Wtedy każdy z interesariuszy zakłada kapelusz z inną perspektywą (np. dyr. marketingu zakłada kapelusz dyr. finansowego). Taką techniką osoby które są mocno skupieni na swoim obszarze potrafią nabrać innej perspektywy.

Ta technika dobrze się sprawdza w przypadku mocnego skupiania się na jednym obszarze gdzie problem dotyczy wielu obszarów ale sprawdza się słabo gdy potrzebujemy wysokiego poziomu szczegółowości w zadanej dziedzinie.

11. Przygotowywanie przypadków użycia

Technika ta polega na zdefiniowaniu razem z interesariuszami diagramu przypadków użycia. Pozwala to na szybkie i skuteczne zdefiniowanie razem z interesariuszami „Co system ma robić” i następnie można spokojnie przejść do definiowania dalszych kroków specyfikowania(np. tworząc specyfikacje przypadków użycia i diagramy aktywności).

12. Specyfikacja za pomocą przykładów (SBE, Gherkin)

Podejście do zbierania i specyfikowania wymagań na podstawie przygotowania i opisania przypadków testowych zamiast pełnej specyfikacji. Przypadki testowe powinny być napisane w języku gherkin.

Dla zainteresowanych odsyłam do książek:

• Gojko Adzic – Specyfication by Example
• Kamil Nicieja – Writing Great Specifications: Using Specification By Example and Gherkin

13. Paradoks burzy mózgów

Jest to modyfikacja standardowej burzy mózgów polegający na tym że grupa nie rzuca pomysłami jak coś osiągnąć tylko rzuca pomysłami jak osiągnąć efekt odwrotny od zamierzonego. Podczas takiego ćwiczenia uczestnicy bardzo często wyobrażają uświadamiają sobie że proponowane rozwiązanie powinno spełniać o wiele więcej wymagań niż wstępnie zakładano.

14. Technika poszukiwania analogii

W inżynierii bionicznej problemy które projekt napotyka są mapowane na sytuacje które są analogiczne w środowisku naturalnym i rozwiązania które natura podaje są mapowane z powrotem na projekt. Dobrym przykładem są silniki zapasowe na statkach gdzie potrzebny do pociągnięcia statku jest jeden(tak samo do patrzenia na świat wystarczy jedno oko).

Ta technika polega na tym żeby interesariusze podali i odnaleźli analogiczne problemy do istniejących w ich biznesie do takich które istnieją w naturze a następnie analityk jest odpowiedzialny za zmapowanie tych analogii.

Ta technika jest bardzo trudna ponieważ wymaga tego żeby interesariusze znali swój problem bardzo dobrze oraz dobrze znali rozwiązanie które jest zastosowane w przyrodzie.

15. Archeologia systemu

Technika polegająca na wydobyciu informacji do zbudowania nowego systemu z dokumentacji lub kodu innego systemu który jest do wyłączenia lub z systemu konkurencji. Ta technika jest często wykorzystywana w sytuacji gdy wiedza organizacji o logice działania systemu przepadła całkowicie lub nawet częściowo.

Analizując istniejący kod analityk upewnia się że żadna z funkcjonalności systemu który jest do wyłączenia nie zostanie pominięta oraz unika konieczności budowania całej logiki systemu na nowo. Technika jest bardzo pracochłonna i wymaga dużo pracy mimo wszystko jest to jedyna technika która może upewnić analityka że nie przeoczyliśmy funkcjonalności systemu który jest do wyłączenia. W przypadku gdy system ma być większy i lepszy to następne wymagania trzeba wspierać innymi technikami(np. burzą mózgów)

16. Czytanie oparte na perspektywie

Technika ta jest częściej stosowana w przypadku walidacji wymagań ale też z powodzeniem można ją stosować do zbierania wymagań. Polega ona na czytaniu dokumentu wymagań z określoną perspektywą w głowie np. perspektywą testera czy programisty. Tematy niedotyczące danej perspektywy są pomijane.

Taka technika pozwala na analizę wymagań w bardziej szczegółowy sposób w konkretnym aspekcie i pozwala na zebranie nowych wymagań i poruszenie nowych tematów z interesariuszami.

17. Reużycie

Technika polegająca na wykorzystaniu wymagań dotyczące innych systemów które były zebrane i zaakceptowane wcześniej. Przykładowo w danej organizacji są standardy wysyłania powiadomień przez dedykowaną aplikację do wysyłania SMS lub maili. Wtedy warto wykorzystać już stworzone wymagania do innych systemów gdzie jasno opisano jak używać danej aplikacji wysyłającej powiadomienia przez kolejny system.

Reużywanie wymagań skraca czas poświęcony na zbieranie wymagań biznesowych i ich specyfikowanie.

18. Persony lub profile użytkownika

Technika polegająca na utworzeniu sztucznej osoby reprezentującej typowego użytkownika systemu. Stworzona postać dostaje imie, nazwisko, cele, bolączki, typowe zachowania. Utworzenie persony z interesariuszami sprawia że można w prosty sposób przedstawić najważniejsze(i pominięte) przypadki użycia dotyczące systemu dla którego zbieramy wymagania.

Dodatkowym plusem stworzenia persony jest pokazanie developerom że system który tworzą jest dla prawdziwego użytkownika którego potrzeby wydają się bardziej realne i rozwiązania które są programowanie stają się bardziej użyteczne z racji że programista tworzy rozwiązanie z myślą o konkretnej osobie.

19. Zbieranie wymagań biznesowych na podstawie obserwacji danych

Technika polega na tym aby zbierać wymagania na podstawie dostępnych danych w organizacji. Są to techniki skupione na wykorzystaniu dużych zbiorów danych(big data).

Pierwszym zastosowaniem jest przegląd komunikacji polegający na tym że zbudowane algorytmy przeszukują komunikację użytkowników w celu wyłapywania bolączek lub propozycji usprawnień użytkowanej aplikacji.

Kolejna technika to przegląd logów aplikacji w celu odkrycia funkcjonalności które są wykorzystywane bardzo często lub funkcjonalności które są wykorzystywane bardzo rzadko w celu odkrycia które elementy systemu powinny być poddane usprawnieniom.

20. Opinie użytkowników

Technika polegająca na wydobywaniu wymagań z bezpośrednich ocen użytkowników. Najczęściej spotykane w aplikacjach mobilnych które są oceniane w appstore.

21. Analiza procesu

Technika polegająca na ocenie procesu biznesowego(lub procesu zaszytego w aplikacji) w celu wydobycia nowych wymagań. Analiza procesu jest wykorzystywana do wielu celów:

• Rekomendacja efektywniejszego rozwiązania(Zmniejszenie czasu wykonywania konkretnego zadania w procesie, eliminacja niepotrzebnych zadań w procesie, automatyzacja wybranych zadań w procesie, modyfikacja interfejsów w celu sprawniejszego działania, naprawa błędów, udrażnianie wąskich gardeł)
• Wykrywanie luk w procesie
• dodawanie kroków do procesu które są wymagane(np. procedury prawne)
• zrozumienie jak technologia wspiera dany proces
• analiza wpływu zmiany na istniejące procesy.

Analizując proces analityk skupia się aby dowiedzieć się:

• Jaką wartość organizacji daje analizowany proces?
• Jaki wpływ ma cel organizacji ma realizowany proces?
• W jakim stopniu proces musi być kontrolowany pod kątem wydajności?
• Jakie wymagania do systemów sprawią że proces będzie realizował cel biznesowy?

22. Karty CRC (Class, Responsibility, Collaboration)

Technika prosto z projektowania systemów którą można wykorzystać do zbierania wymagań z interesariuszami. Ta technika polega na zbudowaniu szeregu klas(za pomocą prostych karteczek np. sticky notes) które mają określoną odpowiedzialność oraz są powiązane z określonymi klasami. Przykłady:

23. Grupy fokusowe

Technika polegająca na zebraniu pomysłów oraz opinii w wybranym temacie od wyselekcjonowanej grupy osób. Polega ona na tym że moderator(przeważnie analityk choć nie musi to być analityk) prowadzi dyskusję z zaproszonymi osobami które spełniają określone kryteria zgodne z celem projektu.

Dyskusja odbywa się zgodnie z wcześniej przygotowanym scenariuszem opisującym cele badania. Każde takie ćwiczeni powinno posiadać:

• Jasno zdefiniowany cel
• Plan ćwiczenia (po co to robimy, gdzie to robimy, z kim konkretnie, jak długo ma trwać ćwiczenie, jakie wyniki chcemy uzyskać i jak będziemy je analizować)
• Moderatora dyskusji
• Zdefiniowane pytania które zadamy uczestnikom
• Osobę która będzie notować lub nagranie audio/wideo z ćwiczenia.

24. Metoda zbierania wymagań na podstawie czarodzieja z krainy oz

Metoda ta polega na stworzeniu prototypu gdzie osoba symuluje odpowiedzi systemu na akcje wykonywane przez użytkownika. W tym przypadku użytkownik myśli że prowadzi interakcje z komputerem a tak naprawdę odpowiedzi pochodzą od człowieka. Dobrym przykładem jest wirtualny asystent gdzie użytkownik myśli że odpowiedzi pochodzą od komputera a na dobrą sprawę odpowiedzi pochodzą od człowieka.

25. Zbieranie wymagań biznesowych ze wsparciem teorii czynności

Podejście do zbierania wymagań z wykorzystaniem Teorii Czynności opracowanej przez radzieckich psychologów którzy opierali się na pracach Lwa Wygotskiego. Teoria aktywności koncentruje się na tym, co użytkownik faktycznie robi w otoczeniu systemu sugeruje, że projekty rozwoju oprogramowania lepiej i skuteczniej można analizować jako „działania”.

Wykorzystuje się do tego strukturę teorii czynności która wygląda jak na obrazku poniżej:

• Narzędzie – artefakt z pomocą którego aktor zmienia encję
• Aktor – użytkownik, system, interesariusz itd.
• Encja – obiekt który aktor zmienia z pomocą narzędzia
• Reguły – zbiór procedur i regulacji w otoczeniu aktora
• Grupa – społeczność ludzi do których przynależy aktor
• Rola – relacja pomiędzy aktorem a grupą (jaką rolę pełni aktor w danej grupie np. manager)

Zaczynając zbieranie wymagań biznesowych z uwzględnieniem struktury teorii czynności wymagania powinny z założenia być bardziej precyzyjne i ustrukturyzowane, ponieważ analityk aby skończyć zbieranie wymagań biznesowych powinien uzupełnić wspominaną strukturę.

26. Facilitated Application Specification Technique (FAST)

Technika której celem jest przede wszystkim likwidacja różnicy w postrzeganiu tego co jest do zrobienia pomiędzy programistami a interesariuszami. Jeszcze bardziej głównym celem jest szybkie i skuteczne zebranie wymagań 🙂 Polega ona na tym że:

• Organizujemy spotkanie z interesariuszami i developerami
• Przed spotkaniem prosimy developerów i interesariuszy o przygotowanie listy obiektów które są:
  • w otoczeniu produkowanego systemu
  • w produkowanym systemie
  • wykorzystywane przez system aby spełniał on swoje funkcje
• Dodatkowo prosimy o przygotowanie listę funkcji systemu na podstawie podanych obiektów oraz o listę ograniczeń(budżet, termin, reguły, przepisy itd.)
• Na spotkaniu każda lista jest przedstawiana bez krytykowania.
• Po przedstawieniu każdej listy tworzymy całą grupą jedną listę na podstawie wszystkich list. Powtarzające się wpisy usuwamy.
• Po ustaleniu ostatecznej listy, dzielimy cały zespół na mniejsze grupy w celu utworzenia specyfikacji dla poszczególnych punktów(lub punktu) z listy.
• Każda grupa prezentuje swoją mini specyfikację reszcie grupy w celu naniesienia uwag.
• Po przerobionych mini specyfikacjach kończymy spotkanie
• Po zakończonym spotkaniu wskazana jest osoba odpowiedzialna za przygotowanie pierwszej wersji pełnej specyfikacji na podstawie wytworzonych mini specyfikacji

27. Quality Function Deployment (QFD), Cechowanie wymagań wg. modelu Kano

Podejście opisujące nie tyle zbieranie wymagań biznesowych ale klasyfikowanie wymagań na 3 różne kategorie

A te kategorie to:

• Wymaganie niezbędne – Wymagania bez których nie osiągniemy celu biznesowego. Prawdopodobnie będą to wymagania prawne, procedury które organizacja musi spełniać.
• Wymagania spodziewane – Wymagania które wydają się interesariuszom tak oczywiste że interesariusz pomija o nich rozmowy. np. dostęp użytkownika do systemu
• Wymagania niespodziewane- wymagania które są ponad oczekiwaniami interesariusza i jak interesariusz je odkryje w zaimplementowanym systemie

Podobnym rozwiązaniem jest model Kano który tak samo dzieli wymagania na 3 czynniki

• podstawowe – czyli nasze wymagania niezbędne
• wydajności – wymagania spodziewane
• entuzjazmu – wymagania niespodziewane

Model kano przedstawiam na wykresie poniżej. Na wykresie w funkcji po upływie czasu czynniki entuzjazmu stają się czynnikami wydajności a czynniki wydajności czynnikami podstawowymi

28. Inżynieria odwrotna (reverse enginnieriing)

Dziedzina głownie dotyczy działu bezpieczeństwa systemów lecz godnym uwagi jest fakt że z powodzeniem wykorzystujemy ją w biznesie jako technikę zbierania wymagań. Polega ona na analizie gotowego oprogramowania lub urządzenia w celu ustalenia jak dokładnie on działa.

W biznesie analityk dokonuje zakupu online usług innych firm. Zakupu dokonuje po to aby zarejestrować wszystkie ekrany i kroki obsługi klienta. Taką analizę wykonujemy w celu odkrycia słabych punktów w procesie swoim jak i w procesie klienta.

Cała ta zabawa ma na celu odkrycie dobrych praktyk(w tym wymagań do systemu) aby uzyskać przewagę konkurencyjna.

29. Framework PIECES

Jest to zbieranie wymagań biznesowych w oparciu na checkliście która obsługuje najczęściej poruszane obszary w zbieraniu wymagań do systemu. Checklista posiada 6 obszarów (stąd też jest akronim PIECES od pierwszej litery obszaru)

• Performance -> potrzeba poprawy wydajności
• Information -> potrzeba powiększenia bazy informacji
• Economic -> potrzeba redukcji kosztów lub zwiększenia przychodów
• Control -> potrzeba zwiększenia kontroli nad procesem lub zwiększenia bezpieczeństwa
• Efficiency -> potrzeba poprawy efektywności (np. ktoś wykonuje pracę którą ktoś już wykonał zamiast wykorzystać wartość pracy kogoś innego)
• Service -> potrzeba poprawy jakości (np. jakość obsługi klienta lub komfort pracy pracowników)

30. Analiza rynku

Technika polegająca na wykonaniu badania rynku aby odkryć jakich zmian w produkcie lub w systemie oczekują(lub potrzebują) klienci. Celem wykonywania takiego badanie jest pozyskanie informacji jakich zmian musimy dokonać aby mocniej wyróżnić organizację na rynku.

Często też dokonuje się takiej analizy w celu podjęcia decyzji. Przykładowo czy warto wycofać się z rynku lub czy potrzebna jest fuzja z innymi firmami itp.

31. Metoda 635

Specyficzny rodzaj burzy mózgów w którym mamy maksymalnie 6 uczestników i moderatora. Uczestnicy pracują z przygotowanymi kartkami na listę pomysłów na dany temat. Praca polega na tym że w ciągu 5 minut każdy z uczestników musi napisać 3 pomysły w podanym temacie. Po 5 minutach każdy z uczestników przekazuję kartkę z pomysłami do uczestnika obok. Następnie każdy uczestnik dopisuje kolejne 3 pomysły w ciągu 5 minut. Czas pisania pomysłów można skracać/wydłużać w zależności od kreatywności grupy.

W idealnym świecie mamy sytuację gdzie w ciągu 30 minut mamy 108 pomysłów(brak duplikatów i każda sesja trwa 6minut).