Niezależnie od tego jaką metodologię wytwarzania oprogramowania przyjmiemy, czy to będzie Scrum czy Waterfall, będzie się na nią składało wiele czynności czy faz. W metodologii Waterfall faza analizy występuje po specyfikacji wymagań oraz przed projektem technicznym i implementacją. Poniższy artykuł opisuje czym są wymagania biznesowe, wymagania funkcjonalne oraz wymagania niefunkcjonalne i jak przeprowadzić ich analizę.

Na początek warto przedstawić diagram kolejnych faz tworzenia oprogramowania:

Chciałbym bardzo mocno zaznaczyć, że to nieprawda, iż w Scrumie Analityk nie jest potrzebny. Zatem co powinien robić Analityk w projektach realizowanych przy użyciu metodyki Scrum? To samo. Tylko częściej i zwinniej. W uproszczeniu powinien analizować wymagania funkcjonalne oraz wymagania niefunkcjonalne przy każdym sprincie.

Tylko czym jest analiza wymagań?

Na początku chciałbym zaznaczyć różnicę pomiędzy tym czym są wymagania biznesowe i funkcjonalne. Otóż wymaganie biznesowe określa to co musi być dostarczone lub wykonane w celu uzyskania wartości. Np wymaganiem biznesowym może być przyśpieszenie procesu obsługi klientów o 20%. W odróżnieniu od wymagań biznesowych wymagania funkcjonalne odnoszą się bezpośrednio do tego co ma się dziać w aplikacji. Np wymagamy aby w systemie można było zrestartować zapomniane hasło.

Kolejną kategorią wymagań są wymagania niefunkcjonalne o których często zapomina się przy realizacji projektu a są one również niezbędne do zrealizowania systemu z powodzeniem. Wymaganie niefunkcjonalne może dotyczyć na przykład wydajności czy dostępności systemu.

Często kiedy rozmawiamy z klientami o projekcie, który chcą zrealizować, prosimy ich o określenie wymagań jakie stawiają tworzonej aplikacji. Niestety rzadko kiedy klient jest je w stanie profesjonalnie przygotować. Znacznie częściej w odpowiedzi dostajemy stronę lub w najlepszym wypadku kilka stron luźno zebranych myśli i nieustrukturowanych pomysłów co powinno się w niej znaleźć.

Przeczytaj też: Specyfikacja Wymagań Projektu Informatycznego – Jak Napisać Ją Prawidłowo?

Niezależenie od tego, z którym przypadkiem mamy do czynienia, pierwszym krokiem jaki wykonujemy jest analiza otrzymanego materiału, próba jego zrozumienia i zinterpretowania w taki sposób, aby mógł powstać z tego pełny, bezpieczny, wydajny i funkcjonalny system.

Od tego jak dobrze swoją pracę wykona Analityk, bądź zespół Analityków zależy dalsze powodzenie projektu.

Przy tworzeniu systemu w Evertop zawsze zaczynamy od serii spotkań i warsztatów analitycznych. Dyskutujemy na temat określonych przez klienta wymagań biznesowych czy funkcjonalności i w zależności od przyjętej metodologii tworzymy Przypadki Użycia (Use Cases) lub Historie Użytkownika (User Stories). Utworzony w ten sposób materiał jest jednym z produktów analizy funkcjonalnej.

Kolejnym krokiem, który często wykonujemy jest stworzenie interaktywnych, klikalnych makiet. Symulują one w bardzo uproszczonym stopniu wygląd tworzonego systemu. Makiety często prezentują już przykładowe dane, przejścia pomiędzy kolejnymi ekranami, metody sortowania czy komunikaty błędów. Pozwala to zespołowi po stronie klienta wczuć się w rolę użytkownika systemu i przejść podstawowe ścieżki oprogramowania.

Przeczytaj też: Czym Jest Prototyp Aplikacji i Dlaczego Warto Go Stworzyć?

Po utworzeniu powyższych elementów możemy także w porozumieniu z testerami opracować od razu Przypadki i Scenariusze Testowe (Test Cases, Test Scenarios) po to, aby po implementacji zespół testerski wiedział co i jak ma dokładnie przetestować.

Podsumowując, w trakcie fazy analitycznej staramy się:

