Specyfikacja wymaga uytkownika Dr Karolina Muszyska Agenda 1

Specyfikacja wymagań użytkownika Dr Karolina Muszyńska

Agenda 1. Definicja wymagań i dlaczego inżynieria wymagań jest trudna i tak bardzo ważna 2. Kryteria dobrej specyfikacji wymagań 3. Elementy składowe inżynierii wymagań 4. Poziomy i rodzaje wymagań 5. Zagrożenia związane z wymaganiami i techniki ich ograniczania 6. Techniki pozyskiwania wymagań 2

Co to są wymagania? � Potrzeby/życzenia użytkowników/interesariuszy � Określenie tego co system powinien robić, jak ma się zachowywać, jakie właściwości musi posiadać, jaką jakością musi się cechować oraz jakie są ograniczenia w stosunku do samego systemu jak i do procesu jego wytworzenia 3

Dlaczego inżynieria wymagań jest skomplikowanym zagadnieniem? Inżynieria wymagań to skomplikowane zagadnienie, gdyż w określaniu każdego wymagania biorą udział aż trzy strony: zamawiający (określany jako ‘użytkownik’), wykonawca (który będzie projektował i implementował system), oraz autor-analityk (który będzie dokumentował wymagania). Zazwyczaj sytuacja wygląda tak, że zamawiający rozumie problem, który trzeba rozwiązać przy użyciu systemu ale nie wie jak wytworzyć system. Wykonawca rozumie narzędzia i techniki wymagane do stworzenia i utrzymania systemu ale nie rozumie problemu, który system ma rozwiązać. Autor-analityk musi stworzyć opracowanie, które w jedno-znaczny sposób komunikuje wytwórcy czego potrzebuje zamawiający. Zatem mamy do czynienia z fundamentalnym problemem komunikacyjnym. Dodatkowo sytuację utrudnia różnorodność interesariuszy (managerowie różnych szczebli, użytkownicy). 4

Dlaczego inżynieria wymagań jest tak ważna? Inżynieria wymagań jest ważna, gdyż zaniedbania w tym obszarze mają ogromny wpływ na powodzenie realizacji projektu i mogą doprowadzić do następujących konsekwencji: � system będzie kosztował więcej niż zakładano i/lub będzie dostarczony później niż zakładano, � system nie zaspokoi oczekiwań zamawiającego, � koszty utrzymania i aktualizacji systemu będą wysokie, � system może być niepewny i podatny na błędy, � reputacja wykonawcy może zostać nadszarpnięta, gdyż to zwykle zespół wykonawczy uznawany jest za odpowiedzialny za niepowodzenie projektu. 5

Dlaczego inżynieria wymagań jest tak ważna? � � Główną konsekwencją problemów związanych z wymaganiami jest konieczność wprowadzania przeróbek. Przeróbki często pochłaniają od 30 do 50% łącznych kosztów związanych z programowaniem, a błędy w definiowaniu wymagań mogą odpowiadać za 70 do 85% kosztów ponoszonych na wprowadzanie poprawek. Zatem opracowywanie lepszych wymagań jest inwestycją na przyszłość, a nie tylko kosztem. Zapobieganie błędom w wymaganiach oraz wczesne ich wyłapywanie bez wątpienia wywiera efekt dźwigni na zredukowanie zakresu prac naprawczych. 6

Kryteria dobrej specyfikacji wymagań Źródłem kryteriów stanowiących o jakości dokumentacji wymagań jest standard IEEE 830. 7

Kryteria dobrej specyfikacji wymagań � Poprawność Każde wymaganie powinno dokładnie opisywać cechę systemu, która zaspokoi potrzebę danego interesariusza, oraz jasno definiować funkcjonalność, którą należy zaimplementować. Aby zapewnić poprawność należy porównać specyfikację wymagań z innymi dokumentami projektu, standardami i regulacjami, których system musi przestrzegać (np. nie można zawrzeć żadnych wymagań, które będą sprzeczne z polskim prawem) � Kompletność Specyfikacja wymagań jest kompletna tylko wtedy, gdy spełnione są trzy warunki: 1. zawiera wszystkie istotne wymagania (nie tylko funkcjonalne, lecz również pozafunkcjonalne), 2. określa odpowiedź systemu na każdą informację wejściową, dla danych zarówno poprawnych, jak i niepoprawnych, 3. zawiera referencje do wszystkich diagramów, tabel, pojęć słownikowych 8

