Przejdź do głównej zawartości

Pytanie o wymagania – a konkretnie o ich zbieranie…

Kolejne pytanie, które pojawiło się na „Liście 99” to:

Jak zbiera Pani wymagania?

Na to pytanie odpowiem posługując się radami, zawartymi w książce „Oprogramowanie szyte na miarę” M. Bartyzela, informacjami z kursu „Specjalistów analizy”  oraz wskazówkami z bloga analiza it


Zbieranie wymagań można podzielić na 3 podstawowe kategorie : Współpracę, Badania i Eksperymenty.

Do etapu współpracy zaliczymy m.in. wywiady, warsztaty ( o tym jak poprowadzić dobre warsztaty można dowiedzieć się z piętnastej lekcji kursu Specjalistów analizy ).
Do rozmowy (wywiadu), pierwsze co należy zrobić to PRZYGOTOWAĆ SIĘ ! Sprawdź kim są Twoi przyszli klienci, czym się zajmują, jaką pełnią rolę w organizacji itp. Itd. To ułatwi Ci prowadzenie rozmowy i pozwoli na połamanie pierwszych lodów.

Badania to między innymi Analiza: dokumentów, materiałów z etapu sprzedażowego, specyfikacji procesów biznesowych, regulacji, możliwych rozwiązań.

Eksperymenty to np.: tworzenie makiet i prototypów.

Ważnym aspektem jest zidentyfikowanie interfejsów nie tylko tych związanych z integracją pomiędzy systemami uczestniczącymi w procesie, ale także (a może przede wszystkim ) tych ludzkich, wymiana informacji między systemami/zespołami, analiza tej komunikacji to podstawa poprawnie zebranych wymagań.

 Jeśli prowadzimy rozwój systemu, czyli nie musimy zaczynać wszystkiego od zera, to dobrze jest zapoznać się z procesami w firmie (jeśli jest coś takiego jak księga procesów, to cudnie, ale najczęściej procesy zagnieżdżone są w dokumentach typu PT, lub różnego rodzaju Specyfikacjach).
   
Jeśli zależy nam na zebraniu dużej ilości informacji w krótkim czasie, warto w procesie zbierania wymagań posiłkować  się dobrymi ankietami i kwestionariuszami, które dadzą nam statystyczny ogląd na problemy , które chcemy rozwiązać.

Kolejnymi metodami są
Burze mózgów, należy zorganizować spotkanie, podać na nim temat i pozwolić uczestnikom na wypowiadanie najbardziej abstrakcyjnych pomysłów, takich, które mogą wydawać się irracjonalne a w efekcie mogą dawać spektakularne rezultaty!

Stymulowanie innego punktu widzenia – należy postawić się w roli potencjalnego użytkownika i jego oczami spojrzeć na potencjalny produkt. Metoda ta może okazać się zbawienna i rzuci nam nowe światło na zbieranie wymagań do naszego projektu.


Obserwacje polowe – polegają na obserwacji użytkowników w trakcie ich pracy, może wydawać się to na pierwszy rzut oka dość dziwne, no bo jak to tak, jedziemy do kogoś i gapimy mu się na ręce ? no niestety trochę tak, ale trzeba pamiętać, że warto wyjść zza biurka, zobaczyć jak wyglądają procesy od początku do końca. Niestety minusem tego sposobu zbierania wymagań jest możliwość pominięcia sytuacji wyjątkowych, bo np.: jesteśmy u naszego klienta przez 7 dni, wyjeżdżamy do swojego biura, mamy w głowie cudowny plan a tu JEB! 8 dnia 3 fuckupy, tysiąc błędów a my tego nie obserwowaliśmy i prawdopodobnie nie uwzględnimy w procesach i wymaganiach, które będziemy opisywać.

Warsztaty – mają na celu zebranie w przysłowiowej kupie osób z różnych działów, najlepiej z różnym punktem widzenia na dany problem, które wspólnie dochodzą do wniosków, dających ogromną wartość dodaną do procesu zbierania wymagań. Warsztaty są jedną z kluczowych praktyk zwinnych, ponieważ angażują kluczowych interesariuszy to tworzenia backlogu. Jedynym minusem warsztatów jest ich czasochłonność i trudność w wykorzystaniu dla zespołów rozproszonych geograficznie.



