Inżynieria wymagań. Wykład 3 Zarządzanie wymaganiami w oparciu o przypadki użycia. Część 3 Analiza problemu

Transkrypt

1 Inżynieria wymagań Wykład 3 Zarządzanie wymaganiami w oparciu o przypadki użycia Część 3 Analiza problemu Opracowane w oparciu o materiały IBM (kurs REQ480: Mastering Requirements Management with Use Cases)

2 Cele Definicja analizy problemu i jej celi Opis aktywności analizy problemu Identyfikacja zainteresowanych stron (stakeholders) Uzyskanie zgody dotyczącej problemu Odnalezienie aktorów i definicja granic systemu Rozpoczęcie prac nad wizją projektu Wyrażenie definicji problemu Identyfikacja ograniczeń projektu Ustalenie wspólnego słownictwa 2

3 W którym miejscu dyscypliny Wymagania jesteśmy? 3

4 Aktywności i artefakty (1) 4

5 Aktywności i artefakty (2) Pierwszym krokiem analizy problemu jest uzyskanie pewności, że wszystkie strony zaangażowane w projekt zgadzają się co do problemu, który ma zostać rozwiązany (albo co do możliwości, które mają być zrealizowane przez system) W celu uniknięcia nieporozumień, ważne jest uzgodnienie wspólnej terminologii, która będzie używana przez cały czas trwania projektu Na samym początku tworzony jest słownik, który będzie utrzymywany i uściślany podczas dalszych prac 5

6 Aktywności i artefakty (3) W celu pełnego zrozumienia problemu, którym się będziemy zajmować, musimy prawidłowo ustalić, kim są zainteresowane strony i osoby (stakeholders) w koncepcyjnej wizji projektu Niektóre z tych osób użytkownicy systemu są reprezentowani jako aktorzy w modelu przypadków użycia 6

7 Aktywności i artefakty (4) Podstawowym artefaktem, w którym umieszczamy informacje z analizy problemu jest dokument wizji (vision), który identyfikuje wysokopoziomowych użytkowników lub spojrzenie na system ze strony klienta W dokumencie wizji, wstępne wysokopoziomowe wymagania identyfikują kluczowe cechy, dla spełnienia których ma być dostarczone rozwiązanie Zazwyczaj są one wyrażane jako zbiór ogólnych cech, które system mógłby posiadać w celu rozwiązania najbardziej krytycznych problemów 7

8 Aktywności i artefakty (5) Kluczowe strony zainteresowane powinny być zaangażowane w gromadzenie zbioru potencjalnych cech Popularną techniką są tzw. warsztaty wymagań (requirement workshops) Cechom tym można przypisać atrybuty takie jak zasadność, względna wartość lub priorytet, źródło wymagania, itp., tak aby można było rozpocząć zarządzanie zależnościami i planami pracy 8

9 Aktywności i artefakty (6) W celu określenia wstępnego zakresu projektu, należy uzgodnić granice systemu Analityk systemowy identyfikuje użytkowników i systemy reprezentowane jako aktorów, którzy wchodzą w interakcję z systemem 9

10 Cel analizy problemu (1) Cele analizy problemu: Lepsze zrozumienie przed rozpoczęciem właściwych prac deweloperskich Identyfikacja źródłowych przyczyn i powodów Pomoc w znalezieniu właściwego rozwiązania Uniknięcie tak, ale... (tak, spełnia wymagania, ale nie spełnia moich potrzeb) Ograniczenie dodatkowych prac (poprawek, powtórek, zaczynania od początku) Jaki jest rzeczywisty 10 problem?

11 Cel analizy problemu (2) Zrozumienie problemu jest pierwszym krokiem zrozumienia wymagań W określeniu problemu, przedmiotem jest potrzebuję, żeby... wypowiedziane przez klienta W wymaganiu przedmiotem jest system: system zapewnia... Jaki jest rzeczywisty 11 problem?

12 Co to jest problem? (1) Problem można określić jako różnice między rzeczami postrzeganymi, a pożądanymi PROBLEM postrzegany pożądany 12 Gause & Weinberg, 1989

