Zarządzanie wymaganiami

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).