.

Zbieranie wymagań biznesowych [jaką technikę wybrać?]

Posted by admin

Cześć! Tutaj Szymon z analizowac.pl W tym poście poruszę temat wyboru techniki zbierania wymagań biznesowych. Przez całą swoją karierę dobierałem techniki ekspercko z wykorzystaniem doświadczenia i tego jak zbieranie wymagań wygląda w danej organizacji.

Wiadomo, wykorzystywałem proste schematy typu:

  • Interesariusz nie umie do końca opisać swojego procesu – obserwacje
  • Duża grupa interesariuszy, mało czasu – ankiety
  • Znany problem lub okazja, brak pomysłu jak go zrobić – burza mózgów
  • Stary system do przepisania – archeologia systemu
  • etc

Jednak nie miałem do tego żadnego ciekawego procesu który opisywał by jasno. Taka i taka sytuacja to taka i taka technika. Ostatnio zacząłem się zastanawiać nad tym jak u mnie wygląda proces doboru techniki zbierania wymagań biznesowych. I szukając też innych ludzi którzy dokonywali takich samych przemyśleń natknąłem się na fajną matrycę doboru technik wyboru techniki pozyskiwania wymagań biznesowych. Sposób doboru techniki wydawał mi się na tyle ciekawy że postanowiłem się nim podzielić na blogu.

Zbieranie wymagań – matryca

Cała matryca wyboru najlepiej jest do przedstawienia za pomocą schematu

Zbieranie wymagan

Wybór naszej techniki zbierania wymagań jest podzielony na 3 filary wyboru które potem razem łączymy i na podstawie tych filarów wybieramy technikę. Te filary to

  • Parametry projektu
  • Interesariusze
  • Jak wytwarzamy oprogramowanie

Przejdźmy przez każdy z tych filarów.

Parametry projektu

W filarze „Parametry projektu” definiujemy zakres parametrów które przypisujemy do projektu(piękne zdanie mi wyszło no ale czy tego chcę czy nie to właśnie to robimy w tym kroku). A jakie parametry mamy? Poniżej tabelka

ParametrOpis
Rozmiar projektuRozmiar projektu definiujemy po ilości wymagań które dany projekt dostarcza. Wyróżniamy trzy typy:
– Mały (do 100 wymagań)
– Średni (do 1000 wymagań)
– Duży (powyżej 1000 wymagań)
Złożoność projektuZłożoność definiujemy na podstawie takich czynników jak liczba modułów których zmiana dotyczy, liczba systemów z którymi trzeba się zintegrować, liczba technologii jakich trzeba użyć, zróżnicowanie obszarów z jakich pochodzą interesariusze, liczba ludzi decyzyjnych w projekcie. Dzielimy na 4 typy
– Niska
– Średnia
– Wysoka
– Bardzo wysoka
Zmienność wymagańCzyli liczba wymagań które się zmieniają wraz z upływem czasu trwania projektu. Dzielimy na 3 typy
– Mała
– Średnia
– Duża
SolidnośćCzyli stopień jakości wymagań jaki jest potrzebny dla bezpieczeństwa wdrożenia projektu. Dzielimy na 4 typy
– Niska
– Średnia
– Wysoka
– Bardzo wysoka
Ograniczenie Czas/budżetCzyli ile mamy czasu na wdrożenie projektu oraz jakim budżetem dysponujemy. Projekt może być rygorystyczny lub bardziej elastyczny. Dzielimy na 4 typy
– Niski
– Średni
– Wysoki
– Bardzo wysoki
Czy domena biznesowa istnieje?W tym parametrze definiujemy czy proces który chcemy usprawnić oprogramowaniem istnieje czy nie. Projekt może być wymianą obecnego systemu lub wyrzuceniem obsługi procesu na Excelach a może być tworzeniem nowych procedur. Dzielimy na dwa typy
– Istniejąca
– Nowa
Dostępność interesariuszyCzyli czas jaki interesariusze są w stanie nam poświęcić
– Niska
– Średnia
– Wysoka  
Zasięg projektuOdpowiada na pytanie czy aplikacja będzie używana tylko przez ludzi w  danej organizacji czyli aplikacja szyta na miarę(wewnętrzna) czy przez zewnętrznego klienta czyli aplikacja pudełkowa (zewnętrzna)
– Wewnętrzna
– Zewnętrzna
Wiedza domenowaCzyli odpowiedź na pytanie jak bardzo znamy domenę biznesową projektu. Dzielimy na 3 typy – Mała
– Średnia
– Duża
Wielkość zespołu
developerskiego
Czyli jak bardzo niezawodne musi być oprogramowanie. Wyróżniamy 3 typy
– Mały (czyli prosty system biznesowy gdzie do obsługi wystarczy max kilku programistów którzy znają system od podszewki) np. system do zarządzania zadaniami
– Średni (czyli system który wymaga większej ilości programistów i nie muszą oni znać wszystkiego)
– Duży  (czyli system który jest duży, nie może zawieść pod żadnym pozorem i wymaga dużej ilości programistów) np. system obsługi bankomatów lub kontroli lotów

