Analiza biznesowa i systemowa

Często można spotkać się z opinią, że analiza i tworzenie dokumentacji jest stratą czasu. Nic bardziej mylnego. Właściwie określone cele i specyfikacja wymagań pozwalają na sprawną realizację projektu. Zespół deweloperski otrzymuje kompletne opisy funkcjonalności, które można jednoznacznie zrealizować i przetestować ich zgodność z oczekiwaniami klienta. Dobrze wyspecyfikowane wymagania i jednoznacznie opisane przypadki użycia lub historyjki pozwalają uniknąć krytycznych błędów analitycznych, które mogą doprowadzić do konieczności przebudowy całej aplikacji w trakcie prac deweloperskich. Inżynieria wymagań jest kluczem stworzenia aplikacji wysokiej jakości, zgodnej z oczekiwaniami klienta, a to zwiększa szanse na sukces projektu.

inżynieria wymagań, dokumentacja projektu

Jednym z warunków sukcesu każdego projektu IT jest właściwe określenie wymagań, które wobec projektowanej aplikacji ma klient oraz przyszły użytkownik systemu. Zanim jednak przystąpi się do definicji wymagań należy w pierwszej kolejności poznać cele, które ma osiągnąć aplikacja. Celem systemu informatycznego może być np. obsługa sprzedaży biletów, automatyzacja procesu zamówień, masowa wysyłka poczty elektronicznej itp. Rolą analityka jest ustalenie z klientem, jakie są cele aplikacji i na podstawie tych założeń zdefiniowanie oraz specyfikacja wymagań biznesowych, które umożliwią realizację wyznaczonych celów.

Co wchodzi w skład dokumentacji projektowej?

Obszerność dokumentacji zależy w dużej mierze od złożoności projektu. W przypadku prostszych projektów można ograniczyć się do tworzenia historyjek scrumowych na podstawie określonych wcześniej celów i definicji wymagań biznesowych. Projekty o dużym stopniu złożoności wymagają dodatkowo analitycznego opisu funkcjonalności, który jest ustrukturyzowanym opisem wymagań w postaci przypadków użycia. Jeżeli zachodzi taka potrzeba, to opis przypadków użycia wzbogaca się o diagramy UML, takie jak diagramy przypadków użycia, diagramy aktywności, diagramy klas itp.

  • Cele aplikacji - ustalona z klientem i zaakceptowana lista celów biznesowych, które mają być osiągnięte za pomocą projektowanej aplikacji.
  • Definicja wymagań - ustalona z klientem i zaakceptowana lista wymagań funkcjonalnych i niefunkcjonalnych, które ma spełniać aplikacja, aby zrealizować określone cele biznesowe.
  • Analityczny opis funkcjonalności (AOF) - ustrukturyzowany opis wymagań funkcjonalnych i niefunkcjonalnych, który zawiera szczegółowy opis wymagań w postaci przypadków użycia, diagramy UML, dodatkowe specyfikacje techniczne i in. AOF tworzy się w przypadku złożonych projektów.
  • Plany testów akceptacyjnych (PTA) - scenariusze testów akceptacyjnych, które wyczerpują wszystkie ścieżki biznesowe obsługiwane przez aplikację. PTA tworzy się w przypadku złożonych projektów i stanowią podstawę przeprowadzenia testów odbiorowych aplikacji.
  • Historyjki (SCRUM) - zarówno proste jak i złożone projekty informatyczne można prowadzić w metodyce SCRUM. Podstawą pracy są historyjki, tworzone na podstawie listy wymagań lub AOF i realizowane w kolejnych okresach iteracyjnych tzw. sprintach. W przypadku braku dokumentacji AOF każda historyjka jest rozszerzeniem i doprecyzowaniem pojedynczego wymagania biznesowego. Po akceptacji treści historyjki przez klienta jest ona realizowana przez zespół deweloperski. Po wykonaniu historyjki funkcjonalność jest testowana przez analityka i odbierana przez klienta.

Poznaj szczegóły