Dr Karolina Muszyńska Opracowano na podstawie: Wiegers K., Beatty J., Specyfikacja oprogramowania. Inżynieria wymagań, Helion, 2014.

Prezentacja na temat: "Dr Karolina Muszyńska Opracowano na podstawie: Wiegers K., Beatty J., Specyfikacja oprogramowania. Inżynieria wymagań, Helion, 2014."— Zapis prezentacji:

1 Dr Karolina Muszyńska Opracowano na podstawie: Wiegers K., Beatty J., Specyfikacja oprogramowania. Inżynieria wymagań, Helion, 2014

2  Analityk biznesowy to osoba, której główną odpowiedzialnością jest pozyskiwanie, analizowanie, dokumentowanie oraz walidacja potrzeb interesariuszy projektu.  Analityk pełni funkcję głównego interpretatora, przez którego przepływają wymagania między społecznością klientów a zespołem pracującym nad oprogramowaniem.  Odgrywa on centralną rolę w gromadzeniu oraz przekazywaniu informacji o produkcie, podczas gdy menedżer projektu zajmuje się przede wszystkim informacjami dotyczącymi projektu. 2

3 3

4  Podjęcie decyzji o zaangażowaniu utalentowanego analityka może zadecydować o różnicy dzielącej projekt zakończony sukcesem od projektu borykającego się z trudnościami.  Specyfikacje pisane przez doświadczonego analityka można czytać dwukrotnie szybciej niż specyfikacje tworzone przez analityka początkującego, gdyż te pierwsze zawierają mniej defektów.  Doświadczenie i umiejętności analityka wywierają znaczący wpływ na wysokość kosztów oraz nakłady poniesione na projekt.  Analitycy o dużym doświadczeniu mogą przyczynić się do zmniejszenia o jedną trzecią łącznych nakładów związanych z projektem w porównaniu z podobnymi projektami, za które odpowiadali niedoświadczeni analitycy. 4

5  Definiowanie wymagań biznesowych  Planowanie podejścia do wymagań  Identyfikowanie interesariuszy projektu oraz klas użytkowników  Pozyskiwanie wymagań  Analizowanie wymagań  Dokumentowanie wymagań  Komunikowanie wymagań  Prowadzenie walidacji wymagań  Pomoc w priorytetyzacji wymagań  Zarządzanie wymaganiami 5

6  Umiejętność słuchania  Umiejętność rozmawiania i zadawania pytań  Umiejętność szybkiego podejmowania decyzji  Zdolności analityczne  Myślenie w kategoriach systemów  Umiejętność uczenia się  Umiejętności facylitacyjne  Zdolności przywódcze  Spostrzegawczość  Umiejętności komunikacyjne  Zdolności organizacyjne  Umiejętność tworzenia modeli  Umiejętności interpersonalne  Kreatywność 6

7 Zawód analityka wymaga kompetencji społecznych, które są w mniejszym stopniu techniczne, ale za to bardziej ukierunkowane na człowieka Skuteczny analityk biznesowy łączy w sobie wysokie umiejętności komunikacyjne oraz interpersonalne, wiedzę techniczną i związaną z dziedziną biznesu. Znajomość biznesu, branży oraz organizacji przynosi ogromne korzyści efektywnemu analitykowi biznesowemu. Analitycy rozumiejący dziedzinę organizacji oraz dziedzinę biznesową często potrafią odgadnąć niewypowiedziane potrzeby i pozostające w ukryciu wymagania. Analityk powinien także rozumieć współczesne praktyki inżynierii wymagań i wiedzieć, jak je stosować w kontekście różnych cykli tworzenia oprogramowania. Cierpliwość i autentyczna chęć do pracy z innymi ludźmi są najistotniejszymi czynnikami decydującymi o sukcesie. 7

8 Dr Karolina Muszyńska Opracowano na podstawie: Wiegers K., Beatty J., Specyfikacja oprogramowania. Inżynieria wymagań, Helion, 2014

9  Wymagania biznesowe to zestaw informacji, które łącznie opisują potrzebę prowadzącą do projektu /–ów rozwiązania oraz osiągnięcia pożądanych wyników biznesowych.  Wymagania biznesowe należy określić przed pełnym zdefiniowaniem wymagań funkcjonalnych i pozafunkcjonalnych.  Deklaracja zakresu i ograniczeń projektu znacząco pomaga w omawianiu proponowanych funkcjonalności i docelowych wersji produktu.  Wymagania biznesowe stanowią punkt odniesienia podczas podejmowania decyzji dotyczących realizacji proponowanych zmian w wymaganiach oraz pozostałych ulepszeń produktu.  Wymagania biznesowe obejmują możliwości biznesowe, cele biznesowe, miary sukcesu oraz deklarację wizji. 9

