Diagram kontekstowy: jak zdefiniować zakres systemu

Najdroższe zdanie w projekcie: „myślałem, że to też robimy"

To zdanie prawie nigdy nie pada na warsztacie wymagań. Pada na demo, na UAT albo tydzień przed wdrożeniem, kiedy klient pyta, gdzie jest import danych z systemu księgowego, a zespół patrzy po sobie w ciszy. Widziałem ten moment kilka razy i za każdym razem wyglądał tak samo: nikt nie skłamał, nikt nie zawalił. Po prostu każdy miał w głowie inną granicę systemu.

Klient zakładał, że „system obsługi zgłoszeń" obejmuje też fakturowanie napraw. Zespół zakładał, że fakturowanie robi księgowość w swoim narzędziu. Obie strony podpisały ten sam dokument wymagań i obie miały rację we własnej interpretacji. Koszt takiej rozbieżności to tygodnie pracy, awaryjne integracje i rozmowy o tym, kto zapłaci za zmianę.

Najtańsza polisa przeciwko temu scenariuszowi to jeden rysunek, który mieści się na kartce A4 i powstaje w pół godziny. Diagram kontekstowy.

Czym jest diagram kontekstowy: system, aktorzy zewnętrzni, przepływy informacji

Diagram kontekstowy pokazuje system jako czarną skrzynkę i odpowiada na jedno pytanie: co jest w środku, a co na zewnątrz. W BABOK znajdziesz go w technice modelowania zakresu (Scope Modelling) i jako najwyższy poziom diagramów przepływu danych.

Składa się z trzech elementów. Tylko trzech:

• System - jeden kształt na środku (koło lub prostokąt) z nazwą. Bez procesów, bez modułów, bez ekranów. Wnętrze Cię na tym etapie nie obchodzi.
• Aktorzy zewnętrzni (external entities) - ludzie, systemy i organizacje, które wymieniają informacje z Twoim systemem, ale są poza jego granicą. Klient, serwisant, ERP, bramka SMS, urząd skarbowy.
• Przepływy informacji - strzałki między aktorami a systemem, podpisane nazwą danych, które płyną. „Zgłoszenie awarii", „status naprawy", „dane do faktury".

I równie ważne jest to, czego na diagramie kontekstowym NIE ma. Nie ma procesów wewnętrznych. Nie ma magazynów danych. Nie ma przepływów między samymi aktorami (to, że klient dzwoni do serwisanta prywatnie, nie dotyczy Twojego systemu). Jeśli coś nie przecina granicy systemu, nie należy do tego rysunku.

Siła tej techniki bierze się właśnie z ubóstwa notacji. Dyrektor finansowy, magazynier i architekt rozumieją ten sam rysunek bez szkolenia. Spróbuj tego samego z diagramem klas.

Jak go narysować w 30 minut - notacja i kolejność kroków

Nie potrzebujesz specjalnego narzędzia. Flipchart na warsztacie działa lepiej niż draw.io, bo ludzie dorysowują rzeczy sami. Kolejność kroków:

1. Nazwij system i narysuj go na środku (2 min). Jedna nazwa, jeden kształt. Jeśli zespół nie umie się zgodzić na nazwę, to pierwszy sygnał, że każdy buduje coś innego.

2. Wypisz kandydatów na aktorów (8 min). Burza pytań: kto korzysta z systemu? Jakie systemy dostarczają mu dane? Komu on wysyła dane? Kto dostaje z niego raporty? Jakie instytucje zewnętrzne są w grze (bank, GUS, operator płatności)? Wypisuj wszystko, filtrowanie przyjdzie za chwilę.

3. Dla każdego aktora dorysuj strzałki (10 min). Pytasz dwukrotnie: co ten aktor wysyła DO systemu i co dostaje OD systemu. Aktor bez ani jednej strzałki wylatuje - skoro nic nie wymienia, nie jest aktorem tego systemu.

4. Podpisz każdą strzałkę rzeczownikiem (5 min). „Zgłoszenie", „potwierdzenie wydania części", „raport miesięczny". Nie czasownikiem („wysyła", „loguje się") - strzałka opisuje dane, nie czynność. Jeśli nie umiesz nazwać danych na strzałce, to znaczy, że nie wiesz, co naprawdę płynie. Dobra wiadomość: właśnie znalazłeś pytanie do interesariusza, zanim znalazł je programista w połowie sprintu.