Kryteria dobrej specyfikacji wymagań � Spójność rozumiemy jako spójność wewnętrzną, czyli np. zgodność z dokumentem wyższego poziomu. Niespójność może wynikać z: ◦ konfliktów pomiędzy opisywanymi obiektami: np. jedno wymaganie mówi, że zestawienie danych ma być w formie tabelarycznej, natomiast drugie, że w formie tekstowej i to wyłącznie na wydruku, ◦ konfliktów logicznych pomiędzy czynnościami: np. jedno wymaganie mówi, że system wyliczy wartość wg wzoru X, a drugie stwierdzi, że ta wartość ma być wyliczona wg wzoru Y, ◦ używania różnych terminów do opisu tych samych obiektów. 9

Kryteria dobrej specyfikacji wymagań � Uporządkowanie według ważności Uporządkowanie to określenie priorytetów, które ułatwia programistom podjęcie właściwych decyzji dot. architektury oraz skupienia się na najważniejszych wymaganiach. Dzięki priorytetom wymagań, można prościej rozwiązać konflikty w przypadku niespójności wewnętrznej. Pomaga też wybrać te obszary specyfikacji wymagań, które raczej nie ulegną już zmianie i mogą być implementowane w pierwszej kolejności. � Jednoznaczność Specyfikacja jest jednoznaczna, gdy każde wymaganie można zinterpretować tylko w jeden sposób; nie ma miejsca na domyślanie się i wybieranie jednej „najbardziej prawdopodobnej” alternatywy. 10

Kryteria dobrej specyfikacji wymagań � Weryfikowalność Polega na tym, aby było możliwe w jednoznaczny sposób powiedzieć, że dane wymaganie zostało wykonane, lub sprawdzić, czy zostało wykonane we właściwy sposób. Czyli innymi słowy, aby wymaganie można było pokryć przypadkami testowymi i przetestować. � Modyfikowalność Wymagania mogą się zmienić. Tym samym powinna móc się zmieniać dokumentacja wymagań. Dokumentacja jest modyfikowalna, jeśli jej struktura i styl pozwalają dokonać w niej zmian w prosty, kompletny i spójny sposób. � Możliwość śledzenia powiązań Możliwość zarządzania referencjami pomiędzy wymaganiami, a innymi artefaktami. 11

Kryteria dobrej specyfikacji wymagań � Wykonalność Możliwość zaimplementowania każdego wymagania w granicach znanych możliwości i ograniczeń systemu oraz jego środowiska operacyjnego, a także przy uwzględnieniu ograniczeń projektu wynikających z czasu, budżetu i liczby pracowników. � Niezbędność Wymagania powinny opisywać cechy systemu, które zapewniają interesariuszom uzyskanie oczekiwanej przez nich wartości biznesowej, wyróżniają produkt na rynku albo są niezbędne ze względu na zachowanie zgodności z zewnętrznymi standardami, politykami bądź przepisami. Każde wymaganie powinno wywodzić się ze źródła, które jest uprawnione do zgłaszania wymagań. 12

Elementy inżynierii wymagań 13

Pozyskiwanie wymagań � Obejmuje wszystkie aktywności związane z identyfikowaniem wymagań, takie jak rozmowy, warsztaty, analizowanie dokumentacji, prototypowanie itd. Główne czynności do wykonania to: ◦ Identyfikowanie spodziewanych klas użytkowników produktu oraz pozostałych interesariuszy. ◦ Zrozumienie zadań użytkowników oraz celów biznesowych, które idą w parze z tymi zadaniami. ◦ Poznanie środowiska, w którym będzie używany nowy produkt. ◦ Współpraca z osobami reprezentującymi każdą z klas użytkowników w celu zrozumienia ich potrzeb funkcjonalnych oraz oczekiwań co do jakości produktu. 14