13 Co to jest problem? (2) Jeżeli różnica pomiędzy tym, jak postrzegasz to co masz, a tym co chcesz mieć, nie istnieje, nie ma problemu. W naszym procesie musimy najpierw zrozumieć, czy w ogóle problem istnieje Ta definicja problemu różni się od wielu innych. Koncentruje się na pustce pomiędzy naszym postrzeganiem czego chcą klienci, a tym czego naprawdę pożądają. Zaletą tej definicji jest nacisk położony na wiele sposobów rozwiązania problemu: Zmiana postrzegania przez klientów tego, co już mają. Na przykład, wiele żądań poprawek otrzymywanych przez Microsoft dotyczy cech, które już istnieją Zmiana aktualnych żądań klientów. Na przykład, jeżeli klienci zrozumieją, że ich zachcianka będzie kosztować o miliony więcej, niż przewiduje ich budżet, najprawdopodobniej zechcą ograniczyć oczekiwania i skupić się na rozwiązywaniu prostszych problemów Zmiana pustki pomiędzy tym, czego klienci chcą, a czego w rzeczywistości pożądają. Rozwiązanie software'owe zazwyczaj jest próbą zmniejszenia tej luki. 13

14 Kroki analizy Identyfikacja zainteresowanych stron Zrozumienie źródłowych przyczyn i powodów Uzyskanie porozumienia w sprawie definicji problemu Identyfikacja ograniczeń nałożonych na system lub projekt Identyfikacja i walidacja rozwiązania względem przyczyn źródłowych Czy konkretne rozwiązanie dodaje nowe strony zainteresowane? Definicja granic systemu 14

15 Różne spojrzenia na problem (1) Dwa podejścia do definiowania systemu: Ktoś ma pomysł lub rozpoznał potrzebę i rozwija produkt, żeby rozwiązać problem Analiza problemu biznesowego jest często wtórna lub nieformalna Orientujemy się, że istnieje problem, który potrzebuje rozwiązania Analiza problemu biznesowego jest podstawą 15

16 Różne spojrzenia na problem (2) Problem biznesowy Identyfikacja stron zainteresowanych Analiza źródłowych przyczyn Pomysł lub możliwość rozwiązania Definicja problemu biznesowego Wybranie najlepszego rozwiązania realizującego cele (lub wielu rozwiązań) Zrozumienie problemu w kontekście celi biznesowych Zwalidowany/dopasowany problem Zidentyfikowany i zdefiniowany rzeczywisty problem Upewnienie się, że rozwiązanie jest najlepsze Zidentyfikowane najlepsze rozwiązanie Wydobycie wymagań Rozszerzenie listy stron zainteresowanych względem rozwiązania 16

17 Różne spojrzenia na problem (3) Bez względu na wybraną perspektywę początkową, zrozumienie miejsca systemu w kontekście celi organizacji jest niezwykle istotne Jeżeli nam się to nie uda, zbudujemy system, który wprowadza niewiele (lub wcale) wartości biznesowej W rzeczywistości niewłaściwy system może powstrzymać organizację od osiągnięcia celi biznesowych Częstą przyczyna porażki projektu jest rozpoczęcie z pomysłem na rozwiązanie i bezpośrednie przejście do prac deweloperskich. W tym momencie dopiero następuje właściwe przejście przez proces analizy (może być za późno) 17

18 Co to jest strona zainteresowana (stakeholder)? Strona zainteresowana: Ktoś, na kogo wynik działania systemu lub projekt produkujący system ma jakiś materialny wpływ, np. zleceniodawca, użytkownik końcowy, administrator, deweloper, tester, pracownik wsparcia, sprzedawca, bank, inwestor, organizacja standaryzacyjna, ekspert technologiczny,... Pominięcie którejkolwiek strony może stanowić o porażce projektu (na przykład system będzie zbyt skomplikowany, żeby prowadzić support) Reprezentant strony zainteresowanej: Osoba reprezentujące stronę zainteresowaną lub kilka stron zainteresowanych Reprezentanci są bezpośrednio zaangażowani w sterowanie, kształtowanie i określanie zakresu projektu 18

19 Identyfikacja stron zainteresowanych Częścią analizy problemy jest zrozumienie kto ma ten problem Należy zrozumieć kto rzeczywiście ma cel w jego rozwiązaniu, nie tylko dbając o klienta, który nam płaci Każda strona zainteresowana musi mieć reprezentanta Nie ze wszystkimi stronami należy wszystko konsultować: Niektóre strony zainteresowane są źródłem wymagań (np. użytkownicy końcowi, administratorzy), inne wcale (np. udziałowcy). 19