5. Zrób przegląd granicy (5 min). Przejdź strzałka po strzałce i zapytaj: czy to na pewno przecina granicę? Czy „moduł raportów" to aktor zewnętrzny, czy część systemu, która przypadkiem wylądowała na zewnątrz? Tu wychodzą pierwsze nieporozumienia i to jest dokładnie ten moment, w którym chcesz je mieć.

Pół godziny. Rysunek nie musi być ładny, musi być kompletny na poziomie granicy.

Diagram kontekstowy a DFD poziomu 0

Te dwa pojęcia bywają używane zamiennie i stąd sporo zamieszania. W klasycznej notacji Yourdona diagram kontekstowy to najwyższy poziom diagramu przepływu danych: cały system jako jeden proces. Kolejny poziom w dół rozbija tę bańkę na kilka głównych procesów i dokłada magazyny danych - ten poziom część zespołów nazywa „poziomem 0", a część „poziomem 1". Nazewnictwo bywa różne między firmami, mechanika jest ta sama.

Praktyczna różnica jest prosta:

• Diagram kontekstowy odpowiada na pytanie „co jest w zakresie". Robisz go na początku, z biznesem, na jednej kartce.
• DFD niższych poziomów odpowiadają na pytanie „jak dane płyną w środku". Robisz je później, kiedy zakres jest już uzgodniony i schodzisz w szczegóły przetwarzania.

Jeśli chcesz zejść poziom niżej i rozpisać wnętrze systemu na procesy oraz magazyny danych, cały warsztat DFD opisałem osobno: diagramy przepływu danych krok po kroku. Kolejność zawsze ta sama: najpierw kontekst, potem dekompozycja. Nigdy odwrotnie, bo rozpisywanie wnętrza systemu o niedomkniętej granicy to proszenie się o przerabianie wszystkiego od nowa.

In scope / out of scope: lista wykluczeń jako tarcza przed rozrostem zakresu

Sam rysunek to połowa roboty. Druga połowa to lista wykluczeń, którą dopisujesz pod diagramem. Brzmi banalnie, a robi więcej dla spokoju projektu niż niejeden dokument na 40 stron.

Mechanizm jest taki: diagram pokazuje, co JEST w zakresie. Ale ludzie zgłaszają pretensje o rzeczy, których na rysunku nie ma, bo „przecież było oczywiste, że to też". Dlatego wszystko, co padło w rozmowach jako kandydat i zostało świadomie odrzucone, ląduje na jawnej liście:

POZA ZAKRESEM (uzgodniono z: ..., data: ...)
1. Fakturowanie napraw - pozostaje w systemie księgowym
2. Zarządzanie stanami magazynowymi - pozostaje w ERP
3. Grafik pracy serwisantów - pozostaje w narzędziu HR
4. Portal wiedzy dla klientów - odrębna inicjatywa

Każda pozycja ma właściciela decyzji i wskazanie, gdzie ta funkcja żyje zamiast tego. Kiedy trzy miesiące później ktoś na spotkaniu rzuca „a fakturowanie to kiedy dowieziecie", nie zaczynasz dyskusji od zera. Otwierasz listę, pokazujesz punkt 1 i nazwisko osoby, która to potwierdziła. Rozmowa o rozszerzeniu zakresu dalej może się odbyć, ale jako świadoma decyzja o zmianie, z wyceną, a nie jako pretensja o „brak".

Z mojego doświadczenia lista wykluczeń jest czytana częściej niż sam diagram. Ludzie rzadko kwestionują to, co system robi. Awantury są o to, czego nie robi.

Przykład: kontekst systemu obsługi zgłoszeń serwisowych, element po elemencie

Weźmy System Obsługi Zgłoszeń (SOZ) dla firmy serwisującej sprzęt. Na środku kartki jedno koło z napisem „SOZ". Dookoła:

Klient (człowiek)

• do systemu: zgłoszenie awarii, ocena wykonanej naprawy
• z systemu: potwierdzenie przyjęcia, status zgłoszenia

Serwisant (człowiek)

• z systemu: przydzielone zlecenie z opisem i adresem
• do systemu: raport z naprawy, zużyte części

System ERP (system)

• do SOZ: dostępność części
• z SOZ: zapotrzebowanie na części

System księgowy (system)

• z SOZ: dane zamkniętego zlecenia do fakturowania