Analiza wymagań � Wiąże się z osiąganiem pełniejszego i dokładniejszego zrozumienia poszczególnych wymagań oraz z przedstawianiem tych wymagań na wiele różnych sposobów. Najważniejsze czynności do wykonania w tym zakresie to: ◦ Analizowanie informacji otrzymywanych od użytkowników w celu odróżnienia celów od wymagań funkcjonalnych, oczekiwań jakościowych, reguł biznesowych, sugerowanych rozwiązań oraz pozostałych informacji. ◦ Dekompozycja wymagań wysokopoziomowych na wymagania o pożądanym poziomie szczegółowości. ◦ …. 15

Analiza wymagań � Najważniejsze czynności do wykonania w tym zakresie to: ◦ Identyfikowanie wymagań funkcjonalnych na podstawie informacji o innych wymaganiach. ◦ Zrozumienie względnej ważności atrybutów jakościowych. ◦ Przypisanie wymagań do składników oprogramowania zdefiniowanych w architekturze systemu. ◦ Negocjowanie priorytetów implementacji. ◦ Identyfikowanie luk w wymaganiach lub wymagań zbędnych w odniesieniu do zdefiniowanego zakresu. 16

Specyfikowanie wymagań � Specyfikowanie wymagań obejmuje reprezentowanie oraz przechowywanie wiedzy zgromadzonej na temat wymagań w trwałej i dobrze zorganizowanej formie. Główną aktywnością w tym zakresie jest: ◦ Przekształcenie zgromadzonych potrzeb użytkownika na sformułowane pisemnie wymagania oraz diagramy umożliwiające ich zrozumienie, przeglądanie oraz wykorzystywanie przez docelowych odbiorców. 17

Walidacja wymagań � Walidacja wymagań służy potwierdzeniu, że zgromadzono właściwy zestaw informacji na ich temat, które pozwolą programistom utworzyć rozwiązanie umożliwiające osiągnięcie celów biznesowych. Najważniejsze czynności to: ◦ Dokonanie przeglądu udokumentowanych wymagań w celu zidentyfikowania ewentualnych problemów, zanim zespół programistów przyjmie je do realizacji. ◦ Opracowanie testów akceptacyjnych oraz kryteriów weryfikujących, czy produkt bazujący na wymaganiach spełni potrzeby klienta oraz zapewni osiągnięcie celu biznesowego. 18

Zarządzanie wymaganiami � Aktywności związane z zarządzaniem wymaganiami obejmują: ◦ Definiowanie bazy dla wymagań — obrazu chwili reprezentującego uzgodniony, sprawdzony i zatwierdzony zbiór wymagań funkcjonalnych i pozafunkcjonalnych, często dotyczący konkretnego wydania produktu albo iteracji. ◦ Ocena wpływu proponowanych zmian w wymaganiach oraz kontrolowane wprowadzanie zatwierdzonych zmian do projektu. ◦ Bieżące utrzymywanie zgodności planów projektu z wymaganiami w miarę rozwijania się tych drugich. ◦ …. 19

Zarządzanie wymaganiami � Aktywności związane z zarządzaniem wymaganiami obejmują: ◦ Ustalanie nowych zadań w oparciu o szacowany wpływ, jaki mogą wywrzeć zmiany wprowadzane w wymaganiach. ◦ Definiowanie relacji oraz zależności zachodzących między wymaganiami. ◦ Odnoszenie poszczególnych wymagań do związanych z nimi projektów, kodu źródłowego i testów. ◦ Śledzenie statusów wymagań oraz zmian w aktywnościach na wszystkich etapach projektu. 20

Granica między opracowywaniem wymagań a zarządzaniem nimi 21