20 Opis stron zainteresowanych w dokumencie wizji Szczegółowy przykład z sekcji Profile Stron Zainteresowanych (Stakeholder Profiles): Strona zainteresowana Reprezentant Opis Typ Zakres odpowiedzialności Kryteria sukcesu Zaangażowanie Wytworzone dokumenty Uwagi Rejestrator Jan Kowalski Użytkownik Rejestrator zazwyczaj ma wyższe wykształcenie i zaawansowany poziom obsługi komputera. Rejestrator jest wyszkolony i doświadczony w obecnie stosowanej formie ręcznej rejestracji. Rejestrator jest odpowiedzialny za administrowanie zapisami na kursy w każdym semestrze. W zakres obowiązków wchodzi nadzór administracyjny i zarządzanie personelem wprowadzającym dane. Podstawowym obowiązkiem rejestratora będzie utrzymywanie baz danych studentów i wykładowców oraz otwieranie i zamykanie procesu rejestracji. Ponadto, biuro rejestratora będzie uczestniczyło w... Rejestrator będzie uczestniczył w projektowaniu interfejsu... Przegląd zarządzania szczególnie w odniesieniu do funkcjonalności i użyteczności cech wymaganych przez personel rejestrujący. Brak 20

21 Jak znaleźć właściwy problem, czyli jego przyczyny...

22 Jaki problem stoi za problemem? (1) Klienci nie są zadowoleni z naszych usług - czy to rzeczywiście jest właściwy problem? Jedna z metod znajdowania przyczyny źródłowej są diagram Ishikawy (diagramy przyczyn i skutków, cause and effect diagrams), zwane także diagramami rybnymi (fishbone diagrams) ości oznaczają przyczyny problemu C h cąpr d yw a t okonują n ości Postrzegana przyczyna problemu biznesowego a ne O per a cje w c o per acji y konyw n a lo t niskach lokalizacji ię cej w C hcą Z byt d lugie czekanie K ol e j k i w B r a k usług ban w n ocy k owych o ddzi ałach s ą z a długie Klienci nie są zadowoleni z naszych usług 22 Ości można rozwijać, jeżeli pojawiają się głębsze przyczyny

23 Jaki problem stoi za problemem? (2) Kiedy znajdziemy już przyczyny źródłowe, skupmy się na tych, które są najpoważniejsze. Przyczyny te należy dalej analizować na diagramie ość może stać się kregosłupem (dodajemy rozgałęzienia), można tez utworzyć nowy diagram Zazwyczaj okazuje się, że pojawia się więcej niż jeden podstawowy problem, może on mieć także wiele wymiarów i interpretacji. W takich sytuacjach najlepszym wyjściem jest konsultacja z klientem Pomagamy klientowi skupić się na problemie, który rzeczywiście musi zostać rozwiązany Kiedy mamy już listę problemów, musimy przeprowadzić analizę w celu zidentyfikowania najlepszego rozwiązania dla najważniejszych czynników. Ten krok następuje dopiero kiedy nastąpiło porozumienie dotyczące najważniejszych problemów i przyczyn źródłowych 23

24 Skup się na najpoważniejszych czynnikach prawo Pareto (1) ś y rz o k 80 % 20 % wysiłku daje 80 % korzyści 20 % wysiłek Uszereguj przyczyny. Skupienie się na najpoważniejszych powinno 24 wystarczyć do utrafienia w istotę problemu.

25 Skup się na najpoważniejszych czynnikach prawo Pareto (2) d u % Dostęp do usług w nocy Więcej lokalizacji Usługi na lotniskach Zbyt długie kolejki Prywatno ść w czasie operacji Pozostałe przyczyna 25

26 Skup się na najpoważniejszych czynnikach prawo Pareto (3) Możliwe rozwiązanie: bankomaty? Dostęp do usług w nocy Więcej lokalizacji 26

27 Szerszy kontekst problemu

28 Zrozum szerszy kontekst problemu (1) Kiedy mamy już jasne przyczyny źródłowe, należy upewnić się, że rozwiązanie jest zgodne strategicznie i operacyjnie z danym biznesem: Brak zrozumienia biznesu i jego celi zwiększa ryzyko Czy problem ma swój komponent organizacyjny lub procesowy? Czy zespół rozumie dziedzinę, w której problem się pojawia? Czy rozwiązanie problemu przedstawia możliwość ulepszenia procesu? 28

29 Zrozum szerszy kontekst problemu (2) Stosuje się tutaj modelowanie biznesowe: Identyfikuje możliwości zautomatyzowania biznesu Wskazuje narzędzia, które mogą zostać użyte Stanowi pierwszy krok przebudowy (re-engineering) bieżącego sposobu prowadzenia biznesu Kiedy można pominąć modelowanie biznesowe: Produkt jest komercyjny, a nie kontraktowy (np. MS Word) Dziedzina produktu jest dobrze znana zarówno zespołowi, jak i klientom 29

