Inżynieria wymagań użytkownika - wprowadzenie Dr Karolina Muszyńska

Agenda Definicja wymagań i dlaczego inżynieria wymagań jest trudna i tak bardzo ważna Kryteria dobrej specyfikacji wymagań Elementy składowe inżynierii wymagań Poziomy i rodzaje wymagań Modelowanie wymagań – diagramy przypadków użycia No additional notes

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 Według IEEE (Institute of Electrical and Electronics Engineers) warunek lub umiejętność potrzebna użytkownikowi, by rozwiązać problem lub osiągnąć cel warunek lub umiejętność, która musi być spełniona przez system lub komponent systemu, aby wypełnić założenia umowy, standardu, specyfikacji lub innego formalnego dokumentu udokumentowana reprezentacja warunku lub umiejętności opisanych w 1. lub 2.

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).

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.

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. Niektóre przeróbki wprowadzają do produktu nowe wartości i go ulepszają, jednak konieczność dokonywania nadmiernych modyfikacji wiąże się ze stratą czasu i jest frustrująca. 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.

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

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: zawiera wszystkie istotne wymagania (nie tylko funkcjonalne, lecz również pozafunkcjonalne), określa odpowiedź systemu na każdą informację wejściową, dla danych zarówno poprawnych, jak i niepoprawnych, zawiera referencje do wszystkich diagramów, tabel, pojęć słownikowych

Kryteria dobrej specyfikacji wymagań Spójność 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.

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.

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.

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ń.

Elementy inżynierii wymagań

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.

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. ….

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.

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.

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.

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. ….

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.

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

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

Poziomy wymagań

Modelowanie przypadków użycia Modelowanie przypadków użycia jest procesem modelowania funkcji systemu, ukazującym zdarzenia biznesowe, aktorów którzy te zdarzenia inicjują oraz to w jaki sposób system reaguje na te zdarzenia. Przypadek użycia jest sekwencją powiązanych akcji, zarówno zautomatyzowanych jak i ręcznych, prowadzących do realizacji funkcji biznesowej. Nazywa się go również scenariuszem realizacji funkcji. Aktor reprezentuje encję zewnętrzną, która wchodzi w interakcję z systemem w celu wymiany informacji. Aktorem jest użytkownik pełniący określoną rolę w systemie i może to być zarówno osoba jak i zewnętrzny system. W pewnego rodzaju zdarzeniach zwanych zdarzeniami czasowymi, które inicjowane są w określonym momencie czasu, aktorem jest czas.

Diagram przypadków użycia Diagram przypadków użycia jest opisem systemu z punktu widzenia jego funkcji – jakie funkcje oferuje system Diagram przypadków użycia nie przedstawia przepływów danych ani przepływów informacji w systemie (przepływy te są przedstawiane na diagramach interakcji)

Rozszerzające i zawierane przypadki użycia Rozszerzający przypadek użycia rozszerza funkcjonalność bazowego przypadku użycia o nowe zachowania lub akcje w stosunku do podstawowego przebiegu zdarzeń. Rozszerzający przypadek użycia może być wywołany jedynie przez przypadek użycia, który rozszerza. Zawierany przypadek użycia zawiera typowe kroki scenariusza, które są wspólne dla dwóch lub więcej bazowych przypadków użycia. Zawierany przypadek użycia redukuje redundancję i sprzyja ponownemu wykorzystaniu wspólnych elementów.

Rozszerzający przypadek użycia (relacja “extend”) Sprawdź listę dostępnych pokoi Przekaż rezerwację centrali “Sprawdź listę dostępnych pokoi” jest przypadkiem bazowym. W określonych sytuacjach (np. brak dostępnych pokoi do wynajęcia w danym obiekcie) wywołany zostanie przypadek “Przekaż rezerwację centrali”. Przypadki rozszerzające nie są wykonywane automatycznie, a zależność rozszerzania skierowana jest do przypadku bazowego.

Zawierane przypadki użycia (relacja “include”) Dokonaj rezerwacji Sprawdź listę dostępnych pokoi Przypadek bazowy „Dokonaj rezerwacji” każdorazowo wywołuje przypadek „Sprawdź listę dostępnych pokoi”. Zależność zawierania skierowana jest do przypadku zawieranego.

Dziedziczenie - uogólnienia w kontekście aktorów i przypadków użycia Złóż zamówienie Złóż zamówienie telefonicznie Złóż zamówienie przez stronę www Klient Przygotuj raport sprzedaży Przedstawiciel handlowy Przygotuj raport Przygotuj raport o reklamacjach Przypadki “Złóż zamówienie telefonicznie” i „Złóż zamówienie przez stronę www” są możliwymi odmianami przypadku bazowego „Złóż zamówienie”, natomiast „Przygotuj raport sprzedaży” i „Przygotuj raport o reklamacjach” to odmiany przypadku bazowego „Przygotuj raport”. Przedstawiciel handlowy może przyjmować rolę Klienta i inicjować te same przypadki użycia co Klient.

Przypadki użycia typu CRUD i elementarne przypadki użycia Utwórz zamówienie Klient Sprzedawca Sprawdź stan zamówienia Anuluj zamówienie Administrator bazy danych Zarządzaj stanem magazynu Przypadki użycia typu CRUD (Create, Read, Update, Delete) są wykorzystywane kiedy aplikacja służy do przechowywania danych i tylko jeden aktor wchodzi z nią w interakcję (np. zarządzanie bazą danych, zarządzanie zamówieniami, itp.).

Dokumentacja przypadków użycia Każdy przypadek użycia powinien zawierać dokumentację w formie scenariuszy. Scenariusz jest sekwencją akcji dokumentujących zachowanie użytkownika i systemu. Każdy przypadek użycia powinien mieć przynajmniej scenariusz główny ale wskazane jest, żeby wyróżnić także scenariusze alternatywne. Zarówno scenariusz główny jak i alternatywny szczegółowo opisują pełną funkcjonalność reprezentowaną przez przypadek użycia. Dodatkowe ważne elementy dokumentacji przypadków użycia to: warunki wstępne oraz warunki końcowe.

Proces tworzenia diagramu przypadków użycia Identyfikacja aktorów (poszukiwanie źródeł i celów głównych wejść i wyjść systemu). Identyfikacja przypadków użycia (główne funkcje systemu). Identyfikacja związków pomiędzy aktorami i przypadkami użycia (asocjacji) Identyfikacja dodatkowych relacji między przypadkami użycia (“extend”, “include”) Identyfikacja relacji uogólnienia pomiędzy przypadkami użycia i aktorami Udokumentowanie przypadków użycia

Lista źródeł Wiegers K., Beatty J., Specyfikacja oprogramowania. Inżynieria wymagań, Helion, 2014 http://www.iaria.org/conferences2011/filesICSEA11/ICSEA-11Tutorial_REID.pdf http://wymagania.net/baza-wiedzy/36-baza-wiedzy/101-kryteria-dobrej-specyfikacji-wg-ieee-std-830-1998 http://www.sei.cmu.edu/productlines/frame_report/req_eng.htm http://www.csun.edu/~dn58412/IS431/IS431_SP13.html Schneider G., Winters J.P. „Stosowanie przypadków użycia”, WNT, 2004 Wrycza S., Marcinkowski B., Wyrzykowski K. „Język UML 2.0 w modelowaniu SI”, Helion, 2006