Liczba defektów na wymaganie
Ten raport pokazuje związek pomiędzy defektami a wymaganiami projektu. Większa liczba defektów dotyczących niektórych wymagań może wskazywać na problemy ze specyfikacją, projektem lub implementacją tego wymagania. Może też pomóc w podjęciu decyzji o pominięciu wymagania powiązanego ze zbyt wieloma defektami, jeśli wymaganie to ma niski priorytet. Analogicznie, defekty wymagania o wysokim priorytecie mogą uzasadniać przeniesienie zasobów z pracy o niższym priorytecie.
Gotowość wersji (wymaganie)
Ten wykres pokazuje liczbę wymagań ze statusem "Approved" (zatwierdzone) lub "Proposed" (proponowane) w rozbiciu na priorytety i dla każdego typu wymagania. Wymagania z tymi wartościami statusu są uznawane za nie w pełni zaimplementowane. Przedstawiona liczba wymagań powinna maleć wraz z postępem pracy w projekcie. Jeśli liczba niezaimplementowanych wymagań (zwłaszcza tych z priorytetem ="Must", konieczny) nie maleje do zera pod koniec projektu, to projekt może nie być gotowy do wydania wersji, gdyż nie zaimplementowano wszystkich jego wymagań.
Przekazywanie wymagań
Ten raport pokazuje, jak wiele wymagań zostało zaimplementowanych i jak wiele pozostaje do wykonania. Liczba zaimplementowanych wymagań powinna być mała na początku i rosnąć wraz z upływem czasu, natomiast liczba pozostałych wymagań powinna się obniżać. Zbyt dużo niezakończonych wymagań w późniejszej fazie projektu może wskazywać na problem.
Lista wymagań
Ten raport zawiera wybrane szczegóły dla każdego wymagania.
Zmienność wymagań
Zbiór względnie stabilnych wymagań ułatwia realizację każdego projektu. Jednak wymagania zmieniają się w trakcie projektu. W zarządzaniu projektem istotne jest rozpoznanie ilości zmian. Zasadniczo zajmowanie się zmianami jest łatwiejsze na początku projektu, a więc poszukaj linii, które mają się obniżać z biegiem czasu. Linia wznosząca lub duża liczba zmian w późniejszej części projektu może oznaczać problemy.
Rozkład wymagań
Ten raport pokazuje liczbę wymagań dla każdego statusu, priorytetu i stabilności. Wraz z postępem projektu liczba początkowych statusów, jak np. "Proposed" (proponowane), powinna maleć, a liczba późniejszych statusów, jak np. "Incorporated" (dołączone), powinna wzrastać. W przeciwnym razie niektóre wymagania mogą nie zostać spełnione. Należy szukać sensownego rozkładu według priorytetu i stabilności. Nie wszystko może mieć wysoki priorytet, a zbyt wiele niskiej stabilności może wskazywać na problem.
Macierz śledzenia wymagań
Ten raport przedstawia wymagania z IBM Rational RequisitePro w rozbiciu na typy. Dla każdego wymagania wyświetlane są pokrewne wymagania i działania.
Wymaganie i pokrewne działania UCM
Ten wykres pokazuje, jak wiele pracy jest wykonywanej dla każdego wymagania. Należy szukać wymagań, które mają znacznie wyższe lub niższe wartości od oczekiwanych lub w porównaniu z innymi wymaganiami. Może to wynikać ze względnej trudności pracy bądź wskazywać, że praca została źle oszacowana lub nie jest wykonywana efektywnie.