„System ma być szybki, bezpieczny i łatwy do zmiany” brzmi dobrze, ale nie prowadzi jeszcze do projektu ani testu. Scenariusz atrybutu jakościowego zamienia taki przymiotnik w obserwowalne zachowanie: opisuje źródło bodźca, bodziec, środowisko, element systemu, oczekiwaną reakcję i jej mierzalną wartość.

Sześć części dobrego scenariusza

  1. Źródło bodźca: kto lub co wywołuje sytuację — użytkownik, operator, inny system albo awaria.
  2. Bodziec: konkretne zdarzenie, np. wzrost ruchu, niedostępność zależności lub potrzeba zmiany reguły.
  3. Środowisko: warunki, w których zdarzenie występuje — normalna praca, szczyt, wdrożenie albo odtwarzanie po awarii.
  4. Artefakt: część systemu, której dotyczy scenariusz.
  5. Reakcja: zachowanie systemu po bodźcu.
  6. Miara reakcji: próg, po którym można stwierdzić, czy wymaganie zostało spełnione.
Przykład fikcyjny — modyfikowalność: gdy zespół podczas normalnego cyklu wydania zmienia nazwę i zestaw wartości pola używanego przez dwie wersje aplikacji, system pozwala wdrożyć kompatybilny etap pośredni i wycofać kod bez utraty zapisów; migracja nie wymaga przerwy, a rozbieżności danych pozostają równe zero w uzgodnionym oknie obserwacji.

Dlaczego sama nazwa jakości nie wystarcza?

Dwie osoby mogą rozumieć „wysoką dostępność” zupełnie inaczej. Dla jednej oznacza dostępność pojedynczego API, dla drugiej zakończenie całej ścieżki klienta. Scenariusz ujawnia różnicę przed wyborem technologii. Pomaga też znaleźć konflikt: szybsza zmiana może wymagać okresu podwójnej obsługi kontraktu, a niższy koszt może ograniczyć redundancję.

ISO/IEC 25010:2023 dostarcza model cech jakości produktu, ale katalog cech nie zastępuje wymagań konkretnego systemu. Materiały Software Engineering Institute pokazują pracę ze scenariuszami podczas warsztatu atrybutów jakościowych: interesariusze tworzą i priorytetyzują sytuacje związane z bodźcem, środowiskiem i reakcją.

Jak użyć scenariusza przy decyzji architektonicznej?

  1. Zacznij od zdarzenia istotnego dla interesariusza, nie od produktu lub wzorca.
  2. Ustal środowisko i miarę. „95% odpowiedzi poniżej 300 ms przy 500 żądaniach na sekundę” jest innym problemem niż ta sama wartość bez opisu obciążenia.
  3. Porównaj warianty według reakcji i kosztu. W ADR zapisz, które scenariusze wspierają decyzję i jakie kompromisy pozostają.
  4. Zamień miarę w test, obserwację produkcyjną albo ćwiczenie awarii. Jeżeli nie wiadomo, jak sprawdzić wynik, scenariusz nadal jest zbyt ogólny.
Fragment przykładowego ADR: Kontekst: wdrożenie kroczące powoduje współistnienie dwóch wersji aplikacji. Scenariusz jakościowy: po zmianie schematu stara i nowa wersja przetwarzają poprawnie ruch, a rollback kodu nie traci danych. Decyzja: używamy etapów rozszerz–migruj–zwęź. Weryfikacja: test mieszanych wersji, kontrola brakujących wartości i próba rollbacku przed usunięciem starego pola.

Pytanie do projektu: które trzy sytuacje — szczyt ruchu, awaria zależności, zmiana kontraktu, incydent bezpieczeństwa lub odtwarzanie — naprawdę kształtują Waszą architekturę i jaką miarą je ocenicie?

Źródła: Software Engineering Institute — Quality Attribute Workshop Collection; ISO/IEC 25010:2023 — Product quality model. Przykłady systemu, wartości i ADR są autorskie i fikcyjne.