Identyfikacja charakterystyk ludzkich

Jak wszyscy dobrze wiemy, ludzie odgrywają największą rolę w przypadku każdej inicjatywy związanej z rozwojem informatycznym organizacji. Tak samo jak w procesie wytwórczym w przypadku wyboru techniki zbierania wymagań, charakterystyka interesariuszy odgrywa dużą rolę. Zachowanie interesariuszy ich wiedza, doświadczenie mają duży wpływ na to jak zbieranie wymagań biznesowych będzie wyglądać.

Dlatego jednym z filarów wyboru techniki zbierania wymagań jest identyfikacja z jakimi interesariuszami mamy do czynienia. Tutaj tak samo jak w przypadku parametrów projektowych przygotowano matrycę cech ludzkich.

W tej matrycy oceniamy Interesariusza ale i Analityka. W przypadku analityka określamy dwie cechy:

  • Doświadczenie w inżynierii oprogramowania (Nowicjusz/Doświadczony/Ekspert)
  • Doświadczenie w domenie biznesowej (Nowicjusz/Doświadczony/Ekspert)

W przypadku Interesariusza mamy dwie cechy

  • Doświadczenie w domenie biznesowej (Nowicjusz/Doświadczony/Ekspert)
  • Charakter (Cichy/Komunikatywny/Otwarty)

Proces wytwarzania oprogramowania

Tutaj to zwyczajnie wyróżniono najbardziej popularne metody wytwarzania oprogramowania i na nie nałożono dopasowanie do technik zbierania wymagań biznesowych. Wyróżniono następujące procesy:

  • Waterfall
  • Prototypowanie
  • Model eksploracyjnego wytwarzania oprogramowania
  • Model spiralny wytwarzania oprogramowania
  • Model skupiony na reużywalności aplikacji
  • Modele Agileowe
  • Proces zunifikowany jak np. RUP
  • Rapid application development (RAD)

Matryce wyboru techniki zbierania wymagań

Po zdefiniowaniu filarów do wyboru metody zbierania wymagań przyszedł najwyższy czas na to żeby dobrać do tego techniki. A jaka propozycja została tutaj przedstawiona? Jak zwykle najlepszym sposobem pokazania czegokolwiek to pismo obrazkowe więc dla odmiany przedstawiamy 3 matryce wyboru techniki zbierania wymagań.

Matryca parametrów projektu

Zbieranie wymagan

Matryca charakterystyk ludzkich

Wartości w matrycy są T/N (Tak/Nie) w odpowiedzi na pytanie czy używać danej techniki. Tam gdzie jest kreska to dana technika nie dotyczy cech interesariusza.

Zbieranie wymagan

Matryca procesu wytwarzania oprogramowania

Zbieranie wymagan

W przypadku tej matrycy zalecane jest stosowanie prostej zasady która brzmi:

Jeśli dla danego procesu dana technika ma wartość >=0.5 to można tą technikę stosować.

Wydaje się proste.

Przykład

Jak już opisałem całe założenia z artykułu to teraz warto jest przerobić to jakoś przetestować.