Bramka SMS/e-mail (system)

• z SOZ: treść powiadomienia dla klienta

Kierownik serwisu (człowiek)

• z systemu: raport zleceń i czasów reakcji

Sześć aktorów, dwanaście przepływów, jedna kartka. I teraz to, co ten rysunek robi w praktyce.

Strzałka „dane zamkniętego zlecenia do fakturowania" jednoznacznie mówi: SOZ NIE fakturuje, tylko przekazuje dane. Kierunek strzałki do ERP mówi: SOZ zgłasza zapotrzebowanie, ale nie zarządza magazynem. Brak aktora „dział HR" mówi: grafiki serwisantów są poza grą. Każda z tych rzeczy była w którymś projekcie przedmiotem sporu, który diagram ucina jednym spojrzeniem.

Zwróć też uwagę na bramkę SMS. Początkujący analitycy często ją pomijają, bo „to tylko wysyłka powiadomień". A potem okazuje się, że trzeba wybrać dostawcę, podpisać umowę, obsłużyć błędy doręczenia i zbudować integrację. Każdy aktor-system na diagramie kontekstowym to potencjalna integracja, czyli koszt i ryzyko. Policz systemy na swoim diagramie: to najszybszy szacunek złożoności integracyjnej projektu, jaki dostaniesz przed rozpisaniem wymagań. Swoją drogą właśnie umiejętność takiego myślenia o granicach i integracjach jest tym, co odróżnia analityka od osoby spisującej życzenia - jeśli dopiero budujesz warsztat BA, zobacz ścieżki wejścia do analizy biznesowej.

Checklista: 8 pytań, którymi zweryfikujesz zakres z interesariuszami

Gotowy diagram bierzesz na przegląd z interesariuszami. Nie pytaj „czy to jest okej", bo usłyszysz „tak" i nic z tego nie wynika. Przejdź te pytania po kolei:

1. Czy każdy element dookoła jest naprawdę poza systemem? Jeśli „moduł raportowy" wisi jako aktor, ktoś właśnie zdradził, że nie wie, czy raporty są w zakresie.
2. Czy każda strzałka ma etykietę z konkretną informacją? Strzałka bez podpisu to niezadane pytanie. Podpis „dane" to podpis-wydmuszka.
3. Kogo tu brakuje? Zapytaj wprost: kto jeszcze wysyła coś do tego systemu albo czegoś od niego oczekuje? Audytor? Regulator? Zewnętrzny partner?
4. Skąd system bierze każdą informację, którą wydaje? Jeśli kierownik dostaje raport czasów reakcji, ktoś musi te czasy do systemu wprowadzać. Jeśli nikt - masz dziurę.
5. Czy jest aktor bez strzałek albo z ruchem tylko w jedną stronę tam, gdzie spodziewasz się dialogu? Klient, który tylko wysyła i nic nie dostaje, to prawdopodobnie brakujące powiadomienia.
6. Które przepływy już istnieją, a które trzeba zbudować? Oznacz je różnie. Właśnie powstała pierwsza mapa prac integracyjnych.
7. Co świadomie zostaje poza zakresem i kto to potwierdza? Czytasz listę wykluczeń na głos, punkt po punkcie, i zbierasz potwierdzenia imiennie.
8. Kto jest właścicielem każdego systemu zewnętrznego i czy wie, że planujecie integrację? To pytanie ratuje projekty. Zespół ERP, który o integracji dowiaduje się kwartał później, potrafi zamrozić harmonogram skuteczniej niż każdy brak budżetu.

Trzydzieści minut rysowania, godzina przeglądu. W zamian dostajesz wspólną granicę systemu, listę integracji, listę wykluczeń z podpisami i kilkanaście pytań wyłapanych zanim stały się drogie. Modelowanie zakresu to też stały element sylabusów certyfikacji BA, od ECBA po CBAP - jeśli myślisz o formalnym potwierdzeniu kompetencji, porównanie certyfikacji analityka biznesowego masz w jednym miejscu.

Teorię masz. Diagram kontekstowy zapamiętasz dopiero wtedy, kiedy narysujesz własny i ktoś go skrytykuje. Na platformie Analify ćwiczysz techniki BA na realistycznych wyzwaniach projektowych, a Twoje rozwiązania przechodzą peer review - czyli dokładnie ten przegląd z pytaniami, który opisałem wyżej, tylko na Twojej pracy.