Analiza biznesowa – zbieranie wymagań i zarządzanie wymaganiami

Analiza biznesowa potrzebna jest do sprawnego funkcjonowania każdego przedsiębiorstwa. To od niej zależy powodzenie wielu projektów informatycznych prowadzonych przez firmę, jej rozwój oraz uzyskiwane efekty. Jeśli zostanie przeprowadzona w poprawny i skrupulatny sposób, z pewnością ułatwi wykonywanie wielu obowiązków. Jednak, jeśli sporządzi się ją w sposób nierzetelny, może ponieść za sobą dużo negatywnych konsekwencji. Aby do tego nie dopuścić, warto dowiedzieć się, w jaki sposób przeprowadzić prawidłową analizę biznesową firmy. W tym zwrócić uwagę na zbieranie wymagań i zarządzanie wymaganiami.

Na czym polega zbieranie i organizowanie wymagań?

Wymagania biznesowe lub wymagania systemowe stanowią ważny element w projektach informatycznych. Z tego powodu analitycy podjęli wiele starań, aby opracować właściwe techniki ich pozyskiwania. Takie, które sprawdzą się w różnych projektach – mniej lub bardziej uszczegółowionych. Dzięki zdobytym wymaganiom, czyli informacjom o tym, jakie potrzeby powinien spełniać  system informatyczny i co w sobie uwzględniać, mogą rozpocząć przeprowadzenie analizy. Tego typu porcja informacji wymaga głębszego zastanowienia się nad tym, jak zgłoszone potrzeby mają się do ogólnych wymagań i zasad działania całego projektu. Może przecież okazać się, że nowe wymagania dotyczą zupełnie nowej funkcjonalności lub diametralnych zmian istniejącego już produktu.

W każdym projekcie pojawia się bardzo dużo rozmaitych wymagań. Szczególnie w średnich i dużych projektach, gdzie liczba ich może wynosić nawet od stu do tysiąca wymagań. Z tego względu najpierw należy je odpowiednio posegregować. Organizacja wymagań polega na przyjęciu określonej struktury opisu. Takiej, którą zrozumieją wszystkie strony projektu i która ułatwi późniejsze prace nad wymaganiami. Z praktyki wynika, że tego typu struktura najczęściej obejmowała opis składający się z określonych atrybutów. Na przykład w postaci dokumentu zawierającego tabele. Obecnie częściej forma dostosowuje się do metodyk zwinnych. Może więc obejmować User Story, w którym określa się kryteria akceptacji i dla którego opracowuje się mockup.  A także issue w narzędziu typu JIRY, gdzie opisuje się sposób implementacji. Organizowanie wymagań jest czasochłonnym zajęciem, które nie stanowi jeszcze samej w sobie pracy z wymaganiami.

Modelowanie

Zebrane wymagania należy wyspecyfikować, czyli stworzyć z nich spis w dowolnej formie. Wraz ze specyfikacją często opracowuje się także modele. Podczas modelowania używa się dwa typy diagramów, które są najbardziej przydatne. To Agile modeling, przeciwieństwo starszych metod z wykorzystaniem UMLa, gdzie w dokumentacji projektowej umieszczano wszystkie możliwe diagramy.

W dokumentacji projektowej znajduje się więc wycinek diagramu klas opisujący encję, których w danym momencie dotyczy Story, model procesu biznesowego lub jego wycinka, a co najważniejsze, prototypy, które są najbardziej znaczące podczas komunikacji z interesariuszami. Ze wszystkich diagramów korzysta się podczas prowadzonych bieżących prac. W przypadku ich dezaktualizacji można po prostu je usunąć. Nie ma potrzeby ich długotrwałego  przechowywania.

Weryfikacja wymagań

W momencie, w którym wymagania nabierają formy, zaczynamy posiadać swego rodzaju paczkę, którą będziemy implementować. Niezbędna jest wtedy weryfikacja naszych wymagań. Polega ona na monitorowaniu odpowiedniej jakości wymagań, które powinny zostać zaimplementowane. W końcu zgodnie z ponadczasowymi standardami wymagania muszą być prawidłowe – bezbłędne, wzajemnie bezsprzeczne, jednoznaczne, wykonalne technicznie i możliwe do testowania. Niezależnie od sposobu opisu wymagań, atrybuty te zawsze mają zastosowanie. Po stworzeniu specyfikacji wymagań należy sprawdzić ich zgodność z przyjętą strukturą oraz to, czy spełniają standardy dobrych wymagań. W przypadku, gdy tak nie jest, szybko będą wymagały programistycznej poprawy.

Walidacja

W przypadku projektów prowadzonych metodami zwinnymi walidacja jest nieodłącznym elementem prowadzenia projektu. Dzieje się tak, ponieważ doceniono możliwość dokonania oceny używanego produktu, jako sposobu na pokazanie fatycznej wartości rozwiązania i jego zgodności z potrzebą biznesową końcowemu użytkownikowi i innym przedstawicielom firmy.

Walidacja jest wykonywana także w trakcie innych etapów, np. podczas sesji refinementu lub planningu. Jej celem jest więc potwierdzenie tego, czy wymagania są odpowiednie i czy dobrze trafiają w potrzebę biznesową. Sprawdzone wymaganie może być poprawnie spisane, jednak może okazać się, że niedokładnie opisuje ono realną potrzebę. Dzięki walidacji jesteśmy w stanie wyłapać tego typu błędy i wyeliminować późniejsze straty czasu nad implementacją, testowaniem lub analizą wpływu tego wymagania na inne.

