Stosuj dwukierunkową identyfikowalność: połącz każde ważne wymaganie z decyzjami i komponentami, które je spełniają, a następnie komponenty z dowodami akceptacji. Powiązania odwrotne pokazują, dlaczego komponent istnieje i na jakie wymagania może wpłynąć planowana zmiana.
Mały, utrzymywany łańcuch
text
[Requirement R-12] --> [Decision D-04] --> [Refund workflow]
| |
+--> [Acceptance test T-18] <-----------+
|
[Test evidence]
Załóżmy, że R-12 wymaga, aby ponowienie tego samego żądania zwrotu pieniędzy nie tworzyło kolejnego zwrotu. D-04 wybiera stabilny identyfikator operacji biznesowej i wykrywanie duplikatów. Przepływ implementuje regułę. T-18 ponawia żądanie po zasymulowaniu utraty odpowiedzi i sprawdza, że nadal istnieje tylko jeden biznesowy zwrot środków.