Słownik analityka biznesowego

Angielska nazwa kryteriów akceptacji — warunki, które muszą być spełnione, aby praca została zaakceptowana.

Business Analysis Body of Knowledge — międzynarodowy standard wiedzy o analizie biznesowej publikowany przez IIBA.

Wspólnie uzgodniona lista warunków, które muszą być spełnione, aby element pracy (User Story, Sprint) został uznany za ukończony.

Wspólne rozumienie zespołu, jakie warunki muszą być spełnione, aby element pracy mógł być uznany za ukończony.

Lista warunków, które User Story musi spełnić, zanim zespół może ją wziąć do sprintu.

Duża User Story, zbyt złożona na jeden sprint, która jest dzielona na mniejsze stories przed implementacją.

Akronim definiujący cechy dobrej User Story: Independent, Negotiable, Valuable, Estimable, Small, Testable.

Requirements Traceability Matrix — tabela łącząca wymagania z ich źródłami, przypadkami testowymi i elementami rozwiązania.

Czynnik limitujący możliwości realizacji projektu, np. budżet, czas, technologia lub regulacje.

Niepewne zdarzenie, które jeśli wystąpi, będzie miało pozytywny lub negatywny wpływ na cele projektu.

Opis kroków do wykonania w celu weryfikacji, czy system działa zgodnie z wymaganiami — obejmuje dane wejściowe, kroki i oczekiwane rezultaty.

Software Requirements Specification — formalny dokument opisujący wszystkie wymagania funkcjonalne i niefunkcjonalne systemu.

Jednostka estymacji w Agile, wyrażająca względną złożoność User Story (nie czas), najczęściej w skali Fibonacciego.

Alternatywna polska nazwa dla User Acceptance Testing — patrz UAT.

Zdolność do śledzenia powiązań między wymaganiami a ich źródłem, implementacją i testami przez cały cykl życia projektu.

Końcowa faza testów, w której użytkownicy biznesowi weryfikują, czy system spełnia ich wymagania i jest gotowy do produkcji.

Szczegółowy opis interakcji aktora z systemem prowadzącej do osiągnięcia konkretnego celu biznesowego.

Wysokopoziomowy opis potrzeby organizacji, który definiuje cel lub problem do rozwiązania.

Opis konkretnej funkcji lub zachowania systemu, które musi zostać zaimplementowane.

Opis potrzeby lub oczekiwania interesariusza wobec systemu lub procesu, stanowiący podstawę do definiowania wymagań systemowych.

Opis ograniczeń i cech jakościowych systemu, takich jak wydajność, bezpieczeństwo czy dostępność.

Proces planowania, śledzenia, analizy i dokumentowania wymagań przez cały cykl życia projektu.

Czynnik przyjęty za prawdziwy na potrzeby planowania projektu, ale niesprawdzony — wymaga monitorowania.