Słownik analityka biznesowego

Kryteria akceptacji to konkretne warunki, które muszą być spełnione, żeby uznać, że dane zadanie (np. nowa funkcja w programie) zostało wykonane prawidłowo. Używa się ich, żeby wszyscy wiedzieli, co dokładnie trzeba zrobić i kiedy można powiedzieć, że praca jest skończona. Na przykład, kryterium akceptacji dla formularza logowania może być: "Użytkownik musi mieć możliwość zalogowania się, używając poprawnego adresu email i hasła".

BABOK (A Guide to the Business Analysis Body of Knowledge) to wydawany przez IIBA (International Institute of Business Analysis) przewodnik po wiedzy analityka biznesowego - globalny standard opisujący, czym jest ta profesja.

Brief projektu to krótki dokument inicjujący przedsięwzięcie: opisuje problem lub cel, zakres (wraz z tym, czego świadomie NIE robimy), głównych interesariuszy, ograniczenia, kryteria sukcesu oraz ramy budżetu i terminów.

Definition of Done to lista kryteriów, które muszą być spełnione, żeby uznać daną pracę za zakończoną. Używamy tego, żeby wszyscy rozumieli tak samo, co oznacza "zrobione" i uniknąć sytuacji, w której ktoś myśli, że praca jest skończona, a w rzeczywistości wymaga jeszcze poprawek. Na przykład, dla zadania "napisanie posta na bloga", Definition of Done może zawierać: "tekst napisany, zredagowany, zaakceptowany przez klienta, opublikowany na stronie".

Definition of Ready (DoR) to lista kontrolna, która określa, czy wymaganie (np. zadanie do zrobienia) jest wystarczająco jasne i szczegółowe, żeby zespół mógł je zacząć realizować. Używamy jej przed rozpoczęciem pracy nad wymaganiem, żeby uniknąć nieporozumień i przestojów. Na przykład, wymaganie "Zrobić przycisk" nie jest gotowe, ale "Zrobić zielony przycisk 'Kup teraz' na stronie produktu, który przenosi do koszyka" już bardziej.

Epik (epic) to w zwinnym zarządzaniu backlogiem duża porcja pracy - zbyt duża, by zmieścić się w jednym sprincie - którą dzieli się na mniejsze historyjki użytkownika (user stories).

Feature (funkcjonalność) to w zwinnym backlogu porcja pracy między epikiem a historyjką użytkownika: konkretna funkcja produktu, którą użytkownik rozpozna po nazwie, a zespół dowiezie w kilku iteracjach.

Governance wymagań (requirements governance) to ustalone zasady zarządzania wymaganiami w projekcie lub organizacji: kto zatwierdza, jak zgłasza się i ocenia zmiany, kto ma jaki głos przy priorytetyzacji, jak wymagania są wersjonowane i śle

