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

Transkrypt

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

2 Cele Identyfikacja źródeł żądań stron zainteresowanych Opis artefaktu żądań strony zainteresowanej Techniki pozyskiwania żądań stron zainteresowanych: Burza mózgów Identyfikacja wymagań ze specyfikacji opracowanej przez klienta 2

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

4 Czynności i artefakty (1) 4

5 Czynności i artefakty (2) W procesie RUP bieżącym celem jest pozyskanie (wydobycie) informacji o stron zainteresowanych projektu Informacje te można postrzegać jako listę życzeń używaną jako podstawowe dane do definiowania przypadków użycia i dokumentacji uzupełniającej Ta część workflow odbywa się głównie podczas faz rozpoczęcia (inception) i opracowania (elaboration) 5

6 Czynności i artefakty (3) Niemniej jednak, żądania stron zainteresowanych powinny być gromadzone przez cały czas trwania projektu poprzez przeglądy żądań zmian w procesie CRM (Change Request Management) Należy być świadomym nadchodzących żądań stron w całym cyklu życia projektu, abyśmy przez cały czas mieli pewność, że realizujemy ich rzeczywiste potrzeby 6

7 Czynności i artefakty (4) Kluczową aktywnością jest pozyskiwanie żądań stron i określanie żądanych cech systemu Podstawowe rezultaty są zbiorem spriorytetyzowanych potrzeb i cech stron zainteresowanych, a także przypisane im atrybuty Te rezultaty umieszcza się w dokumencie wizji Ponadto, w tym workflow dyskutuje się system pod kątem przypadków użycia i aktorów Kolejnym istotnym produktem jest zaktualizowany słownik ułatwiający komunikację w ramach zespołu 7

8 Jakie są źródła wymagań? (1) Partnerzy Klienci Specyfikacja wymagań Modele biznesowe Plany biznesowe Cele osobiste Analitycy Użytkownicy Wstępne żądania Raporty błędów Żądania zmian Dziedzina problemowa Wizyty u klienta Eksperci dziedziny Analitycy przemysłowi 8 Informacje o konkurencji

9 Jakie są źródła wymagań? (2) Należy odnaleźć żądania od wszystkich zainteresowanych stron i okreslić, w jaki sposób i czego dotyczą Pomimo, że rolą odpowiedzialną za zbieranie tych informacji jest analityk systemowy, wielu innych ludzi ma w tym udział: marketingowcy, użytkownicy, klienci każdy kto jest stroną zainteresowaną projektu 9

10 Jakie są źródła wymagań? (3) Inne przykłady zewnętrznych źródeł wymagań: Statement of work (SOW, plan pracy) Oferta przetargowa (request for proposal, RFP) Stwierdzenie misji (mission statement) Stwierdzenie problemu (problem statement) Reguły biznesowe Akty prawne i rozporządzenia Systemy spadkowe Modele biznesowe Sesji i warsztaty pozyskiwania wymagań... 10

11 Jak wygląda proces? (1) Wymagania ad hoc od klienta przekazane zespołowi Klient Specyfikacja wymagań Zespół projektowy Odrzucenie przez klienta Poprawiona wersja Ponowne odrzucenie przez klienta Kolejna poprawiona wersja Akceptacja przez klienta 11

12 Jak wygląda proces? (2) Tradycyjne podejście do opracowywania specyfikacji wymagań kładzie nacisk na sukces w pierwszym podejściu... W nowoczesnych technikach produkcji oprogramowania mamy świadomość, że specyfikacja będzie przez cały czas (w pewnym sensie) błędna: I prawie zawsze ponosi porażkę z podstawowych przyczyn Przez cały czas trwania projektu staramy się odnaleźć najlepsze sposoby obniżenia ryzyka w miarę postępów prac Pomiędzy klientem (w właściwie - stronami), a nami powinna przez cały czas odbywać się dyskusja do czasu osiągnięcia zgody dotyczącej wymagań 12

13 Jak wygląda proces? (3) Niektórzy każde odrzucenie naszych propozycji postrzegają jako porażkę w specyfikowaniu wymagań Należy do tego podejść w inny sposób: każde odrzucenie to nowe informacje, które zdobywamy Kiedy klient mowi, że coś mu się nie podoba, daje nam ważne informacje dotyczące tego, co chce mieć w zamian Proces odrzucania pomaga klientowi skupić się na rzeczach istotnych dla jego organizacji 13

