Odpowiedź.

Historia pytania:

Początkowo w projektach IT analitycy systemowi koncentrowali się głównie na wymaganiach biznesowych, a ograniczenia techniczne były przekazywane lub ignorowane, co prowadziło do nieefektywnych lub zbyt drogich rozwiązań.

Problem:

Ograniczenia techniczne nie zawsze są deklarowane – klient może o nich nie wiedzieć, a zespół deweloperski może ich nie uwzględnić, co skutkuje niezgodnością z możliwościami infrastruktury lub systemów integracyjnych.

Rozwiązanie:

Analityk systemowy aktywnie przeprowadza rozmowy z architektami, DevOps, QA, integratorami:

• Określa stosy technologiczne, zależności biznesowe i infrastrukturalne.
• Uzgadnia wymagania z zasadami architektonicznymi: SLA, odporność na awarie, skalowalność, ograniczenia licencyjne lub bezpieczeństwa.
• Rejestruje i weryfikuje kompromisy między możliwościami a oczekiwaniami biznesu.
• Stosuje podejścia „analiza oparta na scenariuszu” oraz „wymagania niefunkcjonalne”.

Kluczowe cechy:

• Wczesne rejestrowanie ograniczeń i zależności ze wszystkimi odpowiedzialnymi.
• Dokumentowanie kompromisów i niejawnych ograniczeń.
• Ciągłe porównywanie rozwiązań projektowych z architekturą firmy.

Pytania z pułapką.

Czy można ignorować niejawne ograniczenia techniczne, jeśli nie są one wymienione wprost?

Prawda: Nie. Niejawne ograniczenia techniczne (np. czasy oczekiwania integracji, limity rozmiaru wiadomości) zawsze wymagają analizy i rejestracji, nawet jeśli nie są jasno określone.

Czy analityk powinien uczestniczyć w rozmowach/ warsztatach architektonicznych?

Prawda: Tak, analityk systemowy jest ogniwem łączącym biznes z architektami, przekazuje wymagania obu stronom i rejestruje rozwiązania.

Czy wystarczy tylko zebrać wymagania biznesowe i nie analizować dziedzicznych ograniczeń?

Prawda: Nie wystarczy. Dziedziczony kod, licencje, integracje (legacy) czasami narzucają więcej ograniczeń niż jawnie zadane wymagania.

Typowe błędy i antywzorce

• Niedocenianie ukrytych ograniczeń i zależności starych systemów.
• Ignorowanie „niepisanych” zasad architektury.
• Rejestracja tylko części biznesowej bez uwzględnienia wykonalności technicznej.

Przykład z życia

Negatywny przypadek: Analityk zarejestrował integrację według procesu biznesowego, ale nie ustalił ograniczeń prędkości przesyłania danych w interfejsie.

Zalety: Szybka realizacja specyfikacji. Wady: System nie wytrzymał obciążenia, biznes stracił pieniądze i czas.

Pozytywny przypadek: Analityk uczestniczył w sesjach architektonicznych, zidentyfikował ograniczenia (maksymalna liczba wątków = 100, integracja 1 raz na 10 sekund), uzgodnił z biznesem ograniczenia.

Zalety: Działające rozwiązanie, stabilna integracja. Wady: Konieczność kompromisowego ograniczenia funkcjonalności i uzasadnienia tego klientowi.