Weźmy sobie prosty przykład i zobaczmy jak będzie wyglądać zbieranie wymagań dla niego. Załóżmy że jesteśmy w sytuacji gdzie mamy:

Osoby – Interesariusze

  • Osoby które zjadły zęby na swoim biznesie
  • Osoby które są otwarte
  • Osoby które nie dysponują dużą ilością czasu

Osoby – Analityk

  • Mamy dobry background techniczny
  • Słabo jeszcze znamy dziedzinę biznesową

Proces wytwórczy

Proces wytwórczy niech będzie procesem Agileowym czyli np. najbardziej popularny Scrum

Rozmiar projektu

Rozmiar niech będzie średni. Kilkaset wymagań.

Złożoność i solidność

Powiedzmy że to prosta aplikacja więc niech będzie średnia

Zmienność wymagań

Niech będzie niska(czyli idealny świat dla każdego programisty co raczej się nie udaje)

Ograniczenia czas/budżet

Powiedzmy że tutaj zbyt dużego ciśnienia nie ma więc zróbmy niskie.

Domena biznesowa istnieje, projekt wewnętrzny i zespół developerski nie jest za duży.

Jak to nam się mapuje na techniki zbierania wymagań?

Zbieranie wymagan

Patrząc po matrycy parametrów projektowych to szybko nam się lista technik zawęża. BA! nawet jedna technika nie jest w stanie w 100% się wpasować w nasz projekt. No ale nie załamujemy się. Najbardziej pasujące techniki które mają najwięcej podkreśleń(7 podkreśleń) to

  • Grupy fokusowe
  • Warsztaty
  • Obserwacje
  • Analiza protokołu
  • Analiza dziedziny biznesowej/procesu biznesowego
  • Introspekcja

Matryca ludzi też nie ma techniki w 100% pasującej więc wybierzmy te co mają najwięcej „okejek”:

  • Burze mózgów
  • Wywiady
  • Grupy fokusowe
  • Warsztaty

Techniki które w modelu Agile mają >=0.5 to

  • Wywiady
  • Grupy fokusowe
  • Warsztaty
  • Obserwacje
  • Analiza kultury organizacji
  • Prototypowanie
  • Modelowanie
  • Analiza dziedziny lub procesu
  • Laddering
  • Introspekcja
  • Mapy myśli
  • Analiza dokumentacji

No i mamy zwycięzców!! Możemy zaczynać zbieranie wymagań 😉

Wybierzmy laureatów naszego plebiscytu! Techniki dla których zbieranie wymagań najbardziej pasuje do danej sytuacji to(czyli techniki które są w trzech matrycach):

  • Grupy fokusowe
  • Warsztaty

Techniki które są w 2 matrycach

  • Obserwacje
  • Analiza dziedziny lub procesu biznesowego
  • Introspekcja

Jestem zaskoczony. Byłem mocno sceptyczny do tego ale wyszło całkiem dobrze w mojej skromnej ocenie.

Podsumowanie

Podsumowując. Sposób jest… Ciekawy. Jednak wydaje się trochę zadaniem takim dla ludzi którzy lubią sobie pogrzebać i podumać w jakiś rzeczach które nie mają zbyt dużej wartości. Czyli dla ludzi takich jak ja którzy jak się czymś zainteresują to nie odpuszczają i grzebią do końca. Może w sumie by napisać taką apkę która wyliczy te techniki na podstawie wprowadzonych danych? W sumie w wolne jesienno-zimowe weekendy nie będzie co robić 🙂

Źródło

A Methodology for the Selection of Requirement Elicitation Techniques – Santosh Singh Rathore Thapar University, Saurabh Tiwari DA-IICT, Gandhinagar

Chcesz zostać Analitykiem IT? Kliknij w baner poniżej

DARMOWA checklista jakości wymagań!

Zapisz się na listę mailową a dam Ci za darmo checklistę jakości wymagań biznesowych.

Uzupełnienie powyższego pola stanowi zgodę na otrzymywanie od analizowac.pl newslettera zawierającego treści marketingowe. Zgodę można wycofać w każdym czasie. Wycofanie zgody nie ma wpływu na zgodność z prawem przetwarzania dokonanego przed jej wycofaniem.