W celu wprowadzenia pytania stosowanego podczas przeglądu składników należy użyć atrybutu Pytanie. Pytanie należy zapisać tak, aby odpowiedź Tak wskazywała na zatwierdzenie składnika. Przeglądając różne typy składników, takie jak wymagania, przypadki użycia, instrukcje testowania i raporty błędów, można użyć następujących punktów kontrolnych.
Nazwa | Pytanie |
---|---|
Unikalność | Czy tytuł i identyfikator wymagania są unikalne? |
Zrozumiałość | Czy czytelnicy rozumieją wymagania? |
Nadmiarowość | Czy wymaganie jest pozbawione niepotrzebnych informacji? |
Kompletność | Czy wszystkie atrybuty są kompletne? |
Niejednoznaczność | Czy wymaganie jest jasno wyrażone? |
Spójność | Czy wymaganie jest pozbawione sprzeczności z innymi wymaganiami i ogólnymi wymaganiami systemowymi? |
Organizacja | Czy wymaganie jest na poprawnym poziomie hierarchicznym? |
Śledzenie | Czy wymaganie ma wymaganie źródłowe i wymaganie docelowe? |
Testowalność | Czy można zweryfikować spełnienie wymagania poprzez test, demonstrację, przegląd lub analizę? |
Odpowiedzialność | Czy osoba odpowiedzialna za wymaganie została określona? |
Język | Czy wymaganie jest pozbawione błędów gramatycznych i słów, które trudno zweryfikować, np. często, co najmniej i czasami? |
Typ | Czy wymaganie jest wymaganiem, a nie rozwiązaniem konstrukcyjnym lub wdrożeniowym? |
Duplikaty | Czy znaczenie wymagania jest unikalne? |
Dzielenie | Czy w tym wymaganiu określono jedną, dobrze zdefiniowaną potrzebę? |
Grupowanie | Czy jest to autonomiczne wymaganie? |
Zakres | Czy wymaganie mieści się w zakresie projektu? |
Wydajność | Czy określono cel wydajnościowy wymagania? |
Odniesienie | Czy odniesienia wymagania są poprawne? |
Zależność | Jeśli wymaganie jest zależne od innych wymagań, to czy te zależności zostały wyraźnie określone? |
Nazwa | Pytanie |
---|---|
Odrębność | Czy przypadek użycia jest autonomicznym, odrębnym zadaniem? |
Cel | Czy cel (lub mierzalna wartość) przypadku użycia jest jasny? |
Aktor | Czy określono aktorów, którym przypadek użycia przyniesie korzyść? |
Poziom | Czy przypadek użycia został napisany na poziomie zasadniczym (abstrakcyjnym), a nie jako konkretny scenariusz? |
Typ | Czy przypadek użycia zawiera szczegóły projektu i implementacji? |
Kompletność kursu | Czy wszystkie oczekiwane alternatywne kursy zostały udokumentowane? |
Wyjątki | Czy wszystkie znane warunki wyjątków zostały udokumentowane? |
Dzielenie | Czy istnieją wspólne sekwencje działań, które można podzielić na oddzielne przypadki użycia? |
Niejednoznaczność | Czy sekwencja dialogu dla każdego kursu została napisana w sposób wyraźny, jednoznaczny i kompletny? |
Istotność | Czy każdy aktor i krok przypadku użycia jest istotny dla wykonania zadania? |
Wykonalność kursu | Czy kursy zdefiniowane w przypadku użycia są wykonalne? |
Weryfikowalność kursu | Czy kursy zdefiniowane w przypadku użycia są weryfikowalne? |
Nazwa | Pytanie |
---|---|
Wejście i wyjście | Czy instrukcja testowania zawiera pełny opis oczekiwanych danych wejściowych i wyjściowych? |
Odniesienie | Czy wszystkie zależności przypadku testowego zostały opisane? |
Duplikaty | Czy warunek jest testowany tylko jeden raz? |
Kompletność | Czy przypadek testowy jest kompletny? |
Niejednoznaczność | Czy przypadek testowy jest pozbawiony niejednoznaczności? |
Odtwarzalność | Czy przypadek testowy jest odtwarzalny? |
Konstrukcja | Czy przypadek testowy został skonstruowany tak, aby pokazywać obecność awarii, a nie brak awarii? |
Nazwa | Pytanie |
---|---|
Zrozumiałość | Czy czytelnicy rozumieją raport błędów? |
Kompletność | Czy wszystkie atrybuty są kompletne? |
Niejednoznaczność | Czy raport błędów jest jasno wyrażony? |
Duplikaty | Czy istnieje duplikat raportu błędów? |
Odtwarzalność | Czy błąd zawarty w raporcie błędów można odtworzyć? |