30 Dziedziny modelowania biznesowego i wymagań Modelowanie biznesowe Wymagania Połączenie pomiędzy dyscyplinami Połączenie pomiędzy dyscyplinami 30

31 Modele biznesowe (1) Dotyczą struktury i dynamiki: Procesy biznesowe (np. transakcje kupna i sprzedaży) Struktura organizacyjna (np. dział sprzedaży, dział kadr) Role i odpowiedzialności (np. brokerzy przyjmują zamówienia) Produkty (np. przetwarzanie transakcji) Dostawy Zdarzenia (np. przyjęcie zamówienia, umieszczenie zamówienia w kolejce, wysłanie potwierdzenia zamówienia) Wizualizują organizację i jej procesy Pomagają zrozumieć bieżący problem Identyfikują potencjalne ulepszenia Pomagają rozwinąć i zwalidować wymagania systemowe potrzebne dla wsparcia organizacji 31

32 Modele biznesowe (2) Modele biznesowe pozwalają zobaczyć szerszy kontekst problemu Nawet jeżeli jesteśmy skupieni na konkretnej aplikacji, modele biznesowe umożliwiają zbudowanie właściwego rozwiązania, które pasuje do problemu biznesowego 32

33 Modele biznesowe (3) Cele modelowania biznesowego: Zrozumienie bieżących problemów w organizacji docelowej i identyfikacja potencjalnych ulepszeń Zrozumienie struktury i działania organizacji, w której system ma zostać wdrożony. Model biznesowy zapewnia opis graficzny i tekstowy organizacji docelowej i jej procesów Zapewnienie, że klienci, użytkownicy końcowi i deweloperzy rozumieją organizację docelową w taki sam sposób Rozwinięcie wymagań systemowych potrzebnych dla wspierania organizacji docelowej 33

34 Modele biznesowe (4) Aby osiągnąć te cele, modelowanie biznesowe opisuje wizję organizacji docelowej. W oparciu o wizję, model biznesowy definiuje procesy, role i odpowiedzialności w ramach tej organizacji Jeżeli mamy dostępny model biznesowy, może on dostarczyć ważny wkład w proces pozyskiwania wymagań: Zapewnia kontekst dla wymagań systemowych i promuje wspólne zrozumienie potrzeb organizacji docelowej. 34

35 Wizja

36 Opis problemu w dokumencie wizji Definicja problemu Wymagania stron zainteresowanych Dokument wizji Model przyp. użycia Specyfikacja uzupełniająca Specyfikacja projektowa Specyfikacja dokumentacji użytkownika 36

37 Dokument wizji (1) Podstawowy artefakt analizy problemu Komunikuje informacje pomiędzy zarządzaniem, marketingiem, a zespołem projektowym Zapewnia wstępny odzew od klienta Ułatwia ogólne zrozumienie produktu Ustanawia zakres i priorytet wysokopoziomowych żądań i cech postulowanych przez strony zainteresowane Dokument systemowy, który opisuje, co i dlaczego produktu Dokument gwarantujący, że wszystkie strony pracują na tej samej podstawie 37

38 Dokument wizji (2) Zawartość: Opis problemu Cele systemu Identyfikacja i opis stron zainteresowanych Potrzeby użytkowników Rynki docelowe Środowiska i platformy użytkownika Cechy produktu 38

39 Szablon dokumentu wizji 1. Wstęp 2. Pozycjonowanie 3. Opis stron zainteresowanych i użytkowników 4. Zarys produktu 5. Cechy produktu 6. Ograniczenia 7. Zakresy jakości 8. Kolejność i priorytety 9. Inne wymagania produktu 10.Wymagania dokumentacji 11.Dodatek 1 atrybuty cech 39

40 Uzyskanie porozumienia na temat definicji problemu Określenie problemu: Czego dotyczy? Problem nieterminowego i niewłaściwego rozwiązywania zgłoszeń klientów... Na jakie strony zainteresowane ma wpływ (których dotyczy)?... dotyczy naszych klientów, pracowników wsparcia i techników serwisowych. Jaki ma efekt? Rezultatem są rozczarowanie klientów, odczucie niskiej jakości usług, niezadowolenie pracowników i utrata dochodu. Co oznacza skuteczne rozwiązanie? Skutecznie rozwiązanie zapewniłoby dostęp w czasie rzeczywistym do bazy rozwiązywań problemów dla pracowników wsparcia i umożliwiłoby planowanie czasowe i rozdzielanie zleceń pomiędzy techników serwisowych tylko do miejsc, gdzie bezpośredni kontakt jest absolutnie konieczny. 40

