Zbieranie wymagań i analiza
Zarządzanie wymaganiami
Szkolenia z Zarządzania wymaganiami koncentrują się na pozyskiwaniu, analizowaniu, modelowaniu i walidowaniu wymagań z użyciem UML, przypadków użycia i technik UX, a analitykom, Product Ownerom, testerom i przedstawicielom biznesu pomagają opracować specyfikacje oraz zweryfikować jakość rozwiązań IT.
Filtry
Zarządzanie wymaganiami
Najniższa cena z ostatnich 30 dni
Skontaktuj się z namiProjektowanie zorientowane na użytkownika
Najniższa cena z ostatnich 30 dni
Skontaktuj się z namiTworzenie i walidacja specyfikacji funkcjonalnej wymagań
Najniższa cena z ostatnich 30 dni
Skontaktuj się z namiPrzypadki użycia w zarządzaniu wymaganiami
Opinie uczestników
- Paweł Klim, Silky Coders Sp. z o.o.Uczestnik szkolenia Tworzenie i walidacja specyfikacji funkcjonalnej wymagań
Niewiele z niego wyniosłem
- Jolanta Zaborowska, Silky Coders Sp. z o.o.Uczestnik szkolenia Tworzenie i walidacja specyfikacji funkcjonalnej wymagań
Przede wszystkim zabrakło mi poczucia spójności, celu i merytoryki. Warsztatowe ćwiczenia były ok, ale zabrakło tła merytorycznego i "twardych danych". W moich oczekiwaniach do szkolenia pisałam o usystematyzowaniu wiedzy, zależało mi na poukładaniu tego co intuicyjnei wiem, stosuję i utwierdzeni, ze działam dobrze albo powinnam działać inaczej. Kiedy jakie formy, metody są wykorzystywane itd. Miałam wrażenie, że szkolenie jest mocno improwizowane.
- Natalia Małysa, Silky Coders Sp. z o.o.Uczestnik szkolenia Tworzenie i walidacja specyfikacji funkcjonalnej wymagań
Zbyt bezpośrednie podejście prowadzącej do uczestników, często używane kolokwializmy. Brak zaznajomienia się z profilem działalności firmy bądź w ogóle weryfikacji kogo dotyczy szkolenie. Chaotyczne prowadzenie szkolenia, bez konkretnej agendy. Brak przygotowania testowych wymagań- ogólnych aby każdy uczestnik mógł się dopasować. Wybrano temat, który widać było, że nie odpowiada uczestnikom
- Zuzanna Margońska, Silky Coders Sp. z o.o.Uczestnik szkolenia Tworzenie i walidacja specyfikacji funkcjonalnej wymagań
Szkolenie było nieustrukturyzowane i po jego zakończeniu nie mam poczucia, że dużo się nauczyłam - przez teorię przeszliśmy wyrywkowo i pobieżnie, a ćwiczenia nie były dobrze doprecyzowane i przygotowane (np. nie był określony dobrze kontekst w jakim mamy realizować zadanie, przykłady były wymyślane na bieżąco i niektóre nie nadawały się dobrze do prostych zadań typu "opisz jedno wrywkowe wymaganie", pracowaliśmy też na własnych narzędziach Miro); dużo czasu było też poświęcone na dyskusje, które w retrospekcji nie służyły wg mnie celowi szkolenia, nawet jeśli same w sobie mogłabym uznać je za interesujące, nie po to tam przyszliśmy; było też trochę trudności technicznych po stronie łącza internetowego Prowadzącej
- Anna Wysocka, Silky Coders Sp. z o.o.Uczestnik szkolenia Tworzenie i walidacja specyfikacji funkcjonalnej wymagań
Szkolenie była adresowane do analityków na poziomie mid. Moim zdaniem poziom szkolenia był dedykowany juniorom. Omawiany przykład na szkoleniu celem praktyki warsztatu analityka: nie był wcześniej przygotowany, przez co znaczna część szkolenia (cały pierwszy dzień) była skupiona na rozpoznaniu procesu biznesowego,a nie zastosowaniu metod specyfikacji wymagań w powiązaniu do miedzynarodowych standardów. Zabrakło mi jasnej agendy szkolenia i przedstawienia celu ćwiczeń z nawiązaniem do standardu tworzenia specyfikacji wymagań (wg BABOK, IREB). Prezentacja dostarczona podczas szkolenia była tylko materiałem pomocniczym, który wybiórczo został omówiony na przykładzie. Dla mnie prowadzenie warsztatu było chaotyczne (dopiero po zakończeniu długich ćwiczeń, na koniec dnia dowiedziałam się, jak to co opracowaliśmy na miro nawiązuje i do którego punktu w prezentacji). To co dodatkowo utrudniało mi pełne skorzystanie ze szkolenia, to brak włączonej kamerki przez prowadzącą oraz sam styl prowadzenia tego szkolenia: bardzo luźny, dużo dygresji, zaczepnych komentarzy, zamiast skupienia na meritum, używanie słów niecenzuralnych (nie czułam się nimi obrażana, ale niosą one ze sobą negatywne emocje). Spodziewałam się, że finalnym efektem szkolenia, będzie gotowy dokument specyfikacji wymagań zgodny ze standardem BABOK lub IREB, na opracowanym na warsztacie przykładzie.
- Zuzanna Biernat, Silky Coders Sp. z o.o.Uczestnik szkolenia Tworzenie i walidacja specyfikacji funkcjonalnej wymagań
nieprofesjonalna prowadząca
- Klaudia Łaga, Silky Coders Sp. z o.o.Uczestnik szkolenia Tworzenie i walidacja specyfikacji funkcjonalnej wymagań
Za dużo pitupitu za mało szkolenia
- Wioletta SobczakUczestnik szkolenia Tworzenie i walidacja specyfikacji funkcjonalnej wymagań
Przede wszystkim praktyczne
- Agata KowalskaUczestnik szkolenia Tworzenie i walidacja specyfikacji funkcjonalnej wymagań
Dużo przykładów praktycznych, pełna otwartość trenera na potrzeby uczestników
- Magdalena Szrajber-SłomczyńskaUczestnik szkolenia Tworzenie i walidacja specyfikacji funkcjonalnej wymagań
Duża dawka wiedzy. Super atmosfera.
- Paweł MizińskiUczestnik szkolenia Zarządzanie wymaganiami
Jako laik w temacie lubię perspektywę ogólną schodzącą w dół. Pozwala to kreślić pełen zakres tematu. W tym przypadku mieliśmy prezentację elementów, które na końcu dały pełen obraz funkcji Wymagań Biz.
- Wioletta SobczakUczestnik szkolenia Zarządzanie wymaganiami
Przede wszystkim duża i wszechstronna wiedza prowadzącego oraz logicznie ułożony proces prowadzenia szkolenia
Szukasz innych technologii?
Zapoznaj się z naszym pełnym katalogiem szkoleń i usług IT
FAQ
Zbieranie wymagań biznesowych i funkcjonalnych polega na uporządkowanym pozyskiwaniu potrzeb interesariuszy oraz przekładaniu ich na jednoznaczne zapisy możliwe do implementacji i testowania. W praktyce warto sprawdzić źródła wymagań, role interesariuszy, ograniczenia, ryzyka oraz dobrać techniki takie jak wywiady, analiza procesów, warsztaty i przegląd dokumentacji. Przykładem może być opisanie procesu obsługi zamówienia, a następnie rozbicie go na wymagania biznesowe, reguły i funkcje systemowe.
Ten temat przerabiamy praktycznie na szkoleniu: Zarządzanie wymaganiami (ZW).
Przypadki użycia opisują interakcje aktora z systemem w formie scenariuszy, dlatego dobrze sprawdzają się tam, gdzie trzeba precyzyjnie uchwycić przebieg procesu, warianty oraz wyjątki. Przy wyborze warto ocenić złożoność funkcji, liczbę ról, potrzebę modelowania alternatywnych ścieżek i poziom formalizacji dokumentacji. Przykładem jest proces logowania z obsługą błędnego hasła, blokady konta i resetu dostępu, który w specyfikacji przypadku użycia będzie czytelniejszy niż skrócona user story.
Jeśli chcesz przećwiczyć to krok po kroku, zobacz: Przypadki użycia w zarządzaniu wymaganiami (CASE).
Jakość specyfikacji wymagań ocenia się przez kompletność, spójność, jednoznaczność, testowalność i powiązanie z celami biznesowymi oraz zakresem rozwiązania. Należy przejrzeć definicje pojęć, kryteria akceptacji, zależności między wymaganiami, ślady powiązań oraz miejsca, w których pojawiają się luki, nadmiar ogólników albo niejawne założenia. Typowym przykładem błędu jest zapis „system ma działać szybko”, który trzeba zastąpić mierzalnym wymaganiem z parametrem czasu odpowiedzi i warunkami testu.
To jedno z zagadnień omawianych podczas szkolenia: Tworzenie i walidacja specyfikacji funkcjonalnej wymagań (CREQ).
Dokumentowanie wymagań funkcjonalnych zgodnie ze standardami wymaga dobrania właściwej formy zapisu, poziomu szczegółowości i notacji adekwatnej do odbiorców dokumentacji. Warto sprawdzić cel specyfikacji, grupę docelową, strukturę dokumentu, sposób opisu scenariuszy oraz to, czy diagramy UML wspierają zrozumienie zależności zamiast je zaciemniać. Przykładem jest połączenie opisu tekstowego wymagania, diagramu przypadków użycia i kryteriów akceptacji dla funkcji rejestracji użytkownika.
Wersję warsztatową (z konfiguracją i przykładami) znajdziesz w programie szkolenia: Tworzenie i walidacja specyfikacji funkcjonalnej wymagań (CREQ).
Wymagania użyteczności opisują, jak skutecznie, sprawnie i zrozumiale użytkownicy mają realizować zadania w systemie, dlatego trzeba je badać w kontekście rzeczywistego użycia. Dobrze jest przeanalizować profile użytkowników, scenariusze pracy, cele jakościowe, persony, customer journey oraz zaplanować testy użyteczności z mierzalnymi kryteriami oceny. Przykładem może być weryfikacja, czy nowy formularz zakupowy pozwala ukończyć zamówienie bez błędów i bez wsparcia konsultanta.
Dokładnie ten zestaw narzędzi i workflow ćwiczymy podczas szkolenia: Projektowanie zorientowane na użytkownika (UCD).
Szkolenia z zarządzania wymaganiami są najbardziej przydatne wtedy, gdy organizacje porządkują sposób zbierania potrzeb, przygotowują dokumentację projektową albo chcą ograniczyć błędy wynikające z niejednoznacznych ustaleń. Warto sprawdzić, czy w projektach występują częste zmiany zakresu, spory interpretacyjne, problemy z odbiorem funkcji, luki w specyfikacjach lub trudności z walidacją rozwiązań przez biznes. Przykładem są zespoły, które przed startem wdrożenia potrzebują wspólnego modelu pracy dla analityków, testerów, Product Ownerów i przedstawicieli biznesu.
Ten temat przerabiamy praktycznie na szkoleniu: Zarządzanie wymaganiami (ZW).