INVEST to akronim opisujący cechy dobrej historyjki użytkownika: Independent (niezależna od innych), Negotiable (otwarta na rozmowę, nie kontrakt), Valuable (wartościowa dla użytkownika), Estimable (możliwa do oszacowania), Small (mała - do

Matryca śledzenia wymagań (RTM) to taki specjalny dokument, tabela, która pomaga nam pilnować, żeby wszystkie potrzeby klienta (wymagania) zostały uwzględnione w projekcie. Używamy jej, żeby mieć pewność, że niczego nie pominęliśmy i że wiemy, w którym miejscu projektu (np. w jakim dokumencie, w jakim etapie testów) dane wymaganie jest realizowane. Na przykład, jeśli klient chce, żeby strona internetowa ładowała się w mniej niż 3 sekundy, to w RTM zaznaczamy, gdzie to wymaganie jest opisane, jak je testujemy i czy testy wypadły pomyślnie.

Ograniczenie projektowe (ang. constraint) to narzucony z góry warunek, który zawęża przestrzeń możliwych rozwiązań - budżet, termin, technologia, regulacje, dostępność ludzi - i którego zespół nie może zmienić, a jedynie musi uwzględnić.

Ryzyko projektowe (ang. project risk) to niepewne zdarzenie, które - jeśli wystąpi - wpłynie na cele projektu: zakres, termin, budżet lub jakość.

Scenariusz testowy (ang. test scenario) to opis sytuacji do przetestowania sformułowany z perspektywy celu biznesowego: co sprawdzamy i po co.

Specyfikacja wymagań oprogramowania (SRS, Software Requirements Specification) to dokument opisujący kompletny zestaw wymagań na system: funkcjonalne, niefunkcjonalne, interfejsy zewnętrzne, ograniczenia i przyjęte założenia.

Story Points to jednostka miary używana do szacowania wysiłku, jaki trzeba włożyć w realizację zadania (historyjki użytkownika) w projekcie, np. w tworzeniu oprogramowania. Używa się ich zamiast godzin, bo są bardziej abstrakcyjne i uwzględniają złożoność, ryzyko i niepewność. Na przykład, zadanie "Dodanie przycisku" może mieć 1 Story Point, a "Zaimplementowanie systemu logowania" - 5 Story Points, bo jest bardziej skomplikowane.

Traceability, czyli śledzenie wymagań, to jak mapa, która pokazuje, skąd wzięło się dane wymaganie i jak wpływa na różne elementy projektu. Używamy tego, żeby upewnić się, że każde wymaganie jest zrealizowane i żeby łatwo znaleźć, co trzeba zmienić, gdy coś się zmieni w jednym miejscu. Na przykład, jeśli klient poprosi o funkcję "dodawanie produktu do koszyka", traceability pokaże, które testy sprawdzają tę funkcję i które części kodu za nią odpowiadają.

UAT, czyli Testy Akceptacyjne Użytkownika, to po prostu sprawdzanie, czy program lub system działa tak, jak tego oczekują osoby, które będą go używać na co dzień. Robi się to pod koniec tworzenia programu, żeby upewnić się, że wszystko działa poprawnie i spełnia potrzeby użytkowników. Na przykład, jeśli robisz aplikację do zamawiania pizzy, to UAT polega na tym, że klienci testują, czy mogą łatwo wybrać pizzę, dodatki i zapłacić.

Use case (przypadek użycia) to opis interakcji między aktorem (użytkownikiem lub systemem zewnętrznym) a systemem, prowadzącej do osiągnięcia konkretnego celu.

Wymaganie biznesowe opisuje cel lub potrzebę organizacji: co biznes chce osiągnąć i po co - bez przesądzania, jak ma to zrobić system.

Wymaganie funkcjonalne określa, co system ma robić: jakie zachowania, funkcje i operacje na danych ma realizować w odpowiedzi na działania użytkowników i zdarzenia.

Wymaganie interesariusza to po prostu potrzeba lub oczekiwanie osoby (lub grupy osób), która ma wpływ na projekt lub jest przez niego dotknięta. Używamy tego, żeby zrozumieć, czego te osoby potrzebują od projektu, aby był on dla nich sukcesem. Na przykład, jeśli tworzymy nową aplikację do zamawiania jedzenia, wymaganiem interesariusza (np. właściciela restauracji) może być łatwy sposób na aktualizowanie menu i cen.

Wymaganie niefunkcjonalne (NFR, non-functional requirement) określa, jak dobrze system ma działać: wydajność, dostępność, bezpieczeństwo, użyteczność, skalowalność, zgodność z prawem, łatwość utrzymania.

Zarządzanie wymaganiami to pilnowanie, żeby wszyscy w projekcie wiedzieli, co dokładnie ma powstać (np. jaka funkcjonalność ma mieć program) i żeby te ustalenia nie zmieniały się bez kontroli. Używamy tego, żeby uniknąć sytuacji, w której programista robi coś innego, niż oczekiwał klient, bo np. źle się zrozumieli na początku. Wyobraź sobie, że zamawiasz tort urodzinowy - zarządzanie wymaganiami to spisanie, jaki ma być smak, wygląd i waga, żeby cukiernik nie zrobił czegoś innego.

Założenie projektowe (assumption) to stwierdzenie przyjęte za prawdziwe bez dowodu - na potrzeby planowania, wyceny lub projektowania rozwiązania.