Wymagania dokumentacji projektowej dla systemu informatycznego – o czym nie możemy zapomnieć?

Decydując się na wdrożenie oprogramowania w firmie często skupiamy się wyłącznie na jego funkcjonalności i warstwie użytkowej, zupełnie zapominając o dokumentacji projektowej – niezwykle istotnej, zarówno podczas samego wdrożenia, jak i po jego zakończeniu. Co powinno się na nią składać i jaką powinna przyjąć formę, aby skutecznie zabezpieczyć interesy naszego przedsiębiorstwa?

Czym jest dokumentacja projektowa?

Dokumentacja projektowa, w zależności od celu powstania, charakterystyki oraz fazy projektu, a także preferencji firmy wdrożeniowej występuje pod przeróżnymi postaciami (a zatem jeden, ogólny standard dokumentacji systemu informatycznego w zasadzie nie istnieje). Zaliczamy do niej zarówno specyfikację wymagań biznesowych (na której skupiam się w tym tekście), jak i dokumentację implementacji oprogramowania / kodu źródłowego. Czasami jest ona dokumentem spisanym litym tekstem, komentarzem umieszczonym w kodzie oprogramowania, innym razem diagramem, a jeszcze kiedy indziej – elektronicznym rejestrem zadań (np. tak zwanych historyjek użytkownika) w oprogramowaniu do zarządzania projektami (np. Jira czy Redmine).

Która forma jest właściwa? Każda – w zależności od naszych potrzeb. Jednak w przypadku wdrożeń oprogramowania dla biznesu najlepiej sprawdza się mieszanka tradycyjnej, “papierowej” dokumentacji oraz tej “żywej”, elektronicznej, prowadzonej wraz z rozwojem projektu.

Specyfikacja wymagań

Specyfikacja wymagań jest podstawowym dokumentem opisującym wdrażane oprogramowanie. Charakteryzuje funkcjonalność systemu, jego ograniczenia, powiązania z innymi narzędziami informatycznymi, a także – co niezmiernie ważne – stawiane przed nim cele.

Wyczerpująca specyfikacja wymagań powinna zawierać:

• Cel wdrożenia – informację dlaczego tak naprawdę podejmujemy przedsięwzięcie informatyczne, jakiego rodzaju problemy nowe oprogramowanie miałoby rozwiązać;
• Informację o użytkownikach (aktorach systemu) – czyli dla kogo tak naprawdę przeznaczone jest oprogramowanie;
• Przypadki użycia – charakterystykę podstawowych scenariuszy wykorzystania systemu (np. rejestracja w systemie zakupu dokonanego przez nowego klienta);
• Wymagania funkcjonalne – szczegółowy wykaz wszystkich biznesowych funkcji oprogramowania (łączących się i wspólnie tworzących przypadki użycia) – najlepiej w korelacji z konkretnym celem wdrożenia;
• Wymagania niefunkcjonalne – charakterystyka systemu, która nie niesie za sobą konkretnej funkcjonalności, np.
  • konieczność zapewnienia ciągłości działania oprogramowania przy jednocześnie pracującym tysiącu użytkowników;
  • czas ładowania systemu mniejszy niż 5 sekund;
  • miejsce instalacji systemu – usługa chmurowa.

Specyfikacja wymagań jest dokumentem tworzonym przed wdrożeniem oprogramowania – stanowi więc ona źródło wiedzy o przyszłym systemie – zarówno dla klienta, jak i firmy wdrożeniowej. Dokument ten jest zwykle jednym z załączników do umowy wdrożeniowej, warto więc zadbać, aby był kompletny (wówczas najpełniej zabezpiecza nasze interesy – określając dokładnie czego oczekujemy i co powinno zostać nam dostarczone).

Warto dodać, że jednym z elementów specyfikacji wymagań (oraz innych typów dokumentacji projektowej) są różnego rodzaju diagramy, np. schematy blokowe, diagramy związków encji, mapy procesów biznesowych i inne. W zależności od naszych ustaleń oraz standardów firmy wdrożeniowej, diagramy te mogą być zgodne z którąś z popularnych notacji (np. UML czy BPMN) bądź stanowić wolną twórczość rysownika. Niezależnie od standardu diagramu (bądź jego braku) zadbajmy, aby był opatrzony stosownym opisem. Tylko wówczas mamy pewność, że nie pozostawia on miejsca na własną interpretację – że przedstawia dokładnie to, co autor miał na myśli.

Harmonogram wdrożenia

Bardzo istotnym elementem dokumentacji projektowej jest harmonogram wdrożenia oprogramowania. Warto, aby oprócz terminów realizacji poszczególnych zadań projektowych mówił on również o zależnościach między nimi (co pozwala określić tzw. ścieżkę krytyczną projektu – czyli najkrótszą możliwą drogę jego wykonania). Dobrze ilustruje je wykres Gantta, który warto traktować jako załącznik do umowy wdrożeniowej.

Oprogramowanie projektowe jako dokumentacja

W związku z dużą popularnością metodyk zwinnych, zakładających “wyższość działającego oprogramowania nad rozbudowaną dokumentacją”, wiele projektów odchodzi od tradycyjnych sposobów dokumentowania wymagań, jak specyfikacja wymagań czy harmonogram prac. Zamiast nich, stosuje się narzędzia do zarządzania projektami, wykorzystywane przez zespół realizujący wdrożenie. Dokument specyfikacji zastępują tutaj elektroniczne rekordy zadań – zapisane w formie opisów, grafik, diagramów bądź tzw. historyjek użytkownika. Zaletą takiego rozwiązania jest “żywa dokumentacja”, aktualizowana na bieżąco, wraz ze zmianami założeń – co sprawdza się w podejściu zwinnym (traktującym zmianę wymagań jako codzienność). Jego wadą jest natomiast trudność w utrzymaniu tego typu dokumentacji w należytym porządku (brak standaryzacji, zbyt wielu autorów).

Wspomniałem wyżej, że w przypadku projektów wdrożeniowych oprogramowania dla biznesu jestem zwolennikiem podejścia mieszanego – niezależnie od przyjętej metodyki wdrożenia. Uważam, że podstawowa dokumentacja, taka jak (choćby ogólna) specyfikacja wymagań oraz (orientacyjny) harmonogram projektu są niezbędne do jego bezproblemowej realizacji – stanowią bowiem punkt odniesienia w przypadku jakichkolwiek nieporozumień na linii klient – firma wdrożeniowa. Oprogramowanie projektowe stanowi natomiast ich efektywne uzupełnienie, skutecznie dokumentując przebieg projektu oraz ostateczny kształt budowanego systemu informatycznego.