Inżynieria wymagań Wykład 3 Zarządzanie wymaganiami w oparciu o przypadki użycia Część 2 Projekty informatyczne, a wymagania Opracowane w oparciu o materiały IBM (kurs REQ480: Mastering Requirements Management with Use Cases)
Cele Definicje kluczowych pojęć zarządzania wymaganiami Identyfikacja czynników przyczyniających się do sukcesu lub porażki projektu: Zależność wpływu zarządzania wymaganiami na sukces projektu Opis jakości zbiorów wymagań: Weryfikowalność, traceability, jednoznaczność Podejście RUP: workflow, role i artefakty 2
Częste sytuacje... Zrobiliśmy wszystko, Ale nie wszystko, czego Pan wymaga Brak ł. analizy czego chciałem... problemu pod kątem potrzeb zleceniodawcy lub użytkowników Dlaczego nie Brak zrozumienia powiedziałe ś nam, wymagań i że chcesz mie ć t ą zaangażowania cech ę? zleceniodawcy lub użytkowników Nikt mnie nie zapyta ł! Hmm... Chyba chodziło im, żeby to działało jako ś w ten sposób... Deweloperzy wiedzą najlepiej, wymagania nie są sformalizowane, brak zarządzania zmianami Mam pomys ł na świetn ą now ą cech ę. Możesz to dorzuci ć? Nie ma sprawy! Brak zarządzania i koordynacji 3
Wymagania Potrzeby użytkowników PROBLEM Przestrzeń problemu traceability Własności Przypadki użycia i wymagania SYSTEM który ma zostać zbudowany Przestrzeń rozwiązania Procedury testowe Projekt Dokumentacja użytkownika 4
Wymagania Proces transformacji: Przeniesienie potrzeb zleceniodawcy/ użytkowników na zbiór cech systemu Cechy transformowane są w wymagania funkcjonalne i niefunkcjonalne Szczegółowe specyfikacje są przekształcane w procedury testowe, projekt (design) i dokumentację użytkownika 5
Wymagania Traceability pozwala na: Ocenę wpływu zmiany w wymaganiach na projekt Ocenę wpływu porażki testu na wymagania (jeżeli test się nie udaje, wymaganie raczej nie jest spełnione) Zarządzanie zakresem projektu Sprawdzenie, czy wszystkie wymagania są spełnione przez implementację Sprawdzenie, czy aplikacja robi tylko to, co zostało zamierzone Zarządzanie zmianami 6
Definicje Wymaganie: Warunek, który system musi spełniać lub zdolność, którą musi wykazywać (bezpośrednio na podstawie potrzeb użytkowników lub określone w umowie, standardzie specyfikacji, itp.) Pożądana cecha, własność lub zachowanie systemu Wymagania opisują raczej co system robi, a nie jak to robi (czarna skrzynka) 7
Definicje Zarządzanie wymaganiami to systematyczne podejście do: wyrażania, organizacji i dokumentowania wymagań uzyskiwania i utrzymywania porozumienia między klientami/użytkownikami, a zespołem projektowym w sprawach dotyczących zmian w wymaganiach. Zarządzanie wymaganiami odnosi sukces tylko kiedy dopuszcza dużą dozę niepewności we wczesnych stadiach projektu; jednocześnie zapewnia coraz lepszą definicję wymagań wraz z upływem czasu. 8
Co określają wymagania? SYSTEM wejścia? wyjścia Funkcje systemu Wymagania niefunkcjonalne (np. wydajność) Ograniczenia projektowe (np. środowisko) kontekst dla tego co system robi (minimalna wiedza techniczna konieczna do wyrażenia wymagań) 9
Definicje Żądanie/potrzeba klienta lub użytkownika Niezależne od rozwiązania wyrażenie pożądanego stanu w dziedzinie rozwiązania lub problemu Cecha Widoczna z zewnątrz usługa, poprzez którą system bezpośrednio wypełnia jedno lub więcej żądań. Wymagania oprogramowania Funkcjonalne specyfikują z perspektywy czarnej skrzynki, jak rozwiązanie współpracuje i komunikuje się ze światem zewnętrznym (interakcja) Niefunkcjonalne wyrażają z perspektywy czarnej skrzynki jakoś atrybutów rozwiązania Ograniczenie Obostrzenie nałożone na projekt systemu lub proces użyty do budowy systemu 10
Przykłady system zapisów na kursy Żądanie/potrzeba klienta lub użytkownika Cecha Mniej czynności administracyjnych podczas rejestracji Wykładowca potrzebuje natychmiastowego dostępu do ocen studentów Przeglądarka przedstawia informacje o studencie w formie drzewa, szeregując je według semestrów i przedmiotów Wymagania oprogramowania Funkcjonalne przypadek użycia rozpoczyna się w momencie, kiedy student wybiera w systemie zarządzania kursami opcję zapisu na kurs... Niefunkcjonalne system ma być dostępny 99% czasu w systemie 24/7 (3.65 dnia niedostępności w ciągu roku) Ograniczenie System ma pracować na uczelnianym mainframe'ie DEC VAX 11
Zależność definicji Typy wymagań Cechy Żądania/potrzeby klienta Wymagania oprogramowania Ograniczenia projektowe Wymagania funkcjonalne Wymagania niefunkcjonalne 12 Leffingwell & Widrig, 1999
Zależność definicji D. Hatley, P. Hruschka and I. Pirbhai Process for System Architecture and Requirements Engineering" 13
Dlaczego zarządzanie wymaganiami stanowi problem? Wymagania:... Zazwyczaj nie są oczywiste lub klienci nie wiedzą czego chcą Pochodzą z wielu źródeł Nie zawsze można je wyrazić prostymi słowami lub analitycy nie potrafią opisać ich w sposób zrozumiały dla zwykłych ludzi Odnoszą się do siebie nawzajem i do innych produktów procesu inżynierii wymagania Mają unikatowe właściwości lub ich wartości Zmieniają się Są trudne to kontrolowania wraz ze wzrostem ich liczby 14
Zarządzanie wymaga strategii (1) Plan zarządzania wymaganiami (requirement management plan, plan RM): Powinien zostać opracowany w celu określenia informacji (i mechanizmów kontrolujących), które są zbierane i wykorzystywane to pomiarów, raportowania i kontrolowania zmian w wymaganiach Przed przystąpieniem do opisu wymagań projektu, należy zdecydować, jak je dokumentować i organizować Należy także zdecydować jak używać atrybutów wymagań podczas zarządzania wymaganiami wraz z rozwojem projektu Plan RM dokumentuje wszystkie decyzje odnośnie dokumentów wymagań, typów wymagań, wskazówki i strategie dla atrybutów wymagań i śledzenie wymagań (traceability) 15
Zarządzanie wymaga strategii (2) Podobnie jak słownik, plan RM jest żyjącym dokumentem. Jego rozwój rozpoczyna się wraz z początkiem projektu. Nowe pozycje są dodawane w miarę podejmowania kolejnych decyzji. W idealnej sytuacji, można użyć standardowego planu, przystosowywanego do specyfiki każdego projektu. Pozwala to przyspieszyć fazę rozpoczęcia (inception) projektu. Co znajduje się w planie RM: Typy wymagań, które zbieramy i gdzie będą zbierane, Typy atrybutów do śledzenia, Typy wymagań do śledzenia, Typy dokumentów do wytworzenia, Wytyczne do zarządzania. 16
Dlaczego należy dbać o właściwe zarządzanie wymaganiami?
Efektywne zarządzanie wymaganiami Utrzymywanie klarownych i jasno wyrażonych wymagań poprzez: Dobrą jakość wymagań, Atrybuty stosowalne do każdego typu wymagań, Traceability do innych wymagań i artefaktów projektu. Celem jest dostarczenie wysokiej jakości produktu w założonym czasie i budżecie, który spełni rzeczywiste wymagania klienta. 18
Co stanowi o jakości produktu? Stare podejście (delivered as specified): Zgadza się z dokumentami wymagań, Przechodzi testy, Rozwój (development) oparty na procesie, Oparte na czynnościach. Współczesne rozumienie: Zrozumienie wszystkich potrzeb użytkowników, Ciągła ocena, czy wszystkich artefaktów pod kątem spełniania potrzeb, Oparte na rezultatach. 19
Wymiary jakości FURPS (1) Functionality (funkcjonalność) Usability (użyteczność) Reliability (niezawodność) Performance (wydajność) Supportability (zarządzalność) Podstawowe zdolności, bezpieczeństwo, ogólność Estetyka (subiektywny czynnik ludzki), spójność, dokumentacja Częstotliwość/dotkliwośc błędów, podnoszenie po błędzie, przewidywalność, dokładność, MTBF* Szybkość, sprawność, zużycie zasobów, przepustowość, czas odpowiedzi Testability, Extensibility, Adaptability, Maintainability, Compatibility, Configurability, Serviceability, Installability, Localizability, Robustness 20 *) Mean Time Between Failures Grady, 1992
Wymiary jakości FURPS (2) Skrót FURPS oznacza tą część typów wymagań, których należy szukać Przypomina, że ważne są zarówno wymagania niefunkcjonalne (URPS), jak i funkcjonalne (behawioralne) Często stosowany FURPS+ oznacza rozszerzenie tych typów o wymagania nie objęte żadną z pięciu kategorii:...? 21
Na czas i w założonym budżecie (1) zasoby ZAKRES Ile pracy możemy wykonać? budżet czas 22
Na czas i w założonym budżecie (2) Ponieważ czas i zasoby (ludzie, fundusze, wyposażenie, itp.) są ograniczone, może wykonać tylko określony zakres prac Żeby dostarczyć produkt na czas i w budżecie, należy określić, ile pracy możemy naprawdę wykonać w ramach danego zakresu (scope), czasu, zasobów i środków finansowych Jeżeli którykolwiek z czynników się zmienia, trzeba wykonać odpowiednie dopasowania, na przykład: jeżeli powiększymy zakres, należy zwiększyć jedno z pozostałych (budżet, czas lub zasoby), jeżeli ograniczymy budżet, musimy zmniejszyć zakres przeprowadzonych prac w tym samym czasie oraz dostępne zasoby. Porażka przytrafia się najczęściej, jeżeli staramy się wcisnąć coraz więcej w zakres, nie przesuwając pozostałych punktów aby to skompensować W celu dostarczenia maksymalnej wartości należy być możliwie najbardziej dokładnym w szacunkach zasoby ZAKRES 23 budżet czas
Spełnić rzeczywiste potrzeby klientów (1) Cecha 1: System musi... Cecha 2: System musi... Cecha 3: System będzie... Cecha 4: System musi... Cecha 5: System powinien... Cecha 6: System musi Cecha 7: System musi... Cecha n: System powinien... Data rozpoczęcia projektu Zamierzona data wydania czas 24
Spełnić rzeczywiste potrzeby klientów (2) W jaki sposób uzyskujemy porozumienie na temat cech, które mają zostać włączone do projektu? Jakie potrzeby klientów one reprezentują? W jaki sposób powinny one zostać spriorytetyzowane? Co powinno znaleźć się w ramach dostarczonego produktu (delivery baseline)? Zbiór cech, które stanowią uzgodnioną podstawę dla dalszych prac, który może zostać zmodyfikowany tylko poprzez formalną procedurę 25
Wymagania umożliwiają porozumienie (1) Cel Klient użytkownicy System który ma zostać zbudowany Weryfikacja wymagań Cel pośredni (zastępczy) Wymagania 26
Wymagania umożliwiają porozumienie (2) Specyfikacja wymagań stanowi wyrażenie porozumienia, dotyczącego budowanego systemu Ponieważ zazwyczaj rzadko mamy kontakt z klientem/użytkownikami oraz niektórzy klienci często zmieniają zdanie, porozumienie należy udokumentować Specyfikacja wymagań stanowi proxy klienta powinna zawierać wszystko co jest potrzebne, aby wyeliminować potrzebę późniejszych zbędnych kontaktów w fazie implementacji Forma wyrażenie wymagań powinna być zrozumiała dla obydwu stron; wymagania: Stanowią zastępczy cel dla zespołu deweloperskiego Są podstawą walidacji i kryteriami akceptacji gotowego systemu przez klienta 27
Jakie czynniki przyczyniają się do sukcesu projektu? 28 % projektów zostaje ukończonych na czas i w zakładanym budżecie 49 % projektów wykracza poza wstępne szacunki: Przekroczenie czasu średnio o 63 % Przekroczenie kosztów średnio o 45 %. 23 % projektów zostaje porzuconych przed ukończeniem Zarządzanie wymaganiami The CHAOS ten: 1. Executive Management Support 2. User Involvement 3. Experienced Project Manager 4. Clear Business Objectives 5. Minimized Scope 6. Standard Software Infrastructure 7. Firm Basic Requirements 8. Formal Methodology 9. Reliable Estimates 10. Other Standish Group's CHAOS report of 2001. (www.standishgroup.com) 28
Rozmiar ma znaczenie... (1) Wskaźnik sukcesu (%) 60 50 40 30 20 10 less than $750K $750K to $1.5M $1.5M to $3M $3M to $6M $6M to $10M Over $10M 0 Project Size ($) Standish Group, 99 (www.standishgroup.com) 29
Rozmiar ma znaczenie... (2) Pozornie większe projekty mają większe zespoły i lepszą organizację oraz zarządzanie, czyli większą szansę na powodzenie W rzeczywistości jest odwrotnie Zalety mniejszych projektów: Mniejsze zespoły Mniej wymagań Mniej problemów z komunikacją Łatwiejsze w zarządzaniu Bardziej skupione na celach biznesowych 30
Wysoki koszt błędów w wymaganiach Reguła 1-10-100.5-1 2.5 5 10 25 100 Wymagania Projekt Kodowanie Testy jednostkowe Testy akceptacyjne Utrzymanie 200:1 Średni stosunek kosztów to 14:1 (Grady, 1989) Względny koszt naprawy błędów: Kiedy wprowadzony do kiedy naprawiony Reguła obowiązuje dla modelu kaskadowego, jednak w procesie iteracyjnym koszty także są olbrzymie. 31 Boehm, 1988
Jak pomóc projektowi osiągnąć sukces? Analiza problemu Zrozumienie problemu Uzyskanie porozumienia z klientem Klarowne wyrażenie celi biznesowych Sprecyzowanie wymagań Identyfikacja, kto korzysta z systemu (aktorzy) Określenie, jak system jest używany (przyp. użycia) Zarządzanie wymaganiami Kompletna specyfikacja wymagań Zarządzanie oczekiwaniami, zmianami i błędami Kontrola rozpełzania się zakresu (feature creep) Ścisłe określenie składu zespołu 32
Uczestniczyć powinien cały zespół Deweloperzy, testerzy i pisarze dokumentacji Pomoc w osiągnięciu odpowiednich praktyk zarządzanie wymaganiami Monitorowanie zgodności z praktykami Weryfikacja procesu rozumowania i wyrażania Dokumentowanie wymagań Uczestnictwo w przeglądach wymagań Uczestnictwo bądź przewodnictwo w CCB (Change Control Board) Przeglądy efektów traceability Weryfikacja jakości, testowalności i zupełności. 33
Wartość zależna jest od jakości
Wartość zmniejsza się w miarę ustępstw w jakości???? 35
Wartość zmniejsza się w miarę ustępstw w jakości Jakość można mierzyć na wiele sposobów (np. dostępność systemu, błędy, czasy odpowiedzi) Kolejnym wymiarem jakości jest jakość zbioru wymagań Celem jest spełnienie potrzeb klienta: Wraz ze spadkiem jakości, zdolność spełnienia tych potrzeb także spada Jeżeli system ich nie spełnia, jego wartość się obniża Powyższe przykłady jakości są obserwowalne w działającym systemie. Stanowią efekt implementacji wymagań: System nie może być lepszy niż wymagania użyte do jego specyfikacji 36
Jakość zbioru wymagań (1) Poprawny Czy stwierdzenie, że system musi coś robić jest prawdziwe? Czy każde wymaganie opisuje coś, co system musi robić? (Davis, 1993) 37 Leffingwell & Widrig (1999)
Jakość zbioru wymagań (2) Zupełny Czy opisuje wszystkie istotne wymagania, na których zależy użytkownikowi? Czy pokrywa nie tylko funkcjonalności, ale także wydajność, ograniczenia projektowe, atrybuty, czy interfejsy zewnętrzne? Czy wszystkie zakresy wartości wejściowych (ze wszystkich możliwych scenariuszy) zostały zidentyfikowane? Czy wszystkie tabele, ilustracje i diagramy są w pełni opisane, posiadają poprawne odniesienia i definicje pojęć oraz jednostek? 38 Leffingwell & Widrig (1999)
Jakość zbioru wymagań (3) Spójny Czy nie istnieją konflikty między wymaganiami? Czy nie istnieją konflikty między dokumentami (np. diagramem UC, a specyfikacją uzupełniającą)? 39 Leffingwell & Widrig (1999)
Jakość zbioru wymagań (4) Jednoznaczny Czy możliwa jest wyłącznie jedna interpretacja każdego wymagania? Czy w wątpliwych przypadkach wprowadzono odpowiednie diagramy, ilustracje i przykłady? Czy charakterystyczne dla dziedziny biznesowej lub wieloznaczne słowa i zwroty zostały prawidłowo zdefiniowane w słowniku? Przykład: Mary had a little lamb 40 Leffingwell & Widrig (1999)
Jakość zbioru wymagań (4a) Have Lamb Interpretation 1a 1a Mary owned a little sheep under one year of age or without permanent teeth. 4a 1a Mary acquired a little sheep under one year of age or without permanent teeth. 5a 1a Mary is the person who owned a little sheep under one year of age or without permanent teeth. 10a 1a Mary held a little sheep under one year of age or without permanent teeth in a position of disadvantage. 10b 1a Mary tricked a little sheep under one year of age or without permanent teeth. 12 1b Mary gave birth to a young antelope. 12 2a Mary is (or was) the mother of a particular small, gentle person. 13 3a Mary ate a little of the flesh of lamb. 14 2c Mary bribed a small person trading in securities who was easily cheated. Przykład: Mary had a little lamb 1a: To hold in possession as property 4a: To acquire or get possession of: OBTAIN (best to be had) 4c: ACCEPT; to have in marriage 5a: To be marked or characterized by (have red hair) 10a: To hold in a position of disadvantage or certain defeat 10b: TRICK, FOOL (been had by a partner) 12: BEGET, BEAR (have a baby) 13: To partake of (have dinner) 14: BRIBE, SUBORN (can be had for a price) 1a: A young sheep esp. less than one year old or without permanent teeth 1b: The young of various other animals (as smaller antelopes) 2a: A person as gentle or weak as a lamb 2b: DEAR, PET 2c: A person easily cheated or deceived especially in trading securities 3a: The flesh of lamb used as food 41
Jakość zbioru wymagań (4b) Zbyt daleko posunięta jednoznaczność w wymaganiach często obniża ich zrozumienie i alienuje klientów i użytkowników Całkowite usunięcie niejednoznaczności można osiągnąć np. przez użycie wzoru matematycznego, co jednak uczyni wymaganie nieczytelnym dla większości odbiorców Celem jest odnalezienie złotego środka Zrozumiałość 42 Niejednoznaczność
Jakość zbioru wymagań (5) Weryfikowalny Czy może być skończonym kosztem zweryfikowany przez człowieka lub maszynę? Czy każde wymaganie jest weryfikowalne? Przykłady czy te stwierdzenia są weryfikowalne? Jeżeli nie, jak można je lepiej wyrazić? System obsługuje do 1000 użytkowników jednocześnie System powinien odpowiedzieć na dowolne zapytanie w 500 ms Kolor powinien być łagodnym odcieniem zieleni System musi być dostępny 24/7 System musi eksportować dane w formacie CSV 43 Leffingwell & Widrig (1999)
Jakość zbioru wymagań (6) Oznaczony pod względem ważności i stabilności Czy może być posortowany według ważności dla klienta i stabilności samych wymagań? Czy każde wymaganie zostało oznaczone w odpowiedni sposób? 44 Leffingwell & Widrig (1999)
Jakość zbioru wymagań (7) Modyfikowalny Czy zmiany nie wpływają na strukturę i styl zbioru? Czy zidentyfikowano nadmiarowość, zminimalizowano ją i użyto w zamian odniesień? 45 Leffingwell & Widrig (1999)
Żądania/potrzeby Jakość zbioru wymagań (8) Cechy Traceable Czy można odnaleźć początek i powód każdego wymagania? Czy przyczyna wymagania jest jasna? Przypadki użycia Czy każde wymaganie ma czytelny identyfikator? Czy jest ono odróżnione od drugorzędnych stwierdzeń w zbiorze wymagań? Czy istnieje backward traceability dostępna poprzez jawne odwołanie do poprzednich artefaktów? Czy istnieje forward traceability dla artefaktów wynikających ze zbioru wymagań (np. dla przypadków testowych)? Dokumenty uzupełniające 46 Leffingwell & Widrig (1999)
Jakość zbioru wymagań (9) Zrozumiały Czy zbiór jest zrozumiały dla klienta i deweloperów? Czy w wątpliwych przypadkach wprowadzono odpowiednie diagramy, ilustracje i przykłady? Czy charakterystyczne dla dziedziny biznesowej lub wieloznaczne słowa i zwroty zostały prawidłowo zdefiniowane w słowniku? 47 Leffingwell & Widrig (1999)
RUP jako framework do zarządzania wymaganiami 48
Workflow dyscypliny Requirements 49
Role i artefakty 50