Sytuację zna każdy analityk pracujący z istniejącymi systemami: zespół otrzymuje zgłoszenie zmiany lub rozwoju funkcjonalności. Gdzie precyzyjnie przypisać nowe wymagania, skoro nie tworzymy już szczegółowych przypadków użycia od zera? Klasyczne podejście dokumentacyjne sprawdza się przy projektowaniu nowych systemów, ale w codziennej praktyce zarządzania zmianą potrzebujemy czegoś bardziej pragmatycznego.
Odpowiedzią na ten problem może być koncepcja Funkcji Aplikacji – uporządkowanego i praktycznego sposobu dokumentowania oraz grupowania wymagań w kontekście istniejącej funkcjonalności. To podejście pozwala skutecznie zarządzać zmianami bez konieczności tworzenia pełnej dokumentacji przypadków użycia.
Czym jest funkcja aplikacji?
Funkcja aplikacji to logiczna, spójna grupa możliwości, którą system oferuje użytkownikom w celu realizacji określonego celu biznesowego. W przeciwieństwie do przypadków użycia, które projektujemy „od zera”, Funkcje aplikacji stosujemy głównie w kontekście rozwoju i utrzymania istniejących systemów. Funkcje aplikacji są większe niż przypadek użycia i tym samym bez w chodzenia w szczegóły łatwiej jest przypisać wymagania albo zrobić opis zmiany.
Element Feature z diagramie Requirements w Enterprise Architect wraz z ewentualną dekompozycją na PU został pokazany na poniższym rysunku.
Kluczowe cechy funkcji aplikacji:
Dekomponuje aplikację na zarządzalne części – pozwala podzielić złożony system na mniejsze, logiczne obszary odpowiedzialności. Każda funkcja reprezentuje konkretną wartość biznesową dostarczaną przez aplikację.
Jest zbliżona konceptualnie do Application Function z ArchiMate – jeśli w organizacji stosujemy tę notację, funkcje aplikacji naturalnie wpisują się w architekturę korporacyjną.
Stanowi centralny punkt odniesienia dla zarządzania zmianą – wszystkie wymagania dotyczące konkretnego obszaru systemu można łatwo przypisać do odpowiedniej funkcji, co ułatwia szacowanie wpływu zmian i planowanie rozwoju.
Funkcja aplikacji różni się od przypadku użycia przede wszystkim kontekstem stosowania. Przypadki użycia dokumentujemy podczas projektowania nowego systemu albo w organizcji, której jest dokumentacja systemu, natomiast Funkcje aplikacji opisujemy dla istniejącej funkcjonalności, którą chcemy rozwijać lub modyfikować. Dekomponujemy złożone aplikacje na mniejsze części. W organizacjach o pewnej dojrzałości architektonicznej mozna znaleźć moduły aplikacji, które mogą stanowić odpowiednik funkcji aplikacji, co zostało zaprezentowane na poniższym rysunku.
Przykłady funkcji w różnych aplikacjach
Aby zilustrować koncept, przedstawię konkretne przykłady z różnych dziedzin:
System e-commerce: Funkcja „Zarządzanie koszykiem zakupowym” obejmuje wszystkie możliwości związane z gromadzeniem produktów przez klienta – od dodawania artykułów, przez zmianę ilości, po aplikowanie kodów rabatowych.
System CRM: Funkcja „Generowanie raportów sprzedaży kwartalnej” skupia funkcjonalności związane z tworzeniem, parametryzowaniem i udostępnianiem raportów dla celów analitycznych i zarządczych.
Aplikacja bankowa: Funkcja „Obsługa zlecenia stałego” zawiera wszystkie procesy związane z definiowaniem, modyfikowaniem i wykonywaniem automatycznych przelewów cyklicznych.
System HR: Funkcja „Procesowanie wniosku urlopowego” obejmuje pełny cykl życia wniosku – od złożenia przez pracownika, przez akceptację przełożonego, po aktualizację stanu urlopu w systemie.
Jak dekomponować funkcje?
Duże funkcje aplikacji należy dekomponować np za pomocą szczegółowego opisu słownego albo diagramów aktywności. Ułatwia to zarządzanie wymaganiami i pozwala precyzyjnie określić zakres planowanych zmian.
Diagramy aktywności jako podstawowe narzędzie wizualizacji
Rekomenduje stosowanie diagramów aktywności UML do dokumentowania logiki Funkcji aplikacji. Każda funkcja może być przedstawiona jako sekwencja działań z jasno określonymi punktami decyzyjnymi i przepływami alternatywnymi.
Kluczowe zalety tego podejścia:
- Klarowność procesowa – diagram aktywności naturalnie pokazuje sekwencję kroków realizowanych w ramach funkcji
- Obsługa rozgałęzień – łatwe przedstawienie ścieżek alternatywnych i wyjątków
- Identyfikacja podfunkcji – każdy blok aktywności może reprezentować odrębną podfunkcję do dalszego rozwinięcia
Alternatywne podejście dla złożonych funkcji
W skrajnych przypadkach, gdy funkcja jest bardzo rozbudowana i ma wielu różnorodnych aktorów, można zastosować hybrydalnie podejście:
- Użyj diagramu przypadków użycia do dekompozycji głównej funkcji na przypadki użycia
- Zastosuj diagramy aktywności do opisania szczegółowych scenariuszy każdego przypadku użycia
Takie podejście sprawdza się szczególnie w funkcjach obejmujących różne role użytkowników (np. funkcja „Obsługa wniosku kredytowego” z rolami: klient, doradca, analityk ryzyka, decydent).
Funkcje aplikacji w kontekście historyjek użytkownika
Jedną z największych zalet koncepcji Funkcji aplikacji jest naturalne powiązanie z historyjkami użytkownika stosowanymi w metodykach zwinnych.
Grupowanie historyjek wokół funkcji ułatwia zarządzanie backlogiem produktu. Zamiast mieć długą, chaotyczną listę user stories, można je logicznie pogrupować według funkcji aplikacji, które realizują.
Przykład dla funkcji „Zarządzanie koszykiem zakupowym”:
- Jako klient, chcę dodać produkt do koszyka, aby móc go zakupić później
- Jako klient, chcę zmienić ilość produktu w koszyku, aby kupić odpowiednią liczbę sztuk
- Jako klient, chcę usunąć produkt z koszyka, jeśli zmieniłem zdanie
- Jako klient, chcę zastosować kod rabatowy, aby otrzymać zniżkę
Korzyści takiego podejścia:
- Lepsze szacowanie – wszystkie historyjki związane z jedną funkcją można łatwiej oszacować jako całość
- Planowanie sprintów – można planować implementację całych funkcji, a nie fragmentów rozproszonych po systemie
- Testowanie – testy akceptacyjne można grupować według funkcji, co ułatwia weryfikację kompletności implementacji
- Komunikację z biznesem – łatwiej wyjaśnić stakeholderom, jaką wartość biznesową dostarcza konkretna funkcja
To podejście pozwala wykorzystać dobrze znaną notację w elastyczny sposób, dostosowany do specyfiki zarządzania istniejącymi systemami w środowisku zwinnym.
Praktyczny szablon opisu funkcji aplikacji
Ustrukturyzowany opis funkcji aplikacji to klucz do skutecznego zarządzania zmianą. Poniżej przedstawiam gotowy szablon, który można bezpośrednio wykorzystać w Confluence albo SharePoint:
ID Funkcji: [np. ZK-FUN-001]
Nazwa Funkcji: Zarządzanie koszykiem zakupowym
| Element | Opis |
|---|---|
| Cel biznesowy | Umożliwienie użytkownikowi gromadzenia produktów, modyfikacji ich ilości oraz przygotowania do finalizacji zakupu. |
| Komponent aplikacji | Moduł e-commerce |
| Wyzwalacze | Użytkownik klika przycisk „Dodaj do koszyka” na stronie produktu. |
| Aktorzy | Klient (zarejestrowany i niezarejestrowany) |
| Powiązane wymagania | ZK-REQ-054, ZK-REQ-055, ZK-REQ-058 |
| Opis ogólny | Funkcja obejmuje dodawanie, usuwanie, zmianę ilości produktów w koszyku oraz przeliczanie wartości końcowej. |
| Zdekomponowane podfunkcje (Przypadki użycia) |
– Dodawanie produktu do koszyka – Usuwanie produktu z koszyka – Zmiana ilości produktu – Zastosowanie kodu rabatowego |
| Kryteria akceptacji |
– Użytkownik może dodać maksymalnie 10 unikalnych produktów. – Wartość koszyka aktualizuje się w czasie rzeczywistym po każdej zmianie. – Kod rabatowy może być zastosowany tylko raz. |
| model danych (opcjonalnie) | Obiekty: Koszyk, ProduktWKoszyku, KodRabatowy |
Szablon można łatwo kopiować i dostosowywać do specyfiki konkretnych projektów. Kluczowe jest zachowanie struktury, która zapewnia kompletność dokumentacji przy jednoczesnej czytelności.
Podsumowanie
Funkcje aplikacji to praktyczna odpowiedź na wyzwania współczesnego zarządzania zmianą w systemach informatycznych. Główne korzyści to lepsza organizacja wymagań w całym cyklu życia aplikacji, klarowna komunikacja w zespole oraz łatwiejsze planowanie i szacowanie wpływu modyfikacji. To podejście sprawdzi się szczególnie w organizacjach, które rozwijają istniejące systemy i potrzebują pragmatycznych narzędzi dokumentacji funkcjonalności bez wchodzenia w archeologię systemów informatycznych.
Korzystanie z funkcji i modułów aplikacji oraz przypadków użycia jest efektywne, gdy są one gromadzone w jednym repozytorium. Zapisanie ich w narzędziu takim jak Enterprise Architect lub w systemie klasy Wiki pozwoli podczas kolejnej iteracji nie tylko szybciej zidentyfikować niezbędne zmiany, ale również w naturalny sposób tworzyć dokumentację aplikacji.
Funkcje / funkcjonalności to nie są alternatywą, to jest coś bardziej z poziomu architektury biznesowej. Ja to zawsze porównuję do dokumentacji użytkowej, która mówi co to pudełko ma – przypadki użycia są ogólnie słabe bo operują na wycinku ale bardziej dotyczą dokumentacji projektowej – czyli jak coś zbudować.