BPMN odpowiada przede wszystkim na pytania „co dzieje się dalej, kto działa i kiedy?”. Wymagania opisują, co rozwiązanie ma umożliwiać, egzekwować lub zapewniać. Diagram nie zastępuje specyfikacji pól i reguł, a lista wymagań bez procesu nie pokazuje kolejności, odpowiedzialności i wyjątków. Łączy je śledzenie, nie kopiowanie tekstu.
Nadaj stabilne identyfikatory
Elementom istotnym dla wdrożenia nadaj identyfikatory, np. ACT-12 dla zadania, GW-04 dla decyzji, EVT-07 dla terminu. W opisie wymagania zapisuj powiązanie, nie sam numer na obrazku. Po zmianie układu graficznego relacja powinna nadal działać. Jeden element procesu może prowadzić do kilku wymagań, a jedno wymaganie — wspierać kilka kroków.
| Element BPMN | Pytanie analityczne | Typowy wynik |
|---|---|---|
| Start/message | Jak rozpoznać i zwalidować bodziec? | Wymaganie integracji i danych wejściowych |
| User task | Co użytkownik widzi, zmienia i zatwierdza? | Funkcja, uprawnienia, kryteria |
| Service task | Jakie wywołanie, retry i obsługa błędu? | Integracja i wymagania niezawodności |
| Bramka | Kto jest właścicielem reguły i jakie są granice? | Reguła biznesowa lub tabela decyzyjna |
| Timer | Jaki kalendarz i skutek terminu? | SLA, powiadomienie, eskalacja |
| Koniec | Jaki status, dane i komunikaty powstają? | Warunki końcowe i audyt |
Przypadek: wniosek o zwrot
Proces zawiera zadanie ACT-03 „Zweryfikuj prawo do zwrotu”, bramkę GW-02 „Czy termin zachowany?” i timer EVT-05 „14 dni na odesłanie”. Sam diagram nie mówi, od jakiej daty liczyć termin, co z dniem wolnym ani kto może wykonać ręczny wyjątek. Te informacje trafiły do reguł i wymagań.
| ID | Powiązanie | Treść/skutek | Kryterium |
|---|---|---|---|
| BR-09 | GW-02 | Termin liczony od potwierdzonego doręczenia | Wartości graniczne dzień 14 i 15 |
| REQ-31 | ACT-03 | System pokazuje dowody i wynik reguły | Operator widzi źródło daty |
| REQ-32 | GW-02 | Uprawniona rola może zaakceptować wyjątek z powodem | Decyzja trafia do audytu |
| NFR-07 | EVT-05 | Timer uwzględnia strefę czasu i kalendarz | Test zmiany czasu i dnia wolnego |
Workflow synchronizacji zmian
- Zwaliduj ścieżkę procesu na konkretnych przypadkach.
- Przy każdym elemencie zapisz reguły, dane, uprawnienia i wyjątki.
- Utwórz wymagania tylko tam, gdzie rozwiązanie ma odpowiedzialność.
- Połącz wymagania z kryteriami akceptacji i przypadkami testowymi.
- Przy zmianie uruchom analizę wpływu w obu kierunkach: proces → wymagania i wymaganie → proces.
Macierz śledzenia nie może być listą martwych linków
Połączenie powinno mieć typ: „realizuje”, „ogranicza”, „dostarcza dane”, „wywołuje” albo „jest weryfikowane przez”. Dzięki temu analiza wpływu jest precyzyjna. Zmiana timera wpływa na wymaganie SLA i eskalację, ale niekoniecznie na wygląd ekranu. Macierz warto filtrować po wersji procesu i statusie wymagania, aby nie mieszać stanu planowanego z wdrożonym.
| Źródło | Relacja | Cel | Test | Właściciel |
|---|---|---|---|---|
| ACT-03 | realizowane przez | REQ-31 | TC-31A/B | Product Owner |
| GW-02 | sterowane przez | BR-09 | DT-09 | Właściciel zwrotów |
| EVT-05 | ograniczone przez | NFR-07 | TC-TIME-04 | Operacje |
Wymagania niefunkcjonalne wynikające z przepływu
Proces ujawnia obciążenie, terminy i zależność od integracji, ale nie definiuje ich parametrów. Dla automatycznego zadania zbierz czas odpowiedzi, dostępność, retry, idempotencję i sposób degradacji. Dla user task ustal wolumen kolejki, równoczesność, audyt i dostępność interfejsu. Dla wiadomości określ korelację, duplikaty i kolejność. Te wymagania często decydują, czy poprawny logicznie proces zadziała w produkcji.
Analiza wpływu zmiany
Gdy biznes zmienia regułę GW-02, analityk wyszukuje powiązane wymagania, kryteria, testy, komunikaty, raporty i dane. Następnie przechodzi proces od wcześniejszej bramki do wszystkich zakończeń, ponieważ nowa ścieżka może zmienić status lub pracę ręczną. W drugą stronę, nowe wymaganie bez elementu procesu wymaga odpowiedzi: czy dotyczy pracy poza modelem, czy diagram jest niekompletny?
Czego nie wpisywać do diagramu
Nie upychaj w nazwie zadania walidacji pól, komunikatów, szczegółów interfejsu i wszystkich kryteriów. BPMN ma pozostać czytelny. Z drugiej strony wymaganie „system obsługuje proces zgodnie z BPMN” jest nieweryfikowalne: diagram może się zmienić, a jego symbole nie definiują pełnego zachowania systemu.
Warsztat przejścia od procesu do backlogu
Przejdźcie diagram ścieżka po ścieżce z biznesem, architektem, testerem i operacjami. Dla każdego kroku zapisujcie zachowanie systemu, dane, odpowiedzialność ręczną i pytania. Nie zamieniajcie każdego zadania w jedną historyjkę użytkownika — granice backlogu powinny dostarczać sprawdzalną wartość, a czasem obejmują kilka elementów procesu. Na końcu tester odtwarza wybrane scenariusze wyłącznie z kryteriów; brakujące decyzje wracają do właściciela.
Przykład scenariusza end-to-end
Dla zwrotu w 14. dniu tester rozpoczyna od wiadomości klienta, przechodzi walidację daty, pozytywną ścieżkę GW-02, utworzenie etykiety i timer na odesłanie. Kryteria wskazują dane, oczekiwane statusy i komunikaty w każdym punkcie. Ten jeden scenariusz łączy elementy procesu z regułą BR-09, funkcją REQ-31 i NFR-07. Jeśli kryterium opisuje tylko ekran, a nie końcowy rezultat sprawy, śledzenie jest niepełne.
Analogiczny scenariusz negatywny używa dnia 15, próby wyjątku przez nieuprawnioną rolę i awarii usługi etykiet. Pokazuje, czy proces ma obsługę odmowy, audyt oraz retry. Takie pionowe przypadki są lepszym sprawdzianem spójności niż osobne zatwierdzanie diagramu, wymagań i testów.
Checklista śledzenia
- Każdy automatyczny krok, interakcja, reguła i wyjątek ma pokrycie wymaganiami.
- Wymagania wskazują stabilny element procesu i cel biznesowy.
- Kryteria odtwarzają ścieżkę pozytywną, negatywną, timeout i błąd.
- Zmiana bramki lub terminu uruchamia analizę wpływu.
- Macierz nie zawiera osieroconych wymagań ani kroków systemowych bez specyfikacji.
Semantykę decyzji opisują bramki BPMN, a standard redakcji rozwija materiał jak napisać dobre wymaganie.