10  Najważniejszymi elementami wymagań biznesowych są wizja produktu i zakres projektu.  Wizja produktu zwięźle opisuje ostateczny produkt, który pomoże osiągnąć cele biznesowe. Wizja opisuje, co produkt ma robić oraz jaki ma przyjąć ostateczny kształt. Zapewnia ona kontekst do podejmowania decyzji przez cały czas trwania życia produktu i kieruje wszystkich interesariuszy w tę samą stronę.  Zakres projektu określa, jaka część ostatecznej wizji produktu zostanie urzeczywistniona w bieżącym projekcie albo iteracji. Deklaracja zakresu wyznacza granicę między tym, co znajdzie się w danym projekcie, a tym, co wypadnie poza projekt. 10

11  Dokument wizji i zakresu przyjmuje różne postacie: karta projektu, dokument przypadku biznesowego, dokument wymagań rynkowych lub marketingowych  Właścicielem dokumentu wizji i zakresu jest sponsor projektu lub jakiś inny organ finansujący projekt, a nad jego opracowaniem powinni pracować analitycy biznesowi oraz osoby, które wiedzą dlaczego podjęły pracę nad projektem i jakich efektów jego realizacji oczekują 11

12 12

13  Tło ◦ Przesłanki i kontekst utworzenia nowego produktu lub wprowadzenia zmian w istniejącym.  Możliwość biznesowa ◦ Opis rozwiązywanego problemu biznesowego lub udoskonalonego procesu oraz środowiska, w którym będzie używany związany z tym system informatyczny. ◦ Porównania z innymi podobnymi produktami i zaznaczenie zalet proponowanego produktu. ◦ Zbieżność proponowanego produktu z trendami rynkowymi, rozwojem technologicznym lub kierunkami strategii firmowej. ◦ Opis potrzeb typowego klienta oraz docelowego rynku produktu ◦ Definicja wszystkich krytycznych wymagań interfejsu oraz wymagań jakościowych. 13

14  Cele biznesowe ◦ Ilościowe i mierzalne podsumowanie ważnych korzyści biznesowych, których odniesienie zapewni produkt (ogólniki typu „zapewni użytkownikom większą satysfakcję…” nie są ani przydatne ani możliwe do zweryfikowania) ◦ Przykłady finansowych i pozafinansowych celów biznesowych  ◦ Na tym etapie cel musimy odpowiedzieć na następujące pytania:  Co nas powstrzymuje przed osiągnięciem celu? – problem biznesowy  Dlaczego zależy nam na osiągnięciu celu? – możliwość biznesowa  Skąd będziemy wiedzieć, że problem został rozwiązany? – identyfikacja mierzalnego celu 14

15 15

16  Miary sukcesu ◦ Określenie wskaźników, z których będą korzystać interesariusze w celu definiowania i mierzenia sukcesu odniesionego w projekcie. ◦ Miary sukcesu wskazują, czy projekt znajduje się na drodze prowadzącej do zrealizowania celów biznesowych.  Deklaracja wizji ◦ Podsumowanie długoterminowego celu i przeznaczenia produktu ◦ W dokumencie definiującym wizję powinny się znaleźć następujące elementy:  Dla [docelowy klient]  Który [określenie potrzeby albo możliwości]  Proponowany [nazwa produktu]  Który [kategoria produktu]  Jaki [główne możliwości, ważne zalety, istotne powody zakupu lub użytkowania]  W przeciwieństwie do [najważniejsze rozwiązanie alternatywne, bieżący system albo proces biznesowy]  Nasz produkt [najważniejsze różnice i zalety związane ze stosowaniem nowego produktu] 16

17  Ryzyka biznesowe ◦ Podsumowanie najważniejszych ryzyk biznesowych związanych z opracowaniem lub brakiem opracowania danego produktu (np. konkurencja na rynku, problemy z dotrzymaniem harmonogramu, przyjęcie przez użytkowników, problemy z implementacją oraz możliwy negatywny wpływ na działalność firmy).  Założenia i zależności biznesowe ◦ Monitorowanie przyjmowanych przez interesariuszy założeń podczas formułowania projektu i pisania dokumentu wizji i zakresu. ◦ Zapisanie wszystkich występujących w projekcie zależności od czynników zewnętrznych (np. standardy branżowe oraz przepisy prawa, rezultaty innych projektów, dostawcy albo partnerzy spoza organizacji). 17

18  Należy precyzyjnie określić czym wytworzony produkt, w szczególności system informatyczny jest a czym nie jest.  Zakres projektu opisuje koncepcję i dziedzinę zastosowania przyszłego produktu i ostatecznie przyjmuje postać zbioru wymagań funkcjonalnych zaplanowanych do implementacji.  Ograniczenia wyszczególniają funkcje, które nie zostaną zrealizowane w produkcie. 18

