Łatwo jednak zauważyć, że ograniczanie się jedynie do łączenia przypadku testowego z wymaganiem jest marnowaniem dobrze rozpoczętej pracy. Jeśli przypadki są linkowane, to czemu nie zrobić tego samego dla implementacji czy dla błędów? Powstała więc koncepcja Śledzalności Plus oznaczająca, że każdy element wytworzony w ramach projektu jest łączony z elementem, z którego się wywodzi.

Śledzimy projekt

Nazwa "śledzalność" nie została dobrana przypadkowo. Celem w zarządzaniu projektem jest informacja i szybki jej przepływ. Przeanalizujmy więc w modelu Plus przepływ modyfikowanego wymagania. Załóżmy, że klient po otrzymaniu wersji 0.1 oprogramowania przypomniał sobie, że w specyfikacji brakuje ważnego wymagania. Pojawia się więc z jego strony nowe wymaganie W1’. Zanim zmiana zostanie zaakceptowana lub odrzucona, musi zostać wyceniony koszt zmian. Wprowadzenie zmiany do systemu informatycznego wspierającego Śledzalność Plus powoduje, że przy każdym powiązanym z danym wymaganiem elemencie i półprodukcie pojawia się konieczność oszacowania wpływu zmiany na czasowość dostaw oraz na budżet. Tak jak koderzy muszą sprawdzić, ile linii kodu musi zostać napisanych lub zmodyfikowanych, tak samo testerzy muszą zweryfikować, jak dużo nowych przypadków należy napisać i jak dużo starszych przerobić. Uwzględnienie tych etapów zarządzania projektem umożliwia ocenę kosztów. Zbyt duży koszt zmiany może skutkować odrzuceniem zmiany lub renegocjacją kontraktu.

Jeśli jednak dojdzie do akceptacji zmiany, cały projekt informatyczny zmuszony jest do dostosowania się do nowego wymagania. Obieg informacji nie jest jednak w modelu wymuszany z wielu miejsc, a jedynie z jednego. Oszczędza to czas i nakłady na manualne zarządzanie projektem. Zmiana wymagania wymusi np. zmianę implementacji. Może to również oznaczać, że coś, co do tej pory uważane było za defekt, już tym defektem nie jest i zgłoszenie powinno zostać sprawdzone i zamknięte.

Należy także pamiętać, że wymagania stanowią podstawę do tworzenia szeregu dokumentów projektowych. Powinno zatem zostać sprawdzone, czy zmiany mają wpływ na wymagania. Jeśli zmiana wymusza modyfikację dokumentacji, to zmiany w specyfikacji również muszą być odpowiednio zakomunikowane i rozpropagowane w projekcie.

Zalety i wady narzędzia

Wydaje się, że taki model może przynieść jedynie korzyści. Niestety obecnie wdrożenie pełnej śledzalności projektów wymaga zakupu narzędzi od tego samego dostawcy, ponadto są to narzędzia klasy enterprise, z najwyższej półki cenowej. Tylko takie narzędzia gwarantują łatwą integrację i wielokierunkową wymianę informacji. Sam zakup narzędzia nie rozwiązuje problemu, gdyż niezbędne jest prawidłowe jego wdrożenie. Wydatek plus ryzyko nieumiejętnej implementacji narzędzia w organizacji może przełożyć się na straty zamiast korzyści.

Najlepszym rozwiązaniem staje się samodzielna implementacja takiego rozwiązania przy wykorzystaniu narzędzi dostępnych w organizacji. Projekt informatyczny nie musi być tutaj wielki, wystarczy pozbierać dostępne narzędzia do zarządzania wymaganiami, testowaniem, konfiguracją, wersjonowaniem i kodowaniem, i stworzyć platformę komunikacji między nimi. Zbudowanie takiego ekosystemu jest znacznie łatwiejsze, gdy narzędzia są budowane w modelu open source i pochodzą z takich projektów, o wiele trudniej zintegrować kupowane narzędzia od HP, IBM-u czy Microsoftu.