Inżynieria wymagań. Inżynieria wymagań 1/1

Transkrypt

1 Inżynieria wymagań Inżynieria wymagań 1/1

2 Inżynieria wymagań 2/1 Wymagania stawiane oprogramowaniu Opisy usług i ograniczeń są wymaganiami stawianymi systemowi. Proces wynajdowania, analizowania, dokumentowania oraz sprawdzania usług i ograniczeń nosi nazwę inżynierii wymagań.

3 Inżynieria wymagań 3/1 Pojęcie wymogu W przemyśle informatycznym pojęcie wymaganie nie jest stosowane konsekwentnie. Niekiedy wymaganie jest postrzegane jako zapisane na wysokim poziomie, abstrakcyjne określenie usług, które system powinien oferować, albo ograniczenie działania systemu. Niektórzy określają wymaganie jako szczegółową, matematycznie formalną definicję funkcji systemu.

4 Inżynieria wymagań 4/1 Typy wymagań Wymagania użytkownika To wyrażenia w języku naturalnym oraz diagramy o usługach oczekiwanych od systemu oraz o ograniczeniach, w których system ma działać. Wymagania systemowe Szczegółowo ustalają usługi systemu i ograniczenia. Dokumentacja wymagań systemowych, zwana czasem specyfikacją funkcjonalną, powinna być precyzyjna. Specyfikacja projektu Jest abstrakcyjnym opisem projektu oprogramowania, który jest podstawą bardziej szczegółowego projektu i implementacji.

5 Czytelnicy różnych rodzajów specyfikacji Inżynieria wymagań 5/1

6 Inżynieria wymagań 6/1 Wymagania funkcjonalne i niefunkcjonalne Wymagania funkcjonalne Są stwierdzeniami, jakie usługi ma oferować system, jak ma reagować na określone dane wejściowe oraz jak ma się zachowywać w określonych sytuacjach. W niektórych wypadkach wymagania funkcjonalne określają, czego system nie powinien robić. Wymagania niefunkcjonalne To ograniczenia usług i funkcji systemu. Obejmują ograniczenia czasowe, ograniczenia dotyczące procesu tworzenia, standardy itd. Wymagania dziedzinowe Pochodzą z dziedziny zastosowania systemu, odzwierciedlają jej charakterystykę. Mogą być funkcjonalne lub niefunkcjonalne.

7 Inżynieria wymagań 7/1 Wymagania funkcjonalne Wymagania funkcjonalne stawiane systemowi opisują funkcjonalność lub usługi, które system powinien oferować. Zależą od rodzaju tworzonego oprogramowania, spodziewanych użytkowników oprogramowania i rodzaju wytwarzanego systemu. Gdy mają postać wymagań użytkownika, ich opis jest zwykle bardziej ogólny, natomiast wymagania funkcjonalne systemowe szczegółowo definiują funkcje systemu, jego wejścia, wyjścia, wyjątki itd.

8 Inżynieria wymagań 8/1 Przykłady wymagań funkcjonalnych System biblioteki studenckiej Użytkownik będzie mógł przeszukać zbiór wszystkich baz danych lub wybrać tylko ich podzbiór. System udostępni odpowiednie narzędzia do oglądania, aby użytkownik mógł czytać dokumenty z magazynu. Każde zamówienie będzie oznaczone unikatowym identyfikatorem (ORDE ID), który będzie można skopiować do pamięci trwałej konta użytkownika.

9 Inżynieria wymagań 9/1 Kompletność i spójność specyfikacji wymagań funkcjonalnych W zasadzie specyfikacja wymagań funkcjonalnych stawianych systemowi powinna być kompletna i spójna. Kompletność oznacza, że wszystkie potrzebne użytkownikowi usługi powinny być zdefiniowane. Spójność oznacza, że wymagania nie powinny mieć sprzecznych definicji. W praktyce w wypadku złożonych systemów nie da się osiągnąć kompletności i spójności. Przyczynami tego są swoista złożoność tych systemów oraz fakt, że różne punkty widzenia są związane ze sprzecznymi potrzebami.