Przypadki użycia – pomagają spojrzeć na system oczami użytkownika, ważną zaletą przypadków użycia jest wyznaczenie dzięki nim granic systemu i powiązania aktorów z poszczególnymi funkcjonalnościami. Wadami przypadków użycia może być ich niemożliwość dostosowania do systemów bez interfejsu użytkownika lub dla samych wymagań jakościowych
Wg Inżynierii Wymagań, typowa struktura wymagania biznesowego powinna
obejmować następujące aspekty:

  • Użytkownik – dla kogo przeznaczone jest to wymaganie?
  • Wynik – jakiego wyniku oczekują interesariusze?
  • Przedmiot – co jest przedmiotem wymagania?
  • Kwalifikator – jaki jest mierzalny kwalifikator?


Metod zbierania wymagań jest oczywiście o wiele więcej, niemniej te wydają mi się najbardziej praktyczne i najczęściej stosowane. Jeśli uważasz, że ta odpowiedź powinna wyglądać inaczej, napisz w komentarzu. 😊
Etykiety:

Komentarze

Prześlij komentarz

Popularne posty z tego bloga

Jak Pani przeprowadza analizę? Pytania rekrutacyjne na Analityka Biznesowego

Na moim ulubionym  blogu o analizie znajduje się post z 99 pytaniami, które mogą pojawić się na rozmowie kwalifikacyjnej na stanowisko analityka biznesowo/systemowego. Przejdź do pytań   Od dziś będę opracowywać pytania znajdujące się na tej liście, co w konsekwencji pozwoli mi na sporządzenie obszernego materiału, który ułatwi przygotowanie się do skomplikowanego procesu rekrutacyjnego.   Oczywiście zdaje sobie sprawę z tego, że ile firm tyle różnych procesów i pytań kwalifikacyjnych, ale zagadnienia znajdujące się na liście „99 pytań” są na tyle uniwersalne, że można z dużym prawdopodobieństwem założyć, że część z nich zostanie użyta w trakcie rozmów wstępnych. No to lecimy :) pytanie na dziś to     Jak Pani przeprowadza analizę? Pierwsze co mi się nasunęło na myśl: „ To zależy ” 😉 , ale żeby na tym nie kończyć, to może napiszę od czego to tak naprawdę zależy. Ostatnio miałam przyjemność być na warsztatach Przewodnik po analizie dla zdezorientowanych- J
3 komentarze
Czytaj więcej

Jakie znasz rodzaje diagramów UML – lista 99

Dziś post krótki ale treściwy! Takie podobno cieszą się największym zainteresowaniem 😊 Jakie Pani zna rodzaje diagramów UML ? No i może ktoś się zdziwi, ale wszystkich diagramów UML jest 13 😉 ale oczywiście korzystanie ze wszystkich na raz często mija się z celem, bo projekt np.: nie zakładał tworzenia diagramu rozlokowania, albo wymagane były tylko diagramy przypadków użycia, klas i sekwencji.  Ale ! ale! ale ! to nie jest do końca tak, że jak czegoś na co dzień nie używamy to jest nieistotne i mało ważne.   Bo jeśli np.: okaże się, że w ramach dokumentacji ma powstać jakiś „rysunek” obrazujący relacje pomiędzy odpowiednimi częściami systemu to nie zaczniemy tworzyć nowego typu diagramu tylko skorzystamy z diagramu Struktur Połączonych (bo na kiego grzyba koło na nowo wymyślać). A dlaczego z niego skorzystamy ? bo wiemy, że istnieje i do tego właśnie powinien zostać użyty. A gdybyśmy o nim nigdy nie słyszeli to prawdopodobnie tworzylibyśmy nowe, nikomu
Prześlij komentarz
Czytaj więcej

User Stories i Przypadki Użycia na liście 99

Dziś połączymy odpowiedź do trzech pytań z listy 99 😊 Proszę napisać wymganie w formie user stories.  Proszę zapisać wymaganie w formie przypadku użycia. Czym są sytuacje wyjątkowe w opisie przypadków użycia ? No to może zanim zabierzemy się za konkretną odpowiedź, musimy wiedzieć (chociaż tak pokrótce), czym jest User Stories , a czym Use Case . User Stories (US) – inaczej historyjki użytkownika (po angielsku zawsze lepiej to brzmi), są krótką notatką z konwersacji/wywiadu na temat działania systemu. Dzięki User Stories doprecyzowujemy wymagania z rozmowy z klientem. Tylko pamiętajmy, że nie są one po to, aby szukać winnych w razie ewentualnych niedomówień i nie powinny stanowić dowodów w „kwitach” na naszych klientów 😉. [2] User Stories mają w sposób syntetyczny opisywać warunki, jakie powinny zostać spełnione z perspektywy użytkownika i cel, w jakim ta funkcja ma zostać przygotowana.  (definicję tę znalazłam w kursie Specjalistów Analizy )[3]. Ważne jest to,
Prześlij komentarz
Czytaj więcej