Macierz trasowania wymagań: przykład i jak ją prowadzić

Wymaganie zmienia się w piątek wieczorem. Klient prosi o wysyłanie statusu zamówienia dodatkowo SMS-em — e-mail to za mało. Lider zespołu zadaje normalne pytanie: co się zepsuje? I okazuje się, że nie ma kto odpowiedzieć. Analityk pamięta o e-mailu, tester — o swoich przypadkach, programista — o serwisie, który wywołuje bramkę. Całości obrazu nie trzyma w głowie nikt.

Macierz trasowania wymagań trzyma ten obraz za ciebie. W niej każde wymaganie jest powiązane w górę — z tym, skąd się wzięło, i w dół — z tym, gdzie jest zaimplementowane i czym sprawdzone. Można ją czytać w obie strony: od celu biznesowego do przypadku testowego i z powrotem.

Na rozmowie kwalifikacyjnej pytają o nią często, a odpowiada się zwykle połową: „tabela, gdzie wymagania są zestawione z testami”. To prawda. Ale to najnudniejsza jej połowa i po niej od razu słychać, że człowiek widział macierz na slajdzie, a nie prowadził jej.

Co tak naprawdę łączy

Definicja z ISO/IEC/IEEE 29148:2018 — międzynarodowego standardu pracy z wymaganiami — brzmi sucho, za to precyzyjnie: trasowalność to identyfikacja i udokumentowanie ścieżki wyprowadzenia w górę i ścieżki alokacji w dół w obrębie zbioru wymagań. Wymaganie, z którego wyprowadzono inne, standard nazywa rodzicielskim, wyprowadzone — potomnym.

Dalej standard wylicza, do czego wymaganie powinno być trasowane: w dół — do wymagań niższego poziomu, do architektury, do elementów systemu, które je implementują, oraz do bytów weryfikacyjnych, które je sprawdzają; w górę — do wymagań rodzicielskich, z których jest wyprowadzone, lub do potrzeb interesariuszy.

Sama macierz jest opisana w standardzie osobnym terminem: ustrukturyzowany artefakt informacyjny, który łączy wymagania z wymaganiami wyższego poziomu lub potrzebami oraz z implementacją niższego poziomu.

W tym miejscu warto rozdzielić dwa słowa, które w rozmowie często się myli. Trasowalność to cecha: powiązania między wymaganiami istnieją i są utrzymywane. Macierz to forma, w której wygodnie je pokazać. Można prowadzić trasowanie bez ani jednej tabeli, ale można też mieć ładną tabelę i nie mieć trasowalności — jeśli zapisano w niej coś, czego już dawno nie ma.

Każdy kierunek odpowiada na inne pytanie. W górę — „po co to robimy”: każde wymaganie musi opierać się na czyjejś potrzebie, inaczej wymyślono je po drodze. W dół — „czy to zrobiliśmy”: wymaganie ma kod, który je implementuje, i sprawdzenie, które to potwierdza.

Macierz to nie raportowanie dla odhaczenia. To jedyne miejsce, gdzie na pytanie „co się zepsuje” odpowiada się w minutę, a nie w dzień.

Przykład: pięć wierszy, od których można zacząć

Sklep internetowy. Cel kwartału — odciążyć wsparcie: zbyt wiele zgłoszeń „gdzie moje zamówienie”.

Pięć wierszy, pięć kolumn — to już wystarczy, żeby macierz zaczęła działać. Kolumn bywa więcej: priorytet, właściciel, wersja, status. Ale dodatkowe kolumny wygodnie dodaje się do żywej macierzy, a bez sensu projektuje z góry.

Wróćmy do piątkowej prośby o SMS. Patrzysz na wiersz FR-13: w górę od niego SH-4, w dół — szablon e-maila i jeden test. Czyli dodaje się brat FR-13, a nie poprawka FR-12; ekranu nie ruszamy, NFR-3 o pięciu minutach pozostaje w mocy i obejmuje nowy kanał. Odpowiedź dla lidera zajęła minutę.

Zwróć uwagę na wiersz BG-1. Ma pustkę w kolumnie implementacji — i to normalne: celu biznesowego nie implementuje się kodem, sprawdza się go metryką. Pusta komórka oznacza tu nie dziurę, a granicę.

Co o trasowaniu mówi BABOK

W BABOK trasowanie to nie technika, lecz osobne zadanie: 5.1 Trace Requirements w obszarze wiedzy „Zarządzanie cyklem życia wymagań”. Tam też nazwano typy relacji. Jest ich dokładnie cztery: derive, depends, satisfy i validate.