10 Inżynieria wymagań 10/1 Wymagania niefunkcjonalne Mogą definiować ograniczenia systemu, takie jak możliwości urządzeń wejścia-wyjścia i reprezentacje danych używane przez interfejsy systemu. Przykładami wymagań stawianych procesowi są specyfikacja standardów jakości, których należy użyć w procesie, stwierdzenie, że projekt należy opracować za pomocą konkretnego zbioru narzędzi CASE, i opis procesu, którego należy przestrzegać. Wymagania niefunkcjonalne wynikają z potrzeb użytkownika, ograniczeń budżetowych, strategii firmy, konieczności współpracy z innymi systemami sprzętu lub oprogramowania, czynników zewnętrznych.

11 Inżynieria wymagań 11/1 Klasyfikacja wymagań niefunkcjonalnych Wymagania produktowe Określają zachowanie produktu. Przykładami są wymagania efektywnościowe dotyczące szybkości działania systemu i jego zapotrzebowania na pamięć, wymagania niezawodności. Wymagania organizacyjne Wynikają ze strategii i procedur w firmie klienta i w firmie wytwórcy. Wymagania zewnętrzne Ta szeroka kategoria mieści wszystkie wymagania wynikające z czynników zewnętrznych. Obejmują m.in. wymagania współpracy, które definiują interakcje systemu z systemami innych firm i wymagania prawne.

12 Typy wymagań niefunkcjonalnych Inżynieria wymagań 12/1

13 Inżynieria wymagań 13/1 Przykłady wymagań niefunkcjonalnych Wymaganie produktowe Wszelka niezbędna komunikacja między środowiskiem wspomagającym programowanie w Adzie (APSE) i użytkownikiem powinna dać się wyrazić za pomocą standardowego zestawu symboli Ady. Wymaganie organizacyjne Proces tworzenia systemu i końcowe dokumenty powinny być zgodne z procesem i produktami zdefiniowanymi w standardzie XYZCo-SP-STAN-95. Wymaganie zewnętrzne System nie powinien ujawniać operatorom żadnych danych osobowych klientów oprócz nazwisk i numerów identyfikacyjnych.

14 Inżynieria wymagań 14/1 Problemy związane z wymaganiami niefunkcjonalnymi Powszechnie występującym problemem z wymaganiami niefunkcjonalnymi jest fakt, że czasem trudno je zweryfikować. Mogą one być zapisywane w sposób odzwierciedlający ogólne dążenia klienta, takie jak łatwość użycia, zdolność do naprawy awarii i szybka reakcja na działania użytkownika. To jednak zostawia bardzo duży margines do interpretacji.

15 Inżynieria wymagań 15/1 Miary specyfikowania wymagań niefunkcjonalnych Właściwość Szybkość Rozmiar Łatwość użycia Niezawodność Solidność Przenośność Miara Liczba przetworzonych transakcji na sekundę Czas reakcji na zdarzenie wywołane przez użytkownika Czas odświeżania ekranu Kilobajty pamięci RAM Kilobajty przestrzeni dyskowej Czas szkolenia Liczba okien pomocy Średni czas bez awarii Prawdopodobieństwo niedostępności Częstość błędów Dostępność Czas uruchomienia po awarii Ułamek zdarzeń powodujących awarię Prawdopodobieństwo zniszczenia danych po awarii Procent poleceń zależnych od platformy Liczba docelowych systemów

16 Inżynieria wymagań 16/1 Wymagania dziedzinowe Wymagania dziedzinowe wynikają bardziej z dziedziny zastosowania systemu niż z konkretnych potrzeb użytkowników. Mogą być nowymi wymaganiami funkcjonalnymi, ograniczać istniejące wymagania funkcjonalne albo ustalać sposób wykonywania konkretnych obliczeń. Wymagania dziedzinowe są istotne, ponieważ odzwierciedlają podstawy dziedziny zastosowania. Jeśli nie są spełnione, to system nie może działać w sposób zadowalający.

17 Inżynieria wymagań 17/1 Wymagania dziedzinowe z systemu bezpieczeństwa ruchu pociągów Tempo zmniejszania prędkości pociągu jest wyznaczane następująco: D pociagu = D sterowania + D nachylenia przy czym D nachylenia wynosi 9,81m/s 2 wyrównanie nachylenie/alfa, a 9,81m/s 2 /alfa znane są dla różnych typów pociągów.

18 Inżynieria wymagań 18/1 Zasadnicze problemy z wymaganiami dziedzinowymi Są one wyrażone za pomocą języka specyficznego dla dziedziny zastosowania, co sprawia, że inżynierowie oprogramowania często ich nie rozumieją. Eksperci z danych dziedzin często mogli pominąć te informację, ponieważ po prostu jest dla nich oczywista. Może nie być jednak oczywista dla twórców systemu, którzy mogą to wymaganie zaimplementować w sposób niesatysfakcjonujący.

