To niebywałe, jak proste metody mogą być zaskakująco skuteczne!
W tym artykule pokażę Ci jak krok po kroku wdrożyć proces przeglądu specyfikacji wymagań oprogramowania.
Proces, którego oczekiwane ROI jest na poziomie min. 10:11.
Zaczynamy?
Cel – dlaczego warto testować specyfikację wymagań oprogramowania?
Celem przedstawionego procesu jest trwałe podniesienie jakości dokumentacji. Nie chodzi wyłącznie o testowanie, ale przede wszystkim o zapobieganie pojawianiu się podobnych błędów w przyszłości.
Wdrożenie tego procesu powinno zająć nie więcej niż 1 dzień pracy kilku osób. Taki będzie koszt.
A zyski?
Spójrz na poniższy wykres2
Według badań przeprowadzonych w NASA, koszty wprowadzenia zmiany na etapie developmentu to od 20 do 100 razy tyle, ile kosztuje ta sama zmiana na etapie budowania koncepcji.
Wprowadzenie tej zmiany w trakcie testów czy utrzymania, to nawet 1000 razy więcej.

Być może więc inwestycja w ten proces zwróci się już po wykryciu pierwszego błędu w specyfikacji.
Kroki procesu przeglądu specyfikacji wymagań oprogramowania
Poniższa checklista wraz z arkuszem do wprowadzania wyników znajduje się na stronie z materiałami do pobrania
1. Ustal cel przeglądu
Celem procesu kontroli jakości specyfikacji wymagań oprogramowania jest oczywiście poprawa tej jakości. Co to dokładnie znaczy?
Ustal kryteria dotyczące maksymalnej akceptowalnej liczby błędów na 1 stronę tekstu.
Np. kontrola musi wykazać mniej niż 1 krytyczny błąd na stronę (średnio), aby uznać proces za zakończony z sukcesem.
2. Wybierz dokument
Zacznij na małą skalę. Wybierz jeden dokument. Im bardziej typowy, tym lepiej.
Jeżeli chcesz aktywnie brać udział w tym procesie, to nie wybieraj własnej specyfikacji wymagań.
3. Wybierz zawartość (losowo)
Wybierz losowo fragment dokumentu, który będzie podlegał kontroli. Mogą to być nawet 3 strony i raczej nie więcej niż 10, gdyż bardzo ciężko utrzymać skupienie na przeglądzie przez długi czas.
Ważne, aby ten fragment zawierał głównie treść, a nie diagramy.
4. Ustal kryteria przeglądu
Ustal kategorie błędów. Na przykład:
- cel przeglądu: niejednoznaczne wyrażenia,
- poza zakresem przeglądu: błędy logiki biznesowej (nie inwestujemy czasu w pełną analizę),
- itd.
Podobnie ustal priorytety błędów, przykładowo:
- błąd krytyczny – niejednoznaczność, której zmiana po wdrożeniu zajmie min. 1 dzień pracy programistycznej,
- błąd pomijalny – niejednoznaczność, której zmiana po wdrożeniu może zostać wykonana w mniej niż 1 godzinę, bez ryzyka wygenerowania nowych błędów (np. zmiana koloru)
5. Wybierz osoby i ustal role
Jeżeli tylko masz możliwość, to na potrzeby przeglądu zbuduj zespół z kilku osób (2-5) z podziałem na role:
- koordynator procesu – ktoś, kto wdraża kroki z tej listy
- przeglądający – osoba zgłaszająca błędy w specyfikacji
- analityk – ktoś, kto zbierze i przeanalizuje wyniki
6. Wykonaj przegląd specyfikacji wymagań oprogramowania
Każdy z przeglądających analizuje dokument i raportuje błędy z podziałem na kategorie. Możesz skorzystać z wspomnianego szablonu.
Dopisuj do zgłoszeń obszar, którego dotyczą, oraz możliwą przyczynę powstania błędu.
7. Zbierz i opracuj wyniki
Analityk zbiera wyniki do jednego dokumentu, a następnie:
- potwierdza ważność zgłoszeń (priorytety)
- grupuje zgłoszenia według kategorii (użyteczność, wydajność itp.)
- szacuje liczbę błędów w całym dokumencie:
- mnoży średni wynik przez liczbę stron,
- zakłada, że część błędów mogła być niezauważona (np. +20% – wynik do wypracowania w miarę zdobywania doświadczenia)
- oblicza potencjalny koszt pozostawienia dokumentacji w aktualnym stanie:
- uwzględnia, że tylko część błędów wróci do naprawy (np. 50% – do przeanalizowania na podstawie wcześniejszych doświadczeń, np. zwrotek w systemie ticketowym),
- przelicza tę liczbę przez średni koszt naprawy błędu na etapie końcowych testów,
- przedstawia te wyniki koordynatorowi, który podejmuje dalsze decyzje.
8. Zdefiniuj i wdróż działania naprawcze
Na podstawie wyniku z testów specyfikacji wymagań oprogramowania wdróż proaktywne działania naprawcze.
- skoncentruj wysiłek na tych obszarach, które mają największą liczbę krytycznych błędów,
- szukaj rozwiązań długofalowych, które wyeliminują przyczynę powstawania błędów, takich jak:
- zorganizuj szkolenie pomagające zrozumieć dany temat, co przełoży się na precyzyjniejsze wymagania,
- przygotuj checklisty do wykorzystania w każdym projekcie,
- opracuj FAQ dla krytycznych zagadnień,
- stwórz gotowe do użycia szablony,
- itp.
- pamiętaj o ROI, czyli żeby koszty tych działań nie przewyższyły spodziewanych korzyści.
9. Powtarzaj aż do osiągnięcia celu z pkt. 1
Zwróć dokument do poprawy. Oczekuj poprawy całości, nie tylko wybranych stron.
Powtórz cały proces po otrzymaniu kolejnej wersji specyfikacji wymagań oprogramowania. Najlepiej wybierz losowo inny zestaw stron dokumentu.
Testuj tak długo, aż cel założony w pkt 1 nie zostanie osiągnięty, lub gdy kontynuowanie procesu przestanie być opłacalne.
10. Oblicz efektywność procesu
Po osiągnięciu celu podsumuj wyniki:
- liczbę błędów z pierwszego i ostatniego przeglądu,
- zaoszczędzone koszty, dzięki wczesnemu wykryciu błędów,
- nakład pracy na działania związane z przeglądami (czas, koszt),
- efektywność kosztowa – jaki był zysk/strata z inwestycji w ten proces.
Zacznij działać – droga do poprawy specyfikacji wymagań oprogramowania
Zrób pierwszy krok, żeby przekonać się czy to działa.
1. Pobierz checklistę ze strony z materiałami (nr 4 na liście).
2. Wykonaj przegląd przy minimalnych możliwych kosztach.
3. Sprawdź wyniki.
Jaki uzyskałeś wynik?
Moja działania w zakresie pracy ze specyfikacją wymagań są inspirowane publikacjami Toma Gilba, „Value Planning” oraz „Competitive Engineering”
1 Tom Gilb, „Competitive Engineering”, str. 246
2 NASA „Systems Engineering Handbook„, https://www.nasa.gov/seh/2-5-cost-effectiveness-considerations, rozdz. 2.5