OiZPI Część 4 zarządzanie procesem formułowania wymagań

Prezentacja na temat: "OiZPI Część 4 zarządzanie procesem formułowania wymagań"— Zapis prezentacji:

1 OiZPI Część 4 zarządzanie procesem formułowania wymagań
w materiałach wykorzystano: K.Subieta: Budowa i integracja systemów informatycznych A.Kobieliński: Inżynieria Oprogramowania I.Sommerville: Software Engineering IBM Rational: RUP™ S.Wyrcza, B.Marcinkowski: Język Inżynierii Systemów SysML, Architektura i Zastosowanie

2 Zarządzanie procesem formułowania wymagań
Pojęcie inżynierii wymagań Poziomy szczegółowości wymagań Dokumentacja fazy określania wymagań

3 Wymagania Wymaganie to najogólniej opis tego, co i przy jakich założeniach system powinien robić by klient osiągnął postawiony sobie cel. Formułowanie wymagań to proces zamiany celów klienta (określonych w fazie strategicznej) na konkretne wymagania zapewniające osiągnięcie tych celów. W fazie określania wymagań klient - samodzielnie albo wspólnie z grupą doradców i/lub przedstawicielami producenta - tworzy zbiór wymagań zgodny z jego celami Uwaga: pojęcie wymagania może odnosić się także do zasad prowadzenia i zarządzania projektem.

4 Metody rozpoznania wymagań
Wywiady i przeglądy. Wywiady powinny być przygotowane (w postaci listy pytań) i podzielone na odrębne zagadnienia. Podział powinien przykrywać całość tematu i powinny być przeprowadzone na reprezentatywnej grupie użytkowników. Wywiady powinny doprowadzić do szerokiej zgody i akceptacji projektu. Studia na istniejącym oprogramowaniu. Dość często nowe oprogramowanie zastępuje stare. Studia powinny ustalić wszystkie dobre i złe strony starego oprogramowania. Studia wymagań systemowych. Dotyczy sytuacji, kiedy nowy system ma być częścią większego systemu. Studia osiągalności. Określenie realistycznych celów systemu i metod ich osiągnięcia. Prototypowanie. Zbudowanie prototypu systemu działającego w zmniejszonej skali, z uproszczonymi interfejsami.

5 Metody rozpoznania wymagań
Warsztaty wymagań. Jest to spotkanie z inwestorami i użytkownikami (jeśli takich można wskazać) mające na celu uświadomienie sobie tego, co powinien robić przyszły system. Osoba prowadząca – analityk systemowy Uczestnicy – inwestorzy, użytkownicy i inne osoby, które mogą znać problemy rozpatrywanej jednostki organizacyjnej

6 Warsztaty wymagań Przebieg warsztatów
Każda z osób przemawia i artykułuje – na ile jest to możliwe, czytelnie swoje problemy Każdy problem zapisuje się – jakikolwiek by ten problem nie był Wszyscy uczestnicy starają się znaleźć – na zasadzie "burzy mózgów" rozwiązanie tego problemu, Rozwiązania zapisuje się obok problemów Przykład: problem: nie mogę się nigdy doliczyć palet na magazynie rozwiązanie: wprowadzić na faktury zakupowe i sprzedażowe pole określające liczbę przyjętych i wydanych palet.

