Słownik analityka

Słownik wyjaśnia pojęcia tak, jak są używane w projekcie IT. Każda definicja zawiera praktyczny kontekst, ponieważ to samo słowo może oznaczać coś innego dla właściciela biznesowego, analityka, projektanta i programisty.

Analiza biznesowa

Praktyka rozpoznawania potrzeb i rekomendowania zmian, które dostarczają wartość interesariuszom. Obejmuje problem, cel, proces, role, dane, reguły, warianty rozwiązania i sposób oceny efektu. Przykład: przed budową portalu zgłoszeniowego analityk sprawdza, dlaczego zgłoszenia wracają, jakie dane są brakujące i kto podejmuje decyzję o ich przyjęciu. Zobacz pełny przewodnik: analiza biznesowa w projektach IT.

Analiza systemowa

Doprecyzowanie sposobu działania rozwiązania informatycznego: zachowań, danych, stanów, integracji, reguł, wyjątków i cech jakościowych. Analiza systemowa odpowiada na pytanie „jak rozwiązanie ma działać?”, podczas gdy analiza biznesowa wcześniej ustala „jaką zmianę warto wprowadzić i dlaczego?”.

Artefakt analityczny

Materialny rezultat pracy, który przenosi wiedzę lub decyzję: diagram procesu, tabela reguł, mapa interesariuszy, prototyp, opis wymagania, rejestr decyzji albo zestaw przykładów. Artefakt jest użyteczny wtedy, gdy ma konkretnego odbiorcę i wspiera działanie. Dokument bez celu, właściciela i sposobu użycia jest jedynie plikiem.

AS-IS

Opis rzeczywistego stanu obecnego. Powinien uwzględniać faktyczny przebieg, ręczne obejścia, wyjątki, dane i czasy oczekiwania, a nie tylko oficjalną procedurę. Model AS-IS służy do znalezienia przyczyn problemu i punktu odniesienia dla mierzenia zmiany. Porównaj z TO-BE.

BPMN

Business Process Model and Notation — standard graficznego modelowania procesów. Zdarzenia pokazują, co uruchamia lub kończy przepływ, zadania — jaka praca jest wykonywana, bramki — jak rozdzielają się i łączą ścieżki, a pule i tory — kto odpowiada za działania. Diagram ma ułatwiać wspólne zrozumienie procesu; poprawność symboli nie naprawi błędnych faktów. Zacznij od BPMN dla początkujących.

Interesariusz

Osoba, grupa lub organizacja, która wpływa na zmianę, odczuwa jej skutki albo posiada wiedzę potrzebną do decyzji. Interesariuszem może być użytkownik, właściciel procesu, osoba zatwierdzająca budżet, dział bezpieczeństwa, administrator lub odbiorca danych. Sama lista nazw nie wystarcza — trzeba określić wpływ, potrzeby, obawy i rolę decyzyjną.

Kryterium akceptacji

Obserwowalny warunek, który pozwala ocenić, czy wymaganie zostało spełnione. Dobre kryterium opisuje sytuację, działanie i oczekiwany rezultat. Słabo: „system poprawnie waliduje formularz”. Lepiej: „jeżeli numer NIP ma mniej niż 10 cyfr, wysłanie formularza jest zablokowane, a przy polu pojawia się komunikat wskazujący błąd”.

Proces biznesowy

Powiązany ciąg działań prowadzący od określonego zdarzenia do rezultatu wartościowego dla odbiorcy. Proces przekracza granice pojedynczego ekranu i często wielu działów. Ma wejście, wynik, uczestników, reguły i mierniki. Lista czynności bez rezultatu i odbiorcy nie opisuje jeszcze procesu.

Reguła biznesowa

Deklaracja ograniczająca lub określająca sposób działania organizacji. Może wynikać z prawa, polityki, umowy albo decyzji biznesowej. Przykład: „zamówienia powyżej 50 000 zł wymagają akceptacji dyrektora finansowego”. Reguła powinna mieć źródło, właściciela, datę obowiązywania i przykłady graniczne.

Śledzenie wymagania

Powiązanie wymagania z jego źródłem i dalszymi rezultatami: celem, interesariuszem, procesem, decyzją, elementem rozwiązania oraz testem. Dzięki temu można ocenić wpływ zmiany i wykryć „osierocone” funkcje, które nie wspierają żadnego celu. Śledzenie nie wymaga zawsze rozbudowanego narzędzia; w małym projekcie może wystarczyć tabela identyfikatorów.

TO-BE

Docelowy sposób działania po zmianie. Model TO-BE powinien pokazywać nowe role, reguły, dane, punkty kontroli i oczekiwane mierniki. Nie jest kopią AS-IS z dopisanym słowem „automatycznie”. Najpierw usuwa się zbędne działania i porządkuje odpowiedzialność, dopiero potem projektuje wsparcie technologiczne.

User story

Krótki zapis potrzeby użytkownika, najczęściej w formie „jako [rola] chcę [możliwość], aby [wartość]”. Jest zaproszeniem do rozmowy, a nie pełną specyfikacją. Wymaga kryteriów akceptacji, przykładów i kontekstu. User story jest wygodna dla małej, negocjowalnej części zakresu; złożony przepływ lepiej może opisać przypadek użycia.

Przypadek użycia

Opis interakcji aktora z systemem prowadzącej do konkretnego celu. Zawiera warunki początkowe, scenariusz podstawowy, alternatywy, wyjątki i rezultat. Jest przydatny tam, gdzie kolejność kroków oraz reakcje na błędy mają znaczenie. Zobacz porównanie: user story a przypadek użycia.

Walidacja

Sprawdzenie, czy opisujemy właściwą potrzebę i czy proponowane rozwiązanie ma sens dla użytkowników oraz biznesu. Pytanie walidacyjne brzmi: „czy budujemy właściwą rzecz?”. Można je sprawdzić rozmową, prototypem, eksperymentem, próbką danych albo obserwacją procesu.

Weryfikacja

Sprawdzenie, czy wymaganie lub rozwiązanie jest zgodne z ustalonym opisem, regułami i kryteriami. Pytanie weryfikacyjne brzmi: „czy zbudowaliśmy rzecz poprawnie?”. Walidacja i weryfikacja uzupełniają się: można poprawnie zaimplementować funkcję, która nie rozwiązuje prawdziwego problemu.

Wymaganie biznesowe

Potrzebny rezultat lub zdolność organizacji, wynikająca z celu biznesowego. Nie opisuje jeszcze konkretnego ekranu. Przykład: „organizacja musi ograniczyć średni czas przyjęcia kompletnego wniosku z dwóch dni do czterech godzin”.

Wymaganie funkcjonalne

Zachowanie, które rozwiązanie ma umożliwiać lub wykonywać. Przykład: „system wyznacza akceptującego na podstawie jednostki, rodzaju kosztu i wartości wniosku”. Funkcja powinna być powiązana z potrzebą oraz posiadać kryteria akceptacji.

Wymaganie niefunkcjonalne

Wymaganie opisujące jakość, ograniczenie lub warunki działania rozwiązania: wydajność, dostępność, bezpieczeństwo, użyteczność, zgodność, utrzymywalność albo możliwość odtworzenia danych. Słabo: „system ma być szybki”. Lepiej: „dla 95% żądań wyszukanie wniosku trwa nie dłużej niż 2 sekundy przy 300 równoczesnych użytkownikach”.