Błędne wymaganie nie zawsze wygląda błędnie. Często jest krótkie, brzmi profesjonalnie i zostaje zaakceptowane, dopóki programista albo tester nie musi podjąć konkretnej decyzji. Wtedy brakujący warunek zostaje uzupełniony domysłem, a kilka domysłów tworzy kilka wersji produktu.
Poniższe antywzorce warto traktować jako sygnały do rozmowy. Nie chodzi o zastępowanie każdego zdania rozbudowaną specyfikacją, lecz o dodanie informacji proporcjonalnej do ryzyka.
Dziesięć antywzorców i sposób ich naprawy
1. Ogólnik bez obserwowalnego rezultatu
Źle: „System ma usprawniać obsługę reklamacji”. Lepiej: „Pracownik widzi w jednej kolejce reklamacje przypisane do jego zespołu, posortowane według terminu odpowiedzi, wraz z liczbą godzin pozostałych do SLA”. Pierwszy opis jest celem na poziomie hasła; drugi wskazuje użytkownika i zachowanie.
2. Przymiotnik zamiast miary
Źle: „Wyszukiwarka powinna działać szybko”. Lepiej: „Przy 100 równoległych użytkownikach 95% wyników dla zapytań do 50 znaków pojawia się w ciągu 2 sekund”. Słowa „szybko”, „łatwo” i „bezpiecznie” wymagają definicji osadzonej w warunkach.
3. Wiele zachowań w jednym worku
Źle: „System rejestruje klienta, weryfikuje dokumenty, podpisuje umowę i wysyła raport”. Taki zakres ma kilka aktorów, stanów i powodów błędu. Rozdziel go według rezultatów, zachowując wspólny proces i powiązania. Atomowość ułatwia priorytetyzację, lecz nie powinna usuwać kontekstu.
4. Brak warunku uruchamiającego
Źle: „System wysyła powiadomienie o płatności”. Kiedy — po utworzeniu, zaksięgowaniu czy terminie? Do kogo? Lepiej: „Po zaksięgowaniu pełnej kwoty system w ciągu 5 minut wysyła potwierdzenie na adres kontaktowy płatnika i zapisuje wynik wysyłki”.
5. Happy path bez wyjątków
Opis zakłada, że dane są pełne, integracja dostępna, a użytkownik ma uprawnienie. Największe koszty pojawiają się jednak na ścieżkach błędów. Nie trzeba opisywać każdego technicznego wyjątku biznesowo, lecz należy uzgodnić zachowanie widoczne dla użytkownika, stan danych i możliwość ponowienia.
6. Rozwiązanie podszywające się pod potrzebę
Źle: „Potrzebny jest chatbot do odpowiedzi o status przesyłki”. Najpierw ustal, kto nie otrzymuje informacji, jak często pyta i jakie źródło statusu jest wiarygodne. Chatbot może pozostać wariantem, ale równie skuteczne może być proaktywne powiadomienie. Zobacz też różnicę między potrzebą a rozwiązaniem.
7. Reguła bez źródła i właściciela
„Klient premium otrzymuje 15% rabatu” wygląda konkretnie, ale nie wiadomo, kto definiuje status premium, od kiedy reguła obowiązuje, z czym rabat się łączy i kto zatwierdza wyjątek. Reguły zmieniające pieniądze, uprawnienia lub zgodność muszą mieć właściciela oraz źródło.
8. Kryteria, które powtarzają wymaganie
Wymaganie: „Użytkownik eksportuje raport”. Kryterium: „Eksport raportu działa”. Nie dodaje to żadnej informacji. Kryteria powinny podać format, zakres danych, uprawnienia, rezultat przy pustym zbiorze i ważne limity. Praktyczne formaty znajdziesz w artykule jak opisać kryteria akceptacji.
9. Sprzeczność ukryta między dokumentami
User story mówi o anulowaniu do chwili wysyłki, regulamin do chwili spakowania, a testy do momentu płatności. Każdy zapis jest czytelny osobno. Problem ujawnia dopiero przegląd zestawu i wskazanie jednego źródła reguły. Duplikowanie treści zwiększa ryzyko rozjazdu.
10. Pozorna pewność
Brak informacji bywa maskowany kategorycznym zdaniem. Lepsze jest jawne „do potwierdzenia z właścicielem procesu do 14.06; bez odpowiedzi przyjmujemy wariant A i akceptujemy ryzyko X”. Założenie ma właściciela i termin, dzięki czemu nie staje się przypadkową decyzją.
Tabela szybkiej diagnozy
| Jeśli nie wiadomo… | Brakuje najczęściej… | Dodaj… |
|---|---|---|
| po co funkcja powstaje | źródła i celu | powiązanie z potrzebą |
| kiedy zachowanie występuje | zdarzenia lub warunku | stan początkowy i trigger |
| co zrobić przy błędzie | wyjątków | stan, komunikat i ścieżkę powrotu |
| czy wynik jest poprawny | kryteriów | przykłady i wartości graniczne |
| która wersja obowiązuje | zarządzania zmianą | ID, status i źródło prawdy |
Jak szukać błędów na przykładach, nie w próżni
Weź jedną rzeczywistą sprawę i przejdź przez nią chronologicznie. Przy każdym kroku zapytaj o aktora, dane, regułę, decyzję i zmianę stanu. Następnie zmień jeden warunek: brak danych, wartość graniczną, niewłaściwe uprawnienie albo niedostępność integracji. Obserwuj, czy opis nadal daje jednoznaczny wynik.
Drugą skuteczną techniką jest parafrazowanie. Niech właściciel biznesowy, programista i tester osobno powiedzą, co według nich ma zrobić system. Rozbieżność ujawnia lukę, nawet jeśli wszyscy wcześniej zaakceptowali to samo zdanie. Uzgodnioną odpowiedź zapisz w najwłaściwszej formie: regule, kryterium, modelu stanu lub przykładzie danych.
Na koniec sprawdź skutek w całym procesie. Poprawne lokalne wymaganie może pozostawić niemożliwy stan między systemami. Szczególnie uważaj na operacje finansowe, zmiany uprawnień i częściowe niepowodzenia. W tych obszarach pytanie „co zostaje zapisane, jeśli krok drugi zawiedzie?” powinno paść przed implementacją.
Checklista naprawcza
- Zastąp ogólniki obserwowalnym zachowaniem lub miernikiem.
- Rozdziel duże wymagania według wartości i rezultatu.
- Dodaj aktora, zdarzenie oraz warunek zastosowania.
- Przejdź przez błąd, brak danych, granicę i ponowienie.
- Oznacz rozwiązania jako warianty, jeśli nie są ograniczeniem.
- Przypisz źródło i właściciela reguł.
- Przepisz kryteria, które jedynie powtarzają tytuł.
- Usuń duplikaty i wskaż jedno źródło obowiązujące.
- Zamień ukryte braki na jawne pytania z terminem.
Warto budować krótką bibliotekę naprawionych przykładów z własnej domeny. Zanonimizowane zestawienie „przed, pytania, po” pomaga nowym osobom rozpoznać oczekiwany poziom lepiej niż abstrakcyjna definicja jakości. Przeglądaj bibliotekę okresowo, aby nie utrwalała nieaktualnych reguł, formatów ani błędnych skrótów myślowych.
Po poprawkach przeprowadź przegląd jakości wymagania. Jeśli błędy wracają z powodu wersji i kopii, uporządkuj cały proces zgodnie z poradnikiem jak uniknąć chaosu w wymaganiach.