7 Warsztaty wymagań Inne podejście
Analityk najpierw rozpoznaje problemy na niezależnych wcześniejszych spotkaniach Systematyzuje problemy tworząc listę pytań, Do każdego pytania można przygotować dodatkową ilustrację (np.. w postaci slajdu z diagramem, rysunkiem, tabelą, itp. Podczas warsztatów analityk objaśnia problem, przedstawia ilustrację Znajduje się rozwiązanie i udziela odpowiedzi na pytania na odpowiednim formularzu (query sheet) przykład: XXX przykład: YYY

8 Problem ewolucji wymagań
Ewolucja wymagań to najpoważniejszy problem projektowania systemów informatycznych. Szacuje się, że większość niepowodzeń projektów ma swe źródło w zmieniających się wymaganiach. Niestety zmiany wymagań raczej nie uda się uniknąć - trzeba raczej spróbować się na nią przygotować - wiedzieć co trzeba poprawić, gdy zmienią się wymagania czas Początkowe zrozumienie problemu Zmiana zrozumienia problemu Początkowe wymagania Zmiana wymagań

9 Problem ewolucji wymagań
Należy uznać, że ewolucja wymagań jest naturalną właściwością procesu analizy, w którym wiedza o rozpatrywanym problemie systematycznie wzrasta Im dłużej zajmujemy się jakimś zagadnieniem, tym większa jest nasza wiedza, tym większa jest świadomość użytkowników Należy przewidzieć mechanizmy pozwalające kontrolować proces ewolucji wymagań, Nie należy takiego problemu wykluczać Kategoryzacja skali zmian – pomocny mechanizm Poszczególne kategorie odpowiadają zmianom o różnej skali

10 Rodzaje wymagań Wymagania Wymagania funkcjonalne Wymaganie
niefunkcjonalne

11 Wymagania funkcjonalne
Wymagania funkcjonalne opisują operacje wykonywane przez system. Inne aspekty wymagań funkcjonalnych Określenie wszystkich rodzajów użytkowników, którzy będą korzystać z systemu. Określenie wszystkich rodzajów użytkowników, którzy są niezbędni do działania systemu (obsługa, wprowadzanie danych, administracja). Dla każdego rodzaju użytkownika określenie funkcji systemu oraz sposobów korzystania z planowanego systemu. Określenie systemów zewnętrznych (obcych baz danych, sieci, Internetu), które będą wykorzystywane podczas działania systemu. Ustalenie struktur organizacyjnych, przepisów prawnych, statutów, zarządzeń, instrukcji, itd., które pośrednio lub bezpośrednio określają funkcje wykonywane przez planowany system.

12 Metody specyfikacji wymagań funkcjonalnych
Język naturalny najczęściej stosowany. Wady: niejednoznaczność powodująca różne rozumienie tego samego tekstu; elastyczność, powodująca wyrazić te same treści na wiele sposobów. Utrudnia to wykrycie powiązanych wymagań i powoduje trudności w wykryciu sprzeczności. Język naturalny strukturalny Język naturalny z ograniczonym słownictwem i składnią. Tematy i zagadnienia wyspecyfikowane w punktach i podpunktach. Tablice, formularze Wyspecyfikowanie wymagań w postaci (zwykle dwuwymiarowych) tablic, kojarzących różne aspekty (np. tablica ustalająca zależność pomiędzy typem użytkownika i rodzajem usługi).

13 Metody specyfikacji wymagań funkcjonalnych
Diagramy blokowe forma graficzna pokazująca cykl przetwarzania. Diagramy kontekstowe ukazują system w postaci jednego bloku oraz jego powiązania z otoczeniem, wejściem i wyjściem. Diagramy przypadków użycia poglądowy sposób przedstawienia aktorów i funkcji systemu.

14 Trudności fazy formułowania wymagań
Klient nie potrafi rozgraniczyć celów od wymagań; te pierwsze często formułuje mało konkretnie i ogólnikowo; tych drugich nie potrafi wyartykułować (trzeba pomóc mu je rozpoznać) Klient z reguły spodziewa się poprawy stanu aktualnego organizacji, często nie przewidując jakie zmiany w organizacji przedsiębiorstwa spowoduje ulepszony system; najchętniej też nie ponosiłby za nie odpowiedzialności cel: usprawnienie sprzedaży, wymaganie: możliwość wystawienia faktury, możliwość wydruku faktury.

15 Trudności fazy formułowania wymagań
Klient z reguły nie wie w jaki sposób osiągnąć założone cele; z drugiej strony cele klienta można osiągnąć na wiele sposobów Duże systemy wykorzystywane są przez wielu użytkowników; ich cele często są sprzeczne; różni użytkownicy mogą posługiwać się inną terminologią mówiąc o tych samych problemach Inwestorzy i użytkownicy do często inne osoby; głos inwestora, choć decydujący, nie zawsze właściwie potrafi przewidzieć potrzeby rzeczywistych użytkowników cel: usprawnienie sprzedaży, wymaganie: możliwość wystawienia faktury, możliwość wydruku faktury.

16 Zalecenia Wymagania użytkowników powinny być wyjaśniane poprzez krytykę i porównanie z istniejącym oprogramowaniem i prototypami. Należy uzyskać stan porozumienia pomiędzy projektantami i użytkownikami dotyczący projektowanego systemu. Wiedza i doświadczenia potencjalnej organizacji podejmującej się rozwoju systemu powinny wspomóc studia nad osiągalnością systemu. W wielu przypadkach dużym wspomaganiem jest budowa prototypów. Wymagania użytkowników powinny być: jasne, jednoznaczne, weryfikowalne, kompletne, dokładne, realistyczne, osiągalne.

17 Wymagania niefunkcjonalne
Wymagania niefunkcjonalne określają jakim ograniczeniom podlegać ma system wypełniając wymagania funkcjonalne. Najczęściej związane są z wydajnością systemu, właściwościami interfejsu użytkownika, dopasowaniem do określonego środowiska – system operacyjny, system zarządzania bazą danych

18 Weryfikowalność wymagań niefunkcjonalnych
Wymagania niefunkcjonalne powinny być weryfikowalne, czyli powinna istnieć możliwość sprawdzenia lub zmierzenia czy system je rzeczywiście spełnia, np. wymagania “system ma być łatwy w obsłudze”, „system ma być niezawodny”, „system ma być dostatecznie szybki”, itd. nie są weryfikowalne. Aby uniknąć nieporozumień na etapie odbioru systemu (testach akceptacyjnych) najlepiej posługi się metryką, która obiektywizuje spełnienie bądź nie wymagań niefunkcjonalnych.

19 Przykłady metryk wymagań niefunkcjonalnych
Cecha Metryka Szybkość Liczba transakcji przetwarzanych na sekundę, czas reakcji na sygnał użytkownika / sygnał zewnętrzny Rozmiar KB/MB/GB Łatwość użycia Czas treningu użytkownika, liczba stron systemu pomocy, liczba stron dokumentacji Niezawodność Średni czas międzyawaryjny, prawdopodobieństwo niedostępności, częstotliwość występowania awarii Odporność na błędy Czas restartu po awarii, statystyczny procent zdarzeń powodujących awarie Przenośność Procent instrukcji zależnych od systemu operacyjnego, liczba systemów docelowych

20 SysML - wymagania Formułowanie wymagań – najbardziej newralgiczny etap pracy nad systemami W języku SysML wyodrębniono dla wymagań osobną kategorie modelowania Notacja – diagram wymagań systemowych Wymaganie – symbol kasy o stereotypie <<requirement>> Wymaganie jest identyfikowane przez: Numer – numeracja o strukturze hierarchiczne, notacja Deweya (numerowanie wierzchołków drzewa) Treść wymagania – spójny, syntetyczny opis właściwości, która powinien posiadać system (nazwa) Wymaganie można uzupełnić opisem, korzystając z metki „tekst” lub z pola notatek

21 SysML - wymagania

22 SysML – wymagania i relacje
W SysML przewidziano siedem kategorii zależności: Zagnieżdżenie Zależność wyprowadzania (<<deriveReqt>>) Zależność realizacji (<<satisfy>>) Zależność powielenia (<<copy>>) Zależność weryfikowania (<<verify>>) Zależność precyzowania (<<refine>>) Zależność śledzenia (<<trace>>)

23 SysML: wymagania i relacje – zagnieżdżenie
Najczęściej spotykana relacja Znaczenie: łączy wymagania nadrzędne z podrzędnymi pozwalając na tworzenie hierarchicznej struktury powiązań Na jednym poziomie hierarchii może istnieć tylko jeden element nadrzędny Przeniesienie pomiędzy elementami nadrzędnymi – zależność kopiowania

24 SysML: wymagania i relacje – zależność wyprowadzania
Znaczenie: wyprowadzanie jednego wymagania z innego Wyprowadzone wymaganie to wymaganie pochodne Strzałka wskazuje wymaganie, z którego wyprowadzono wymaganie pochodne

25 SysML: wymagania i relacje – zależność realizacji
Znaczenie: przypisanie wymagania do spełniającego go elementu Strzałka wskazuje spełniane wymaganie

26 SysML: wymagania i relacje – zależność powielania
Znaczenie: wyrażanie tożsamości wymagań Pozwala unikać wielokrotnego definiowania podobnych wymagań Strzałka wskazuje powielane wymaganie

27 SysML: wymagania i relacje – zależność weryfikowania
Znaczenie: powiązanie testu formalnego z wymaganiem Test formalny (ang. testcase) jest odrębna kategoria modelowania SysML (także UML) Strzałka wskazuje weryfikowane wymaganie

28 SysML: wymagania i relacje – zależność precyzowania
Znaczenie: powiązanie wymagania z elementem modelu wzbogacającym jego specyfikację Elementem wzbogacającym może być dowolna kategoria modelowania, ale także specyfikacja tekstowa, projekt interfejsu, itp. Strzałka wskazuje wzbogacane wymaganie

29 SysML: wymagania i relacje – zależność śledzenia
Znaczenie: pokazanie formalnego związku pomiędzy wymaganiem i elementami modelu Duża swoboda posługiwania się znaczeniem (swoboda interpretacji) Przykładowe zastosowanie: zależności czasowe