41 Identyfikacja ograniczeń (1) Ograniczenia projektu mają możliwość poważnie wpływać na zdolność skutecznego dostarczenia rozwiązania Czasami ograniczenie zachowuje się jak góra lodowa na powierzchni nie widać go zbyt dużo, jednak po dokładnym sprawdzeniu jego wpływ okazuje się bardzo istotny (być może zbyt mały, żeby zatopić statek, ale dostateczny, by zmienić jego kurs) Typy ograniczeń, które podlegają identyfikacji mogą mieć także wpływ na techniki pozyskiwania wymagań, szczególnie w przypadku ograniczeń politycznych 41

42 Identyfikacja ograniczeń (2) Środowiskowe Polityczne Ekonomiczne Techniczne Systemowe Wykonalnościowe 42

43 Identyfikacja ograniczeń (3) Przykłady: Projekt nie może kosztować więcej niż dolarów, włączając w to rozwój i wdrożenie. Wdrożenie obejmuje koszt instalacji i szkolenia System ma być wdrożony na górze lodowej w kole podbiegunowym. Dlatego musi działać bez usterek w skrajnych temperaturach arktycznych System ma być wdrożony we wszystkich biurach rządowych całej Unii Europejskiej (to nie jest ograniczenie systemowe, ale ograniczenie projektu; ma wpływ na pozyskiwanie wymagań od ludzi porozumiewających się różnymi językami) 43

44 Identyfikacja najlepszego rozwiązania biznesowego Upewnij się, że wszyscy zgadzają się co do problemu Określ możliwe (wykonalne i sensowne) rozwiązania najważniejszych kontrybuujących problemów: Techniczne, nietechniczne lub obydwa rodzaje Wybierz jedno najlepsze, które: Najlepiej rozwiązuje kluczowe przyczyny Jest zgodne z celami biznesowymi i je wspiera Wszyscy akceptują Zbierz wymagania potrzebne do implementacji rozwiązania 44

45 Identyfikacja granic systemu (1) Użytkownicy Inne systemy Nowy system System spadkowy Obsługa Komunikacja Raporty 45

46 Identyfikacja granic systemu (2) Podczas definiowania granicy systemu, należy rozważyć wszystkie istniejące zasoby, które mogą grac rolę (w tym inne i spadkowe systemy): Kto używa systemu? Kto obsługuje system? Kto otrzymuje dane wyjściowe (raporty)? Jak wygląda komunikacja z systemem? Jak możliwości nowego systemu nakładają się lub zastępują istniejący system? Jakie interfejsy system ma udostępniać dla ludzi lub systemów z zewnątrz? Którzy (które) z nich są aktorami? 46

47 Rola aktorów w identyfikacji granic systemu (1) Aktor korzysta z systemu (lub system z niego), ale sam nie stanowi części systemu. Aktor to użytkownik albo system zewnętrzny. Ponieważ aktor nie jest częścią systemu, nie trzeba budować funkcjonalności, którą aktor reprezentuje. Dlatego identyfikacja aktorów pomaga określić granice problemu, który ma zostać rozwiązany, w efekcie systemu, który ma zostać zbudowany. 47

48 Rola aktorów w identyfikacji granic systemu (2) Przykład: oprogramowanie klienckie serwerowe PC Aktor Aktor Aktor Granica systemu Aktor Aktor Aktor Granica systemu 48

49 Wspólne słownictwo Zdefiniuj wszystkie słowa i zwroty używane w dokumentach: Charakterystyczne dla biznesu lub dziedziny problemu Mogące rodzić nieporozumienia lub niejednoznaczne Rozpocznij prace nad słownikiem jak najwcześniej Kontynuuj prace nad słownikiem i dbaj o jego aktualność przez cały czas prac nad projektem 49

50 Model domenowy jako wizualizacja słownika Modelowanie domenowe stanowi podzbiór modelowania biznesowego i często jest używane w zastępstwie pełnego modelu: Szybki rozwój kluczowych obiektów biznesowych Formalizacja słownictwa Uproszczenie rozumowania na temat różnych zwrotów i pojęć Opis zależności między pojęciami Wizualna reprezentacja zależności Student 1 0..* Plan 0..* 0..4 Kurs 0..* 0..* Student Dzienny Student Zaoczny Prowadzący Przedmiot 50