19 Inżynieria wymagań 19/1 Wymagania użytkownika Wymagania użytkownika stawiane systemowi powinny określać wymagania funkcjonalne i niefunkcjonalne tak, aby były zrozumiałe dla użytkowników systemu, którzy nie mają szczegółowej wiedzy technicznej. Należy je zapisywać w języku naturalnym, używając formularzy i prostych, intuicyjnych diagramów.

20 Inżynieria wymagań 20/1 Problemy z językiem naturalnym Brak jasności Czasem trudno jest wyrażać się w języku naturalnym precyzyjnie i jednoznacznie bez czynienia dokumentów gadatliwymi i nieczytelnymi. Sprzeczność wymagań Trudno jest jasno rozgraniczać wymagania funkcjonalne, wymagania niefunkcjonalne, cele systemu i elementy projektu. Łączenie wymagań Kilka różnych wymagań może być zapisanych razem jako jedno wymaganie.

21 Inżynieria wymagań 21/1 Problemy przy stawianiu wymagań Jeśli wymagania użytkownika zawierają zbyt wiele informacji, to ograniczają wolność twórców systemu w wyborze innowacyjnych rozwiązań oraz utrudniają zrozumienie wymagań. Uzasadnienia związane z wymaganiami są istotne. Pomagają wytwórcom i konserwatorom systemu w zrozumieniu, dlaczego takie wymaganie się pojawiło, i w ocenie wpływu zmiany tego wymagania. Szczegóły implementacyjne nie powinny pojawić się bez informacji dotyczących działania części systemu.

22 Inżynieria wymagań 22/1 Wymagania systemowe Wymagania systemowe są bardziej szczegółowymi opisami wymagań użytkownika. Mogą być podstawą kontraktu na implementację systemu, powinny być zatem pełną i niesprzeczną specyfikacją całego systemu. Są traktowane przez inżynierów oprogramowania jako punkt wyjścia do projektowania systemu. Specyfikacja wymagań systemowych może zawierać różne modele systemu.

23 Inżynieria wymagań 23/1 Wymagania a projekt W dokumentacji wymagań można zdefiniować wstępną architekturę systemu, aby nadać specyfikacji odpowiednią strukturę. Wymagania systemowe są zorganizowane zgodnie z podziałem na podsystemy wchodzące w skład systemu. W większości wypadków systemy muszą współpracować z innymi istniejącymi systemami. Ograniczają one projekt, co implikuje dodatkowe wymagania stawiane nowemu systemowi. Użycie specyficznego projektu może być zewnętrznym wymaganiem systemowym.

24 Inżynieria wymagań 24/1 Notacje specyfikacji wymagań Notacja Strukturalny język naturalny Język opisu projektu Notacje graficzne Specyfikacje matematyczne Opis To podejście polega na definiowaniu standardowych formularzy i szablonów do wyrażania specyfikacji wymagań W tym podejściu używa się języka podobnego do języka programowania, ale z bardziej abstrakcyjnymi elementami do specyfikowania wymagań poprzez model operacyjny systemu Do definiowania wymagań funkcjonalnych stawianych systemowi używa się języka graficznego z tekstowymi dopiskami, np. używa się diagramów przypadków użycia. Są to notacje oparte na pojęciach matematycznych, takich jak skończone matematyczne maszyny stanowe lub zbiory. Takie jednoznaczne specyfikacje zmniejszają spory na temat funkcjonalności między klientem a zleceniobiorcą. Większość klientów nie rozumie jednak formalnych specyfikacji i jest niechętna przyjęciu ich jako kontraktu na budowę systemu.

25 Inżynieria wymagań 25/1 Dokumentacja wymagań Zalecana struktura dokumentacji 1. Wstęp 1.1 Przeznaczenie tej dokumentacji wymagań 1.2 Zakres produktu 1.3 Definicje, akronimy, skróty 1.4 Odnośniki 1.5 Przegląd pozostałej części dokumentu 2. Ogólny opis 2.1 Wizja produktu 2.2 Funkcje produktu 2.3 Charakterystyka użytkowników 2.4 Ogólne ograniczenia 2.5 Założenia i zależności 3. Szczegółowe wymagania 4. Dodatki 5. Skorowidz