Poziomy wymagań � Wymagania biznesowe ◦ opisują, dlaczego organizacja implementuje system; są to korzyści biznesowe, jakie organizacja chce osiągnąć � Wymagania użytkowników/interesariuszy ◦ określają możliwe do osiągnięcia cele lub zadania, jakie będą musieli realizować użytkownicy za pomocą produktu; opisują, co użytkownicy będą mogli robić za pomocą systemu � Wymagania funkcjonalne ◦ definiują zachowania, jakie w określonych sytuacjach będzie wykazywać produkt; opisują, co programiści powinni zaimplementować, aby użytkownicy mogli wykonywać swoje obowiązki � Wymagania pozafunkcjonalne ◦ określają nie to, co system robi, ale jak dobrze to robi; mogą opisywać ważne charakterystyki i właściwości systemu, w tym jego dostępność, użyteczność, bezpieczeństwo, wydajność i wiele innych cech 22

Poziomy wymagań 23

Ryzyko związane z wymaganiami 24

Pozyskiwanie wymagań � Niejasna wizja produktu i pełzający zakres projektu ◦ Napisz dokument wizji i zakresu, zawierający wymagania biznesowe i wykorzystuj go przy podejmowaniu decyzji zmieniających zakres projektu � Ograniczanie czasu poświęcanego na opracowywanie wymagań ◦ Zapisuj ile faktycznie czasu zajmuje opracowywanie wymagań, żeby móc ocenić czy zaproponowana ilość czasu wystarczy � Niewystarczające zaangażowanie klienta ◦ Zidentyfikuj interesariuszy, klientów i wyznacz przedstawiciela każdej klasy użytkowników ◦ Wyznacz kluczowych interesariuszy na mistrzów produktów i pilnuj czy się wywiązują ze swoich obowiązków � Braki w kompletności i poprawności specyfikacji wymagań ◦ Zbieraj wymagania, które przekładają się na wymagania biznesowe ◦ Wymyślaj scenariusze, pisz testy, proś użytkowników, żeby definiowali własne kryteria akceptacji, twórz prototypy ◦ Zachęcaj klienta do udziału w ocenianiu wymagań i modeli 25

Pozyskiwanie wymagań � Niepewność wymagań dotyczących produktów innowacyjnych ◦ Kładź duży nacisk na badania rynkowe i tworzenie prototypów ◦ Korzystaj z grup fokusowych w celu uzyskania opinii klientów na temat wizji innowacyjnego produktu � Niedostateczne zdefiniowanie wymagań pozafunkcjonalnych ◦ Wypytaj klienta o wymagania pozafunkcjonalne, udokumentuj je i określ ich kryteria akceptacji � Brak porozumienia z klientami co do wymagań ◦ Określ kim są główni klienci, zdobądź odpowiednią reprezentację klientów (wyznaczając mistrzów produktów) i ich zaangażowanie ◦ Poproś przedstawicieli interesariuszy o ocenę wymagań � Wymagania niewyartykułowane ◦ Spróbuj zidentyfikować założenia, które mogą przyjmować klienci ◦ Zachęcaj klientów do dzielenia się swoimi przemyśleniami (spytaj np. co sprawiłoby, że odrzuciliby produkt) 26

Pozyskiwanie wymagań � Istniejące produkty w roli źródła wymagań (projekty ulepszające i zastępujące) ◦ Zastosuj inżynierię odwrotną w celu pozyskania wymagań z istniejących aplikacji � Rozwiązania przedstawiane jako potrzeby ◦ Staraj się poznać rzeczywiste intencje – wymagania użytkownika � Brak zaufania między stroną biznesową a zespołem programistycznym ◦ Staraj się zachowywać, rozmawiać i odnosić do klienta w sposób, który będzie budował zaufanie i wzajemny szacunek 27

Analiza wymagań � Brak priorytetyzacji wymagań ◦ Upewnij się, że każde wymaganie uzyskało swój priorytet i oceniaj priorytety nowych wymagań � Technicznie trudne funkcje ◦ Oceniaj wykonalność każdego wymagania ◦ Śledź statusy wykonania poszczególnych wymagań, aby w razie potrzeby podjąć działania korygujące ◦ Twórz prototypy dla nowych, nieznanych i ryzykownych wymagań � Nieznane technologie, metody, języki, narzędzia albo sprzęt ◦ Nie bagatelizuj czasu wymaganego na zapoznanie się z nowymi technologiami i technikami potrzebnymi do realizacji wymagań ◦ Zapewnij dostateczny czas i możliwości na naukę, eksperymenty i możliwe początkowe niepowodzenia 28