• Derive — jedno wymaganie jest wyprowadzone z drugiego, między nimi są różne poziomy abstrakcji. FR-12 jest wyprowadzone z SH-4.
• Depends — wymaganie zależy od innego. Dwa podtypy: necessity, gdy implementowanie go w pojedynkę nie ma sensu, oraz effort, gdy można, ale razem taniej.
• Satisfy — powiązanie elementu implementacji z wymaganiem, które on zamyka. Serwis statusów zamyka FR-12.
• Validate — powiązanie wymagania z przypadkiem testowym, który potwierdza, że rozwiązanie spełnia wymaganie.

Różnica między necessity a effort to pytanie o poziom głębiej — i po nim zwykle widać, czy ktoś prowadził trasowanie, czy opowiada rozdział.

Sam przewodnik patrzy na trasowanie szerzej niż „powiąż wymaganie z testem”. Zadanie 5.1 jest mu potrzebne do zarządzania zakresem prac i ryzykiem jego rozpełzania, znajdowania luk, oceny wpływu zmian, rozumienia statusu każdego wymagania oraz rozdzielania wymagań na release’y i komponenty. To narzędzie zarządzania, a nie dokumentowania.

Wewnątrz zadania są trzy elementy: poziom formalności, same powiązania oraz repozytorium trasowalności. Pierwszy jest najważniejszy i to on jest najbardziej dojrzałą odpowiedzią przewodnika na cały temat. BABOK nigdzie nie wymaga trasowania wszystkiego po kolei. Wymaga, żeby raz świadomie zdecydować, co jest trasowane i do jakiego poziomu — bo powiązania kosztują czas, a trasowalność to tu nie cnota, tylko inwestycja z ceną i zwrotem.

Narzędzi w ogóle nie wymienia i to jest świadome. O repozytorium trasowalności powiedziano dokładnie jedno: w skomplikowanych przypadkach się je automatyzuje. Trzecia edycja wyszła w 2015 roku i nadal jest aktualna — oczekiwanie od niej listy nowoczesnych systemów nie ma sensu, ona wyznacza zasady, a nie produkty.

O samym przewodniku wiedzy i o tym, po co analitykowi, w artykule Co to jest BABOK i jak go używamy.

Co ona wyłapuje

Trzy rzeczy, dla których w ogóle się ją zakłada.

Sieroty. Wymaganie bez żadnego powiązania w dół — nikt go nie zaimplementował i nikt nie sprawdził. Przypadek testowy bez powiązania w górę — testujemy coś, o co nie proszono. Standard proponuje to nawet mierzyć: udział rodziców bez dzieci i średnią liczbę wymagań potomnych na rodzica, gdzie drugie jest wskaźnikiem złożoności projektowania. W naszej tabeli sierotę widać gołym okiem: gdyby w FR-13 w kolumnie sprawdzenia było pusto, e-mail o zmianie statusu poszedłby na produkcję bez testów, a zauważyliby to klienci.

Wpływ zmian. Ten piątek z SMS-em. Bez macierzy pytanie „co się zepsuje” zamienia się w ankietę wśród trzech osób i i tak kończy się słowem „chyba”.

Pokrycie. Gdy klient po pół roku pyta „a to zrobiliście?”, macierz odpowiada wierszem, a nie wspomnieniami zespołu.

Ile to kosztuje i kiedy nie trzeba

Teraz uczciwa część, którą na kursach rzadko się omawia. Powiązania nie pojawiają się same i nie utrzymują się same. Każdy nowy wiersz to praca, którą ktoś wykonuje ręcznie, a potem aktualizuje przy każdej zmianie.

Im bardziej złożona sieć powiązań, tym drożej utrzymać ją żywą — właśnie dlatego przewodnik wymaga określenia poziomu formalności z góry, a nie w trakcie. Decyzja jest podejmowana raz i świadomie: co trasujemy, do jakiego poziomu, czym.

Praktyczna rada jest jedna. Nie zakładaj osobnego Excela, jeśli zespół żyje w Jirze: powiązania między zadaniami to już trasowanie, a macierz składa się filtrem. Plik na dysku przeżywa dokładnie jeden sprint, w którym zapomniano go zaktualizować. A martwa macierz jest gorsza niż brak macierzy — powołują się na nią, a ona kłamie.

Od czego zacząć, jeśli macierzy nie ma

Nie zaczynaj od historii. Odtworzenie powiązań z trzech lat rozwoju jest niemożliwe, a próba zje miesiąc i skończy się niczym.

Weź najbliższy release. Wypisz jego wymagania z identyfikatorami — po prostu ponumeruj, jeśli numerów nie było. Każdemu przypisz źródło: czyja to potrzeba i z jakiej decyzji wyrosło. Potem — czym jest sprawdzane. I tyle, macierz jest.