Jak przebiega zarządzanie wymaganiami?

Zarządzanie wymaganiami odnosi się przede wszystkim do systemów lub aplikacji, które są budowane i rozwijane. Jest to całość czynności, które wykonuje się, aby wymagania były możliwe do użycia, aktualne i dostępne dla wszystkich zainteresowanych.

Utrzymanie wymagań

Najważniejszą sprawą jest utrzymanie wymagań. Mimo panującego trendu do tworzenia jak najmniejszych dokumentacji nie tworzenia jej wcale lub jedynie na bieżąco w wyniku potrzeby developmentu bez jej dłuższego przechowywania. Dokumentacja z wymaganiami potrzebna jest w wielu projektach, ponieważ zmieniają się ich uczestnicy, którzy muszą dokładnie wiedzieć, co należy robić. Nie zapewni im tego sam kod lub gotowa aplikacja. Niekiedy trzeba przecież wrócić do pewnych funkcjonalności, aby móc je rozwinąć, zmodyfikować lub wzorować się na nich w tworzeniu nowych możliwości. Niezależnie od formy, w jakiej będą zebrane wymagania – model, opis, czy prototyp, jest ona niezbędna.

Ustalenie priorytetów

Ustalenie priorytetów, czyli, krótko mówiąc priorytetyzowanie, dotyczy zarówno tradycyjnych, jak i nowoczesnych projektów. Jest niezwykle istotne w metodykach zwinnych, kiedy należy dokonać wyboru pomiędzy dwoma wymaganiami. Może to wynikać z różnych czynników. W przypadku projektów waterfall może pojawić się konieczność ograniczenia zakresu tak, aby zmieścić się w budżecie oraz przewidzianym czasie realizacji. W projektach typu agile chodzi przede wszystkim o ustalenie funkcjonalności najbliższego przyrostu aplikacji. Oznacza to, że aplikacja na koniec iteracji powinna działać. Wybiera się więc taki pod zakres, który będzie najistotniejszy z punktu widzenia wartości biznesowej i możliwy do zaimplementowania. Priorytetyzowanie leży w gestii interesariuszy biznesowych, a więc do Product Ownera. Jednak niezbędna jest w nim rola analityka, który najczęściej ma świadomość tego, że trzeba ustalić kolejność, a także dostarcza do tego odpowiednich technik.

Śledzenie wymagań

Dla wszystkich wymagań należy utrzymać wertykalne i horyzontalne powiązania. Wertykalne to te pomiędzy wymaganiami. Są bardzo istotne w przypadku analizy zmian w wymaganiach. Powiązania horyzontalne to te pomiędzy wymaganiami, ich implementacją i pojedynczym testem, który ma na celu sprawdzenie implementacji wymagania. Śledzenie tego typu powiązań w obu kierunkach sprawia, że nie przeoczy się żadnych występujących po drodze zjawisk. Pozna się wszystkie problemy i wysiłki, które należy ponieść, aby prawidłowo zaimplementować aspekty odpowiadające na wyznaczoną potrzebę biznesową.

Komunikowanie wymagań

Komunikowanie wymagań polega na informowaniu interesariuszy o powstaniu zmiany w wymaganiach lub o tym, że któreś z nich w ogóle się nie pojawiło. To niezwykle istotna informacja dla developerów, szczególnie jeśli są w trakcie developmentu, ponieważ oznacza, że będą musieli w inny sposób zrealizować daną funkcjonalność. Komunikowanie wymagań jest również ważne dla strony biznesowej projektu. Tutaj istotny jest przekaz od developerów. Np. o tym, że nie można w oczekiwany sposób  zrealizować niektórych funkcjonalności. Tego typu sytuacje naprawdę zdarzają się często. Dlatego ważne jest zachowanie transparentności każdej sytuacji i dla wszystkich zainteresowanych stron.

Status wymagań, czyli cykl życia wymagań

Dotyczy aspektu powiązań horyzontalnych i utrzymania. Najczęściej w projektach mamy do czynienia z ogromną ilością wymagań.  Na szczęście możemy wyposażyć się w odpowiednie narzędzia, które pomogą nam nimi zarządzać. Należy do nich np. JIRA lub dedykowane narzędzie do zarządzania jedynie wymaganiami. W tego typu oprogramowaniach można bez przeszkód zarządzać statusami. Na przykład w blacklogu dla produktu (blacklog wykorzystuje się w projektach prowadzonych zgodnie z metodyką SCRUM i scrumopodobną) przechowuje się wszystkie informacje o tym, co należy w produkcie wykonać. Istotne jest więc, by dokładnie wiedzieć, co trzeba zrobić, co jest w trakcie realizacji (oraz na jakim etapie – czy jest to etap developmentu, testów wewnętrznych, a może akceptacji?), a także, co już wcześniej zostało wykonane i co jest archiwalnym wymaganiem. Co więcej, ważne stają się także niektóre statystyki, które można prowadzić, np. wydajności pracy zespołu developerów dla danej liczby wymagań określonych rozmiarów, statystyki służące porównaniu  wersji produktu pod kątem rozmiaru lub samej liczby wymagań i dla innych parametrów.

Zarządzanie wymaganiami to skomplikowany etap analizy biznesowej. Jest jednak bardzo ważny, ponieważ stanowi nieodłączny element cyklu życia całego produktu. Jeśli produkt żyje – jest wykorzystywany, muszą istnieć dla niego wymagania. Z kolei operujący nimi analityk musi je mieć uporządkowane, by w prosty sposób móc z nich korzystać i doskonalić swoje prace.