19  Główne funkcjonalności ◦ Lista głównych funkcjonalności produktu oraz cechy użytkowe ◦ Funkcjonalności powinny być jednoznacznie oznaczone ◦ Można także dołączyć drzewo funkcjonalności  Zakres pierwszego wydania – opis funkcjonalności zaplanowanych do realizacji w pierwszym wydaniu produktu (np. w formie przypadków użycia), opis charakterystyk jakościowych i najważniejszych wymagań pozafunkcjonalnych.  Zakres kolejnych wydań – opracowanie zakresu i harmonogramu kolejnych wydań.  Ograniczenia i wyłączenia – lista funkcjonalności, których może oczekiwać interesariusz, a które nie zostały zaplanowane do wdrożenia (zostały wykluczone z zakresu). 19

20  Profile interesariuszy – opis różnych kategorii klientów i pozostałych interesariuszy. Każdy profil interesariusza powinien zawierać następujące informacje: ◦ Najważniejsze korzyści, jakie z produktu odniesie interesariusz ◦ Oczekiwane po nich nastawienie do produktu. ◦ Ich najważniejsze właściwości i cechy charakterystyczne. ◦ Znane ograniczenia, które powinny zostać uwzględnione.  Priorytety projektu – aby efektywnie podejmować decyzje interesariusze muszą być zgodni co do priorytetów projektu. Należy przy tym uwzględnić pięć aspektów: funkcjonalność, jakość, harmonogram, koszty i pracownicy. Jeżeli wynikną niespodziewane okoliczności musi być zgodność co do najwłaściwszego sposobu postępowania.  Warunki wdrożenia - opis wszystkiego co może mieć wpływ na wdrożenie produktu, m.in. środowisko wdrożenia. 20

21  Diagram kontekstowy  Mapa ekosystemu  Drzewo funkcjonalności  Lista zdarzeń  Diagramy przypadków użycia 21

22 22

23 23

24 24

25  Proponowane nowe wymagania muszą za każdym razem podlegać analizie pod kątem mieszczenia się w zakresie. ◦ Jeżeli proponowane wymaganie całkowicie wykracza poza zakres, ale jest interesujące powinno być uwzględnione w przyszłym wydaniu albo innym projekcie. ◦ Jeżeli proponowane wymaganie mieści się w ramach zdefiniowanego zakresu projektu należy zaimplementować je w bieżącym projekcie. ◦ Jeżeli proponowane wymaganie leży poza zakresem, ale jest bardzo dobrym pomysłem, to w celu jego uwzględnienia należy poszerzyć zakres, a także dokonać koniecznych zmian w budżecie, harmonogramie i (lub) zespole. 25

26 Dr Karolina Muszyńska Opracowano na podstawie: Wiegers K., Beatty J., Specyfikacja oprogramowania. Inżynieria wymagań, Helion, 2014

27  Pozyskiwanie wymagań to proces identyfikowania potrzeb i ograniczeń różnych interesariuszy systemu oprogramowania. Jest to proces analityczny, który wiąże się ze zbieraniem, odkrywaniem, wydobywaniem i definiowaniem wymagań biznesowych, funkcjonalnych i pozafunkcjonalnych. 27

28  Wywiady (indywidualne albo w niewielkich grupach)  Warsztaty - ustrukturyzowane spotkanie, podczas którego starannie dobrana grupa interesariuszy i ekspertów współpracuje w celu definiowania, tworzenia, precyzowania i osiągnięcia porozumienia w zakresie oczekiwanych wyników (takich jak modele i dokumenty) reprezentujących wymagania użytkowników – sesje JAD  Grupy fokusowe – spotkania z reprezentacyjną grupą użytkowników  Obserwacje użytkowników 28

29  Kwestionariusze  Analiza interfejsów systemu - badanie systemów, z którymi łączy się tworzony system w celu wykrycia wymagań dotyczących wymiany danych i usług między systemami  Analiza interfejsu użytkownika - badanie istniejących systemów w celu odkrycia wymagań użytkownika i wymagań funkcjonalnych  Analiza dokumentów – badanie istniejącej dokumentacji 29

30  Zaplanowanie zakresu i programu sesji  Przygotowanie zasobów  Poznanie interesariuszy  Przygotowanie pytań  Przygotowanie prowizorycznych modeli (przypadków użycia, przepływu procesów) 30

31  Kształcenie interesariuszy  Sporządzanie rzetelnych notatek  Wykorzystywanie przestrzeni 31

32  Organizowanie i udostępnianie notatek  Dokumentowanie kwestii otwartych  Klasyfikowanie uzyskanych informacji ◦ Wymagania biznesowe ◦ Wymagania użytkowników ◦ Reguły biznesowe ◦ Wymagania funkcjonalne ◦ Atrybuty jakościowe ◦ Wymagania zewnętrznych interfejsów ◦ Ograniczenia ◦ Wymagania danych ◦ Propozycje rozwiązań 32