26 Inżynieria wymagań 26/1 Proces inżynierii wymagań Składa się z etapów: Studium wykonalności Określenie i analizowanie wymagań Specyfikowanie wymagań Zatwierdzanie wymagań

27 Inżynieria wymagań 27/1 Studium wykonalności Odpowiada na pytania Czy system przyczyni się do realizacji celów przedsiębiorstwa? Czy system może być zaimplementowany z użyciem dostępnych technologii, w ramach ustalonego budżetu i ograniczeń czasowych? Czy system może być zintegrowany z istniejącymi systemami, które już zainstalowano? Raport studium wykonalności Raport studium wykonalności zawiera zalecenie kontynuacji lub przerwania budowy systemu. Może również proponować zmiany zakresu systemu, budżetu lub harmonogramu.

28 Określanie i analizowanie wymagań Uczestnik Uczestnik systemu to osoba, która będzie pracować z systemem oraz osoby w przedsiębiorstwie, na które system będzie mieć wpływ. Uczestnik powinien mieć bezpośredni lub pośredni wpływ na wymagania systemowe. Określanie i analizowanie wymagań jest trudnym procesem, gdyż: Uczestnicy mogą nie wiedzieć dokładnie czego oczekują od systemu komputerowego. Uczestnicy systemu wyrażają wymagania za pomocą pojęć z własnej dziedziny. Różni uczestnicy mogą stawiać różne wymagania i mogą je wyrażać na różne sposoby. Czynniki polityczne mogą mieć wpływ na system. Środowisko ekonomiczne i gospodarcze, w którym prowadzi się analizę, jest dynamiczne. Inżynieria wymagań 28/1

29 Inżynieria wymagań 29/1 Czynności procesu określania i analizowania wymagań Czynności: Rozpoznanie dziedziny. Zbieranie wymagań. Klasyfikacja. Usuwanie sprzeczności. Nadawanie priorytetów. Sprawdzanie wymagań.

30 Inżynieria wymagań 30/1 VORD Viewpoint-Oriented Requirements Definition Główne kroki: Identyfikacja punktów widzenia. Strukturalizacja punktów widzenia. Dokumentacja punktów widzenia. Przyporządkowanie punktów widzenia.

31 Inżynieria wymagań 31/1 Szablony formularzy punktów widzenia i usług Szablon do punktów widzenia Odnośnik: Nazwa punktu widzenia Atrybuty: Atrybuty z informacją o punkcie widzenia Zdarzenia: Odnośnik do zbioru scenariuszy zdarzeń opisujących, jak system reaguje na zdarzenia w ramach tego punktu widzenia Usługi: Odnośnik do zbioru Podrzędne PW: opisów usług Nazwy podrzędnych punktów widzenia Szablon do usług Odnośnik: Nazwa usługi Uzasadnienie:Przyczyna oferowania usługi Specyfikacja: Odnośnik do listy specyfikacji usług, które mogą być opisane za pomocą różnych notacji Wymagania Odnośnik do zbioru niefunkcjonalnenalnych ograniczających wymagań niefunkcjo- usługę Dostawca: Odnośnik do listy obiektów systemu, które oferują tę usługę

32 Burza mózgów Inżynieria wymagań 32/1

33 Burza mózgów Inżynieria wymagań 33/1

34 Inżynieria wymagań 34/1 Usługi przypisane do punktów widzenia Właściciel konta Lista usług Wypłata gotówki Pytanie o saldo Zamówienie czeków Wysłanie komunikatu Lista transakcji Zamówienie wyciągu Przelew środków Obcy klient Lista usług Wypłata gotówki Pytanie o saldo Kasa banku Lista usług Diagnostyka Dodanie gotówki Dodanie papieru Wysłanie komunikatu

35 Hierarchia punktów widzenia Inżynieria wymagań 35/1

36 Inżynieria wymagań 36/1 Proces zatwierdzania wymagań Sprawdzanie wymagań Sprawdzenie ważności Sprawdzenie niesprzeczności Sprawdzenie kompletności Sprawdzenie realności Możliwość weryfikacji

37 Inżynieria wymagań 37/1 Proces zatwierdzania wymagań Zatwierdzanie wymagań Przeglądy wymagań Prototypowanie Generowanie testów Zautomatyzowane generowanie niesprzeczności

38 Inżynieria wymagań 38/1 Wykład przygotowany na podstawie Sommerville I.: Inżynieria oprogramowania, WNT, Warszawa 2003