Śladowanie wymagań – po co i jak?

Zapewne większość Analityków Biznesowych spotkała się z sytuacją, w której ktoś (Project Manager, Sponsor, Product Owner, inny Analityk Biznesowy etc.) zadał jedno z tych niewygodnych pytań. Pytań w rodzaju: „Skąd się wzięło to wymaganie?”, „Co się stanie jak je zmienimy?”, „Czy możemy z niego zrezygnować? Co wtedy?”. Odpowiedź na tego rodzaju pytania bywa niebanalna. Zwłaszcza w przypadku dużych projektów i sporej ilości, związanych z nimi wymagań. Pomóc nam może „śladowanie wymagań” (ang. Requirements traceability).

„Pionowe” śladowanie wymagań

W jednym z poprzednich artykułów opisywałem klasyfikację wymagań i ich hierarchię. Hierarchia i tworzenie powiązań pomiędzy wymaganiami wyższych rzędów i wynikającymi z nich wymaganiami niższych rzędów pozwala śledzić, w jaki sposób wymagania były dekomponowane. Możemy tworzyć relację od potrzeb biznesowych do odpowiadajacych im wymagań biznesowych, dalej od poszczególnych wymagań biznesowych do wspierających je wymagań interesariuszy i w końcu od wymagań interesariuszy do wymagań dla rozwiązania.

Dzięki tego rodzaju powiązaniom wiemy dokładnie, które wymagania niższego rzędu powstały z dekompozycji którego wymagania wyższego rzędu. Wiemy również jaki zbiór wymagań niższego rzędu musi zostać zaimplementowany, aby wymagania wyższego rzędu zostały spełnione. Pozwala nam to określać konsekwencje wprowadzania zmian w poszczególnych wymaganiach lub ich usuwania. Wiemy, które elementy są powiązane z elementem zmienianym / usuwanym i dzięki temu możemy łatwiej analizować wpływ potencjalnej zmiany (ang. Impact analysis).

Dodatkowe korzyści wynikające z tego rodzaju śladowania to łatwiejsza możliwość wyszukiwania sprzeczności (np. pomiędzy wymaganiami różnych poziomów) oraz łatwiejsze odnajdywanie potencjalnych luk. Możemy np. zauważyć sytuację, w której wymaganie wyższego poziomu (np. wymaganie biznesowe), nie ma powiązanych żadnych wymagań niższych poziomu. Może to oznaczać, że wymaganie nie zostało poprawnie zdekomponowane i być może zostało pominięte. Zawsze warto się temu przyjrzeć.

„Poziome” śladowanie wymagań

Również wymagania będące „na tym samym poziomie” mogą być śladowane. Zazwyczaj stosuje się wtedy dwa rodzaje powiązań. Pierwsze z nich oznacza konieczność (ang. Necessity) zaimplementowania jednego wymagania, by zaimplementowanie innego było możliwe. Drugie oznacza zmniejszenie wysiłku (ang. Effort) implementacji określonego wymagania, pod warunkiem implementacji innego. Tego typu śladowanie również jest bardzo pomocne w sytuacji, gdy musimy określić wpływ zmian w wybranych wymaganiach na realizację innych.

Śladowanie wymagań oraz innych artefaktów

Trzecim rodzajem powiazań, jakie mogą wystąpić, są powiazania pomiędzy wymaganiami oraz innymi artefaktami. Atrefaktami tymi mogą być propozycje rozwiązań, testy, czy też kod (np. rewizje lub commity). Tworząc i śledząc tego typu powiązania możemy łatwo sprawdzić, czy dla danego wymagania istnieje jedna lub wiele propozycji rozwiązań, czy istnieje test je sprawdzający, bądź kod, który je realizuje.

Oczywiście powiązania mogą istnieć nie tylko pomiędzy wymaganiem a innymi artefaktami, lecz także pomiędzy poszczególnymi artefaktami, np. pomiędzy designem, a realizującym je kodem lub pomiędzy kodem, a sprawdzającą jego poprawność procedurą testową.

Odpowiedni stopień szczegołowości

Dla efektywnego śladowania wymagań kluczowy wydaje się być dobór odpowiedniego stopnia szczegołowości. Chodzi o to, żeby nie popadać skrajności i nie tworzyć powiązań wszystkich wymagań ze wszystkimi. Prawdą jest, że czasem wydaje się, iż jedno wymaganie wpływa niemal na wszystkie pozostałe i odwrotnie, niemal wszystkie inne wymagania wpływają na jedno określone, jednak śladując wymagania należy zachować zdrowy rozsądek. Zależności pomiędzy powiązanymi wymaganiami powinny być jasne i czytelne, oczywiste dla odbiorcy.

Przesadzając i tworząc nadmiarowe, nieoczywiste relacje, ciężko nam będzie nimi zarządzać. Szybko staną się nieaktualne, a zatem bezużyteczne. Należy tego unikać, zgodnie z zasadą opisaną w jednym z wcześniejszych artykułów.

Podsumowanie korzyści

Podsumowując korzyści ze śladowania wymagań, wymieniłbym niewątpliwe zalety jak: możliwość łatwej oceny wpływu zmian doknywanych w poszczególnych wymaganiach na inne wymagania, łatwiejsze odnajdywanie sprzeczności, bądź niejednoznaczności, możliwość odnajdywania braków lub pominiętych wymagań. Ponadto możemy pośrednio śledzić stan prac nad danym wymaganiem poprzez sprawdzanie podpiętych do niego artefaktów (np. propozycji rozwiązań, testów czy kodu).

Jak śladować wymagania?

Oczywiście istnieje wiele zaawansowanych systemów do zarządzania wymaganiami, takich jak np. Jira (oraz cały ekosystem firmy Atlassian), rozwiązania firmy Microsoft, czy też program Enterprise Architect i inne. Narzędzia te pozwalają na wygodne i efektywne tworzenie powiązań i późniejsze zarządzanie nimi.

Jednak „podstawowa” wersja śladowania wymagań, może być zrealizowana nawet w przypadku, gdy wymagania przechowujemy jako pliki tekstowe. Dobrą praktyką jest nadawanie każdemu z wymagań unikalnego identyfikatora pozwalającego na jego jednoznaczne wyróżnienie. Poprzez taki identyfikator możemy się odwołać do niego w innych wymaganiach i w tej sposób tworzyć powiązania. Nie jest to oczywiście wygodne ani efektywne, ale wciąż możliwe.

Moje rekomendacje

  • Twórz i zarządzaj powiązaniami pomiędzy bardziej ogólnymi wymaganiami i tymi, które powstały po ich zdekomponowaniu
  • Twórz i zarządzaj powiązaniami pomiędzy wymaganiami jeśli implementacja określonych z nich jest niezbędna lub ułatwia implementację innych
  • Podpinaj do wymagań inne artefakty, jak propozycje rozwiązań, czy testy
  • Zdefiniuj odpowiedni poziom szczegółowości; nie staraj się na siłę wiązać wszystkiego ze wszystkim

Źródła

Agile Extension to the BABOK® Guide. Version 2. 2017.