1. Zidentyfikować wszystkie wymagania funkcjonalne oraz wymagania niefunkcjonalne
2. Stworzyć przypadki użycia lub historie użytkownika
3. Stworzyć klikalne makiety
4. Opcjonalnie, stworzyć Przypadki i Scenariusze Testowe

Często zdarza się, że w trakcie wykonywania analizy, wspólnie z klientem odkrywamy, że źle były wyspecyfikowane wymagania funkcjonalne jak i te niefunkcjonalne. Na tym etapie spokojnie można wrócić do wcześniejszej fazy i je skorygować, zmienić czy dodać nowe wymagania systemu.

To co jest najważniejsze to fakt, iż usunięcie niejednoznaczności, niekompletności i braku spójności na etapie tworzenia wymagań kosztuje o rząd wielkości mniej niż ich poprawianie w późniejszych fazach rozwijania systemu.

Czy warto wykonać płatną analizę wymagań przed podpisaniem umowy na wykonanie?

Analiza wymagań jest immanentną częścią cyklu wytwarzania oprogramowania. Jej pominięcie jest albo niemożliwe, albo bardzo kosztowne. Dobra analiza wymagań pozwala lepiej oszacowań pracochłonność kolejnych etapów tworzenia systemu, a co za tym idzie również ich koszt.

Coraz częściej polecamy naszym klientom wykonanie płatnej analizy wymagań jako etapu przed podjęciem decyzji o realizacji projektu bądź nie. Zwłaszcza jeśli oczekują oni oferty typu fixed price.

Przeczytaj też: Time and Materials vs Fixed Price – Which One Is Better?

Przeprowadzamy analizę zarówno wymagań biznesowych jak i wymagań funkcjonalnych a koszt takiej usługi to kilkanaście tyś PLN, czyli relatywnie niedużo patrząc na całkowite koszty tworzenia oprogramowania, a pozwala ona z jednej strony na wydobycie (i często uświadomienie) od klienta wszystkich niezbędnych wymagań funkcjonalnych, a z drugiej strony poznanie i zrozumienie procesów biznesowych jakie u niego funkcjonują.

Posiadając taki materiał jesteśmy w stanie dokładnie wycenić koszt stworzenia systemu, natomiast klient posiada gotowy materiał do stworzenia zapytania ofertowego i wysłania go np. do 2 innych firm.

Konsekwencje źle wykonanej analizy funkcjonalnej

Niezależenie od tego w jakim modelu analiza będzie wykonywana, warto mieć świadomość co się stanie jeśli będzie przeprowadzona nieprawidłowo. Najczęstsze konsekwencje błędów w tej fazie produkcji oprogramowania to:

• błędne szacunki czasu wykonania projektu (a co za tym idzie – błędna wycena),
• niezgodność pomiędzy oczekiwaniami klienta a wytworzonym produktem,
• poważne braki i luki funkcjonalności aplikacji nieodpowiadające procesom biznesowym funkcjonującym u klienta,
• ogromna ilość zgłoszonych uwag przez klienta na etapie odbioru projektu.

Skutki prawidłowo wykonanej analizy

Trochę na zasadzie przeciwieństw. Przy dobrze wykonanej analizie zyskujemy:

• możliwość prawidłowego zorganizowania zespołu odpowiedzialnego za implementację,
• możliwość prawidłowego oszacowania pracochłonności realizacji poszczególnych wymagań,
• możliwość prawidłowego zbudowania scenariuszy testowych.

Podsumowanie

Często kiedy rozmawiam z klientami i opowiadam im o tym, jak powstają systemy informatyczne to używam porównania do budowy domu. Jest to coś bardziej namacalnego i łatwiej im to sobie wyobrazić.

Każdy przeciętny człowiek wie, że zamiana kuchni z łazienką na etapie kartki papieru i ołówka jest dość prosta. Kiedy stoi przed nami świeżo wybudowany dom to takie operacje są już dość karkołomne. Dlatego zawsze powtarzam, że na etapie analizy wymagań możemy sobie fantazjować, zmieniać koncepcję i próbować różnych wariantów projektu. To jest ten moment, żeby wprowadzać poprawki, korekty funkcjonalne i zmieniać zdanie. Wykorzystajmy to. Później będzie tylko trudniej i niestety drożej.