Specyfikacja wymagań � Niewłaściwe zrozumienie wymagań ◦ Powierzaj programistom, testerom i klientom przeprowadzenie przeglądów koleżeńskich wymagań ◦ Doświadczeni analitycy biznesowi powinni napisać wysokiej jakości specyfikację ◦ Przeglądaj i analizuj modele i prototypy � Presja czasu, aby kontynuować mimo istnienia otwartych kwestii ◦ Oznaczaj kwestie pozostające do wyjaśnienia i wyznacz osobę odpowiedzialną za domknięcie otwartych kwestii i docelową datę � Niejednoznaczna terminologia ◦ Utwórz glosariusz z definicjami terminów biznesowych i technicznych, które mogą być różnie interpretowane � Projekt dołączony do wymagań ◦ Oceniaj wymagania, aby upewnić się, że nie narzucają rozwiązania, ograniczając możliwość osiągnięcia optymalnego produktu 29

Walidacja wymagań � Wymagania bez walidacji ◦ Przydziel czas i zasoby na wykonanie oceny specyfikacji wymagań i opracowanie testów ◦ Zobowiąż przedstawicieli klienta do wzięcia udziału w przeglądach wymagań � Brak biegłości w inspekcji ◦ Przeszkol wszystkich członków zespołu, którzy będą uczestniczyć w inspekcjach dokumentów wymagań ◦ Poproś doświadczonego inspektora, aby przyjrzał się wcześniejszym inspekcjom i przeszkolił uczestników 30

Zarządzanie wymaganiami � Zmiana wymagań ◦ Projektuj systemy, mając na uwadze łatwość wprowadzania w nich zmian, szczególnie gdy realizujesz je w cyklu iteracyjnym � Brak zdefiniowanego procesu zmiany wymagań ◦ Wprowadzaj zmiany zgodnie z ustalonym procesem, uwzględniającym analizę wpływu, kontrolę zmian, odpowiednie narzędzia wspomagające realizację zmian ◦ Komunikuj zmiany odpowiednim interesariuszom � Niezaimplementowane wymagania ◦ Śledź wymagania, żeby nie przeoczyć któregoś z nich na etapie projektowania, tworzenia i testowania produktu � Rozszerzanie zakresu projektu ◦ Sporządzaj plany etapowo lub w cyklu przyrostowym ◦ We wczesnych etapach implementuj funkcje o najwyższym priorytecie, a w późniejszych iteracjach rozwijaj możliwości systemu 31

Pozyskiwanie wymagań � 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. 32

Techniki pozyskiwania wymagań � � 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 33

Techniki pozyskiwania wymagań � � 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 34

Przygotowania do pozyskiwania wymagań � Zaplanowanie zakresu i programu sesji � Przygotowanie � Poznanie zasobów interesariuszy � Przygotowanie pytań � Przygotowanie prowizorycznych modeli (przypadków użycia, przepływu procesów) 35

Przeprowadzanie pozyskiwania � Stosowanie technik aktywnego słuchania wobec interesariuszy � Sporządzanie rzetelnych notatek 36

Po zakończeniu pozyskiwania � 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ń 37

Lista źródeł 1. Wiegers K. , Beatty J. , Specyfikacja oprogramowania. Inżynieria wymagań, Helion, 2014 2. http: //www. iaria. org/conferences 2011/files. ICSEA 11/ICSEA 11 Tutorial_REID. pdf 3. https: //it-consulting. pl/autoinstalator/wordpress/tag/ieee 830 -1998/ 4. https: //resources. sei. cmu. edu/asset_files/Technical. Report/ 1992_005_001_16478. pdf 38