Dalej zacznie się ciekawe: część komórek zostanie pusta. To nie porażka ćwiczenia, to jego wynik. Pusta komórka w kolumnie źródła oznacza wymaganie, które nie wiadomo po co. Pusta w kolumnie sprawdzenia — coś, co pojedzie na produkcję bez testów. Z tymi dwiema listami można już iść na spotkanie zespołu i rozmowa będzie konkretna.

Jak to się robi dziś: trasowanie z modelem

Najbardziej nudna część trasowania to nie myślenie, lecz zestawianie. Sześćdziesiąt wymagań, dwieście przypadków testowych — i trzeba ustalić, co z czym jest powiązane. To właśnie tutaj model językowy oszczędza godziny, a nie udaje inteligencję.

Trzy techniki, które naprawdę działają.

Wstępne zestawienie. Dajesz modelowi listę wymagań i listę przypadków testowych, prosisz o powiązanie i zwrócenie dwóch tabel: co się zestawiło i co nie. Wartość jest w drugiej. To gotowa lista kandydatów na sieroty, którą ręcznie zbierałoby się pół dnia.

Rewizja specyfikacji. Prosisz o znalezienie wymagań bez źródła, duplikatów znaczeniowych oraz sformułowań, pod które nie da się napisać testu. Model czyta dokument w całości i nie męczy się przy czterdziestej stronie — w przeciwieństwie do człowieka.

Szkic analizy wpływu. „Zmieniamy FR-13, oto macierz — co jest objęte?” Na wyjściu lista kandydatów, którą sprawdzasz wzrokiem. Minuty zamiast korespondencji z trzema kolegami.

Dalej — czerwona linia, i jest ostrzejsza, niż się wydaje. Model potrafi wymyślić powiązanie, którego nie ma. Fałszywe powiązanie jest groźniejsze niż brak: pusta komórka jest widoczna i budzi pytanie, a błędna wygląda jak wykonana praca i nie budzi niczego. Dlatego zasada jest prosta: model proponuje — człowiek potwierdza. Do macierzy trafia tylko to, gdzie sam otworzyłeś wymaganie i test i przekonałeś się osobiście.

Dostawcy narzędzi do zarządzania wymaganiami wbudowali to jeszcze wcześniej: ich platformy proponują powiązania, oceniają pewność co do nich i oznaczają elementy niższego poziomu jako podejrzane, gdy zmienia się wymaganie wyższego poziomu. Nazwy i ceny bywają różne, zasada jest jedna.

I najważniejsze, co widuję najczęściej. Narzędzie się podłącza — i uważa, że trasowanie się pojawiło. Nie pojawiło się: pojawiło się repozytorium, w którym nic nie zostało rozstrzygnięte. Co trasujemy i do jakiego poziomu — to decyzja, której model za Ciebie nie podejmie.

Dlaczego trasuję nie tylko wymagania

Dalej osobista opinia, i jest szersza niż temat. Wartość trasowania nie tkwi w tabeli, lecz w nawyku zadawania dwóch pytań: skąd to się wzięło i jak poznam, że to zadziałało. Nawyku można użyć wszędzie.

Kurs, który robimy, jest zbudowany właśnie tak. Nie od ładnego spisu treści w dół, lecz oddolnie — od banku realnych pytań z rozmów kwalifikacyjnych. Każdy moduł jest trasowany do tego, ile pytań na niego przypada. Moduł, pod który pytań prawie nie ma, nie trafia do programu, choćby w obcych kursach wyglądał na obowiązkowy. To ta sama macierz: w górę — potrzeba, w dół — materiał.

Z artykułami jest tak samo. Mamy zasadę: temat bez realnego zapytania w wyszukiwarce na stronę nie idzie. Zapytanie jest zapisane w samym pliku artykułu — obok tekstu, a nie w czyjejś głowie. Ten artykuł też powstał pod konkretne zapytanie i za trzy miesiące będzie można otworzyć pomiar i sprawdzić, czy zadziałało. Pusta komórka „po co” znaczy tu to samo co w projekcie: pracę wykonywaną z rozpędu.

Dlatego na rozmowie kwalifikacyjnej bardziej wierzę kandydatowi, który trasuje cokolwiek, niż temu, kto z pamięci wylicza cztery typy powiązań. Pierwszy rozumie, po co to. Drugi przeczytał rozdział.

Jak to brzmi na rozmowie kwalifikacyjnej

Słaba odpowiedź — „tabela, gdzie wymagania są zestawione z testami”. Formalnie poprawnie, ale rozmowa dalej nie idzie.

Mocna jest krótsza, niż się wydaje: powiązanie w górę i w dół, jeden przykład z własnego projektu, cztery typy powiązań, jeśli zapytają głębiej. I osobno cenione jest szczere „w ostatnim projekcie nie prowadziliśmy jej, bo zespół był czteroosobowy i wszystko trzymało się w Jirze”. To odpowiedź praktyka, nie opowiadanie rozdziału.