14 Jakie problemy możemy napotkać? Strony zainteresowane: Nie wiedzą, czego naprawdę chcą Nie potrafią wyrazić, czego chcą Myślą, że wiedzą czego chcą, ale nie widzą tego w dostarczonym produkcie Analitycy Mają z góry założone prawidłowe (i jedyne słuszne) rozwiązanie Myślą, że rozumieją problemy użytkowników lepiej niż użytkownicy Każdy... widzi rzeczy ze swojego punktu widzenia wierzy, że wszyscy inni mają jakieś motywacje polityczne 14

15 Wyrażanie potrzeb stron zainteresowanych (1) O, taki dinks by się przydał Widziałem w telewizji... Właśnie takie jak to, ale inne... Dobrze by było... I żeby tło było różowe...zgodny ze standardem CSQ-234/4 System musi... Chcę, żeby... ` 15

16 Wyrażanie potrzeb stron zainteresowanych (2) Cechą ludzkiej natury jest przechodzenie do trybu rozwiązania Dzieje się tak, ponieważ podczas wydobywanie potrzeb od stron zainteresowanych, zazwyczaj otrzymujemy je wyrażone jako cechy zamiast określenia, czego potrzebują od rozwiązania w celu rozwiązania problemu biznesowego 16

17 Wyrażanie potrzeb stron zainteresowanych (3) Co należy zrobić z potrzebami wyrażonymi jako cechy? Powiedzieć klientowi: wstrzymaj się, dojdziemy do tego później? Otóż na tym etapie wszystkie żądania klientów powinny zostać odnotowane W odpowiednim czasie należy je zwalidować pod kątem utrzymania ważności i utworzyć z nich wymagania cech Opis nowej cechy może być identyczny z tekstem żądania strony 17

18 Wyrażanie potrzeb stron zainteresowanych (4) Żeby zrozumieć potrzebę kryjącą się za żądaniem wyrażonym jako cecha, należy przeprowadzić rodzaj analizy problemu, na przykład: System śledzenia usterek powinien zapewnić raport trendu statusu projektu Potrzeba została wyrażona jako cecha Żeby zrozumieć potrzebę wyrażoną jako cechę, zapytajmy dlaczego? Odpowiedź mogłaby brzmieć: potrzebujemy dowiedzieć się, czy usterki nie pojawiają się szybciej niż są usuwane To jest rzeczywista potrzeba pod-problem, który będziemy rozwiązywać 18

19 Wyrażanie potrzeb stron zainteresowanych (5) Bez względu na wszystko, należy odnotować każde żądanie (cechę czy potrzebę) i przeprowadzić je przez standardowy proces akceptacji zanim zostanie włączone do systemu Żądania stron wyrażone jako cechy wymagają trochę więcej analizy, żeby sprawdzić czy pozostają ważne i czy są zgodne z celami biznesowymi systemu 19

20 Artefakt żądań stron zainteresowanych (1) Wymagania stron zainteresowanych Dokument wizji Model przyp. użycia Specyfikacja projektowa Specyfikacja uzupełniająca Specyfikacja dokumentacji użytkownika 20

21 Artefakt żądań stron zainteresowanych (2) Właścicielem są strony zainteresowane Zawiera wszystkie żądania stron zainteresowanych Skonsolidowany z wielu źródeł: Maile, nieformalne rozmowy, specyfikacja wymagań klienta, notatki, arkusze, itp. Duża trudność w zarządzaniu (istnieją wyspecjalizowane narzędzia/bazy danych, np. RequisitePro) Używany przez zespół projektowy w celu wydobycia cech i wymagań oprogramowania Może zawierać odniesienie do dowolnych typów źródeł zewnętrznych 21

22 Techniki pozyskiwania żądań stron zainteresowanych (1) Przeglądy specyfikacji wymagań klienta Warsztaty wymagań Warsztaty przypadków użycia Burze mózgów i redukowanie pomysłów Wywiady Kwestionariusze Odgrywanie ról Prototypy Storyboards... 22

23 Techniki pozyskiwania żądań stron zainteresowanych (2) Takie techniki są użyteczne dla gromadzenia informacji o potrzebach stron, przydają się z równie dobrym skutkiem przy pozyskiwaniu wymagań cech lub szczegółowych wymagań oprogramowania Wiele technik może być używanych jednocześnie (np. podczas warsztatów, kiedy wszyscy są zebrani, można przeprowadzić burzę mózgów lub można wykonać szkice przyszłego systemu) 23

24 Przeglądy specyfikacji wymagań klienta (1) Czasami zespoły projektowe otrzymują dokumenty wymagań bezpośrednio od klienta, zwłaszcza w przypadku kontraktowania prac W takim przypadku, przeglądy specyfikacji klienta są bardzo istotne przy wyznaczaniu tego, co naszym zdaniem ma zostać określone jako wymaganie Zidentyfikowane wymagania muszą być następnie zweryfikowane zwrotnie przez klienta. Należy określić i rozwiązać wszelkie problemy 24

25 Przeglądy specyfikacji wymagań klienta (2) Pamiętajmy, kto napisał specyfikację i z czyjej perspektywy problem został opisany Wstępne i przeglądowe sekcje specyfikacji są ważne dla ogólnego zrozumienia dokumentu. Te sekcje raczej nie powinny zawierać wymagań, ale mogą się tam znaleźć jakie zagubione egzemplarze 25

26 Przeglądy specyfikacji wymagań klienta (3) Zidentyfikuj wymagania Rozpoznaj i oznacz: Zachowania aplikacji Atrybuty behawioralne Problemy i założenia Pytaj klienta 26

27 Burze mózgów (1) Reguły burzy mózgów: Jasno określcie cele sesji Wytwórzcie tyle pomysłów, ile jest tylko możliwe Pozwólcie szaleć wyobraźni Nie pozwalajcie na krytykę ani debaty (mogą powstrzymać ludzi od wyrażania swoich pomysłów) Łączcie i mieszajcie pomysły (inspiracja pomysłami innych) 27

28 Burze mózgów (2) Technika proces czterostopniowy Wyburzujcie cechy, które nowy system ma realizować. Naklejcie wszystkie na ścianie (sticky notes) Sklasyfikujcie naklejki: Ten proces musi zostać przeprowadzony bez rozmów Poproście każdego, żeby pogrupował naklejki względem cechy, które opisują Można w tym momencie dodać dodatkowe naklejki, jednak nadal nikt nie może się odzywać poza animatorem Powinniśmy uzyskać w ten sposób ok % poprawnej klasyfikacji 28

29 Burze mózgów (3) Technika proces czterostopniowy (c.d.) Nazwijcie cechy: Animator odczytuje na głos naklejki z każdej grupy i pomaga grupie nazwać cechę Porządkujmy naklejki, przenośmy je do odpowiednich grup, usuwajmy zbędne Powinniśmy być w stanie poprawnie dokończyć klasyfikację otrzymując kilkanaście grup Spriorytetyzujcie cechy: Bezwzględnie istotne jest, żeby zrozumieć i odnaleźć kluczowe cechy, które system ma wspierać Można posłużyć się jakimś sposobem głosowania 29

30 Burze mózgów (4) Zalety Użyteczne w każdej sytuacji i w każdym czasie Dobre dla grup Dobre dla wysokopoziomowych pojęć i założeń Dogodne do automatyzacji Wady Podatne na zjawiska związane z grupą Niesystematyczne (w klasycznym rozumieniu) 30 Takeda et al. 1993

31 Redukowanie pomysłów (1)...tnij i organizuj 31

32 Redukowanie pomysłów (2)...tnij i organizuj Diagramy afiniczne (diagramy powinowactwa, pokrewieństwa): 32

33 Redukowanie pomysłów (3)...tnij i organizuj Diagramy afiniczne (c.d.): 33 Zarządzanie jakością, pod red. W. Ładońskiego i K. Szołtysek, Wydawnictwo Uniwersytetu Ekonomicznego, Wrocław 2008

34 Redukowanie pomysłów (4)...tnij i organizuj Diagramy afiniczne (c.d.): Są używane do porządkowania efektów burzy mózgów Proces ma charakter twórczy, mniej logiczny Najpierw bez rozmów i konsultacji Potem dyskusja, nazywanie grup i korekty klasyfikacji: Często jedna z naklejek stanowi nazwę grupy 34

35 Redukowanie pomysłów (5)...priorytetyzowanie Priorytetyzowanie może odbyć się dopiero kiedy wszystkie pomysły są uporządkowane i pogrupowane Głosowanie: Kumulacyjne - kupowanie pomysłów (problem jedna osoba przeznacza wszystkie swoje głosy na drugorzędny i niepopularny pomysł) Głosy pojedyncze Etykietowanie, np. krytyczny, ważny, użyteczny z odpowiednimi wagami Stosowanie kryteriów Ważonych Nieważonych 35

36 Kryteria wyboru techniki pozyskiwania wymagań Przeznaczenie wymagań Typy wiedzy Różne metody pozyskują różne typy wiedzy (zachowanie, procesy i dane) Wewnętrzne filtrowanie wiedzy Specyfikacje projektu i implementacji Wybór gotowych pakietów (off-the-shelf) Formalna umowa nabycia systemu Niektóre rodzaje wiedzy można łatwo wydobyć z pamięci, w przeciwieństwie do innych Kontekst pozyskiwania Środowisko może mieć istotny wpływ na techniki pozyskiwania 36 Maiden N.A.M. & Rugg G., 1996