Inżynieria wymagań. Wymagania stawiane oprogramowaniu

Transkrypt

1 Inżynieria wymagań. Wymagania stawiane oprogramowaniu Wykorzystane materiały: prezentacje J.E. Sienkiewicza i M.A. Płotki I. Sommerville, Inżynieria oprogramowania, WNT 2003 wykłady MIT Dilbert by Scott Adams

2 Czym jest inżynieria wymagań? pozyskiwaniem analizowaniem dokumentowaniem weryfikowaniem i walidacją funkcji i ograniczeń projektowanego systemu (czyli właśnie wymagań) oraz zarządzaniem nimi. Inżynieria wymagań jest relatywnie nowym terminem, który został wymyślony w celu nazwania wszystkich działań związanych z pozyskiwaniem, dokumentacją i utrzymywaniem zbioru wymagań dla systemu komputerowego. (I. Sommerville)

3 Wymaganie formalna definicja (a) Warunek (ang. condition) lub cecha (zdolność, ang. capability) nieodzowna dla rozwiązania problemu lub osiągnięcia zamierzonego celu. (b) Warunek lub cecha, które muszą być spełnione bądź posiadane przez system, aby być w zgodzie z kontraktem, standardem, specyfikacją lub innym formalnie narzuconym dokumentem. Udokumentowana reprezentacja warunku lub zdolności wg (a) lub (b).

4 Wymaganie pierwszy przykład Poprawnie sformułowane wymaganie to takie, które określa pewną zdolność systemu, której funkcjonowanie może zostać poddane walidacji oraz którą system musi posiadać, aby cele i wymagania klienta były spełnione, oraz na którą narzucone zostały pewne mierzalne warunki i ograniczenia (IEEE1233) Zdolność systemu: Samolot ma przewozić ludzi pomiędzy Nowym Jorkiem a Paryżem Warunek: Średnia prędkość lotu powinna wynosić 2500 km/h Ograniczenie: Maksymalna prędkość, jaką może osiągnąć samolot to 5000 km/h

5 Cechy dobrego wymagania Wymaganie powinno być: poprawne jednoznaczne możliwe do zrozumienia kompletne spójne realistyczne (możliwe do zrealizowania) uporządkowane (wg ważności i stabilności) sprawdzalne (weryfikowalne, testowalne) modyfikowalne możliwe do śledzenia

6 Określanie wymagań Innymi słowy: chcemy ustalić co system powinien robić, przy uwzględnieniu istniejących ograniczeń.

7 Dlaczego to w ogóle jest takie ważne? Najczęstszą przyczyną błędów w systemie jest błędna specyfikacja (ok. 60%). Koszt naprawy błędów powstałych na etapie tworzenia specyfikacji jest bardzo duży (sięga 80% budżetu projektu najczęściej trzeba w mniejszym lub większym stopniu przebudować cały system).

8 Rodzaje specyfikacji wymagań i jej zapis Wymagania użytkownika Oczekiwane usługi systemu oraz ograniczenia, w których system ma działać, wyrażone w języku naturalnym. Zapis powinien być zrozumiały dla udziałowców systemu, którzy nie mają szczegółowej wiedzy technicznej. Można wykorzystać język naturalny, posiłkując się prostymi i intuicyjnymi diagramami (np. diagramem UML Use Cases przypadki użycia). Wymagania systemowe Szczegółowe i precyzyjne ustalenie usług systemu i ograniczeń. Zwykle wykorzystuje się strukturalny język naturalny (formularze i szablony), notację graficzną (diagramy UML), języki opisu projektu (Program Design Language PDL), specyfikacje matematyczne.

9 Specyfikacja wymagań Dokumentacja wymagań stawianych oprogramowaniu (nazywana też specyfikacją wymagań stawianych oprogramowaniu, ang. Software Requirements Specification, SRS) jest oficjalną deklaracją tego, co jest wymagane od wytwórców systemu. Powinna zawierać zarówno wymagania użytkownika jak i szczegółową specyfikacje wymagań systemowych (SWS). Nie jest projektem powinna opisywać co system ma robić, a nie jak to robić. Powinna określać zachowanie systemu jedynie z zewnątrz. Powinno być łatwo ją zmieniać, ze względu na często zmieniające się lub uzupełniane wymagania. Specyfikacja wymagań jest podstawą kontraktu na implementację systemu, powinna być zatem pełną i niesprzeczną jego specyfikacją. Stanowi również punkt wyjścia do projektowania systemu.

10 Cechy poprawnej specyfikacji wymagań Jest czytelna i zrozumiała dla klientów, użytkowników i projektantów Opisuje jedynie zachowanie systemu widziane z zewnątrz ( czarna skrzynka ) Zapisana jest w sposób ułatwiający dokonywanie zmian Opisuje zarówno funkcje systemu jak i jego ograniczenia Opisuje, co w systemie można zrobić i czego nie można Powinna być użyteczna dla konserwatorów systemu jako referencja Powinna być kompletna, jednoznaczna, spójna, realna i testowalna Powinna specyfikować akceptowane reakcje systemu na sytuacje wyjątkowe Opisywać przyrosty (jeżeli stosowana będzie metodologia ewolucyjna lub przyrostowa) lub minimalną i maksymalną funkcjonalność (priorytety) Opisywać przewidywane zmiany wymagań w przyszłości (zarówno od strony środowiska jak i oprogramowania)

11 Kto czyta dany rodzaj specyfikacji? Wymagania użytkownika Menedżerowie klienta Użytkownicy systemu Inżynierowie klienta Menedżerowie zleceniobiorcy Projektanci systemu Wymagania systemowe Użytkownicy systemu Inżynierowie klienta Projektanci systemu Programiści Największy zarzut, który usłyszysz od osób piszących specyfikację brzmi, że "nikt jej nie czyta". Joel Spolsky,

12 Kto i do czego używa specyfikacji? Użytkownicy systemu i inżynierowie klienta Menedżerowie klienta i zleceniobiorcy Projektanci systemu, programiści Testerzy Określają wymagania i czytają je, aby sprawdzić, czy odpowiadają ich potrzebom. Określają także zmiany wymagań. Używają dokumentacji wymagań do planowania oferty budowy systemu i do planowania procesu jego tworzenia Używają wymagań, aby zrozumieć, jaki system ma być zbudowany Używają wymagań, aby opracować i przeprowadzić testy zatwierdzające system Inżynierowie konserwacji systemu Używają wymagań jako pomocy w zrozumieniu systemu i związków między jego częściami

13 Podział wymagań stawianych oprogramowaniu Wymagania ogólne (biznesowe) Pozwalają umieścić system w kontekście biznesowym, technicznym i środowiskowym. Wymagania funkcjonalne Stwierdzają, 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 Określają ograniczenia usług i funkcji systemu (czasowe, dotyczące procesu tworzenia, standardów itd.) Wymagania dziedzinowe Odzwierciedlają charakterystykę dziedziny zastosowania systemu. Mogą być zarówno funkcjonalne jak i niefunkcjonalne.

14 Wymagania ogólne (biznesowe) Wymagania pozwalające umieścić system w kontekście biznesowym, technicznym i środowiskowym. Wśród wymagań z tej kategorii powinno znaleźć się odniesienie do celów (biznesowych) systemu, przepisów i regulacji prawnych, zgodności z obowiązującymi i powszechnie stosowanymi w podobnych programach standardami oraz do udziałowców, a zwłaszcza przyszłych użytkowników systemu. Przykłady: WO1. Wspomaganie nauczania podstaw komputera przy wykorzystaniu idei i technologii Learning Objects do tworzenia zestawów aktywnych ćwiczeń praktycznych. WO2. Wypełnienie luki na rynku dla podobnego oprogramowania. WO3. System przeznaczony jest na rynek. WO4. Użytkownikami systemu będą adepci informatyki oraz osoby tworzące zestawy.

15 Wymagania funkcjonalne Odpowiadają na pytanie: jakie funkcje system ma udostępniać użytkownikom? Wymagania funkcjonalne opisują funkcjonalność lub usługi, które system powinien oferować. Zależą od rodzaju tworzonego oprogramowania, spodziewanych jego użytkowników oraz rodzaju wytwarzanego systemu. Gdy mają postać wymagań użytkownika, ich opis jest zwykle bardziej ogólny, natomiast wymagania systemowe szczegółowo definiują funkcje systemu, jego wejścia, wyjścia, wyjątki itd.

16 Przykłady wymagań funkcjonalnych Wymagania użytkownika zapisane w postaci tekstowej (system e-learningowy): F1. Odtwarzanie kursu. F2. Nieliniowe prezentowanie kursu (nawigacja po lekcjach), powtarzanie lekcji. F3. Możliwość ograniczenia/monitorowania czasu prezentowanego fragmentu. F4. Drukowanie. F5. Nawigacja po slajdach. F6. Pauzowanie lekcji. F7. Zamieszczanie filmów, dźwięków, animacji, pokazywania grafiki. F8. Przeprowadzanie testów, quizów. F9. Tworzenie raportów z przebiegu lekcji. F10. Administrowanie użytkownikami. F12. Wyświetlanie wprowadzenia do lekcji.

17 Przykłady wymagań funkcjonalnych Wymagania użytkownika zapisane w postaci tzw. diagramu przypadków użycia (Use Cases): Diagram przypadków użycia będzie szczegółowo omówiony na kolejnym wykładzie Diagramowi temu towarzyszy zwykle opis scenariuszy

18 Przykłady wymagań funkcjonalnych Wymaganie użytkownika F6 przepisane jako wymaganie systemowe:

19 Kompletność i spójność wymagań funkcjonalnych 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 wielkich 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.

20 Wymagania niefunkcjonalne Odpowiadają na pytanie: jak system ma działać? Mogą definiować ograniczenia systemu, takie jak możliwości urządzeń wejścia-wyjścia lub dostępne reprezentacje danych. 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. Wymagania stawiane procesowi tworzenia oprogramowania specyfikacja standardów jakości, których należy użyć, stwierdzenie, że projekt należy opracować za pomocą konkretnego zbioru narzędzi CASE. Wymagania te nie dotyczą bezpośrednio konkretnych funkcji systemu, ale związane są z takimi cechami jak: niezawodność, efektywność pracy, czas reakcji, bezpieczeństwo, ochrona czy wiarygodność.

21 Przykłady wymagań niefunkcjonalnych N1. System powinien posiadać zabezpieczenia przed niepowołanym dostępem do funkcji administrowania użytkownikami i tworzenia raportów (hasła dostępu) N2. System powinien płynnie odtwarzać lekcje (np. brak przypadkowego zatrzymywania się animacji czy dłuższego niż 1s wczytywania się kolejnego slajdu). N3. System należy wdrożyć do końca semestru dyplomowego. N4. System powinien działać pod systemami operacyjnymi Windows, Mac OS i Linux. N5. Należy wykorzystać język programowania Java. N6. Minimalne wymagania sprzętowe: prędkość procesora XX GHz, dysk twardy YY GB, karta graficzna itp. Wymagania niefunkcjonalne systemowe również należy zapisywać w karcie wymagania tak, jak wymagania funkcjonalne (opuszczając jedynie niektóre jej pola, które w ich przypadku nie mają sensu, np. czynności równoczesne, warunki początkowe i końcowe itp.)

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

23 Podział szczegółowy wymagań niefunkcjonalnych Wymagania produktowe Wymagania organizacyjne Wymagania zewnętrzne Wymagania sprawnościowe Wymagania niezawodności Wymagania przenośności Wymagania współpracy Wymagania etyczne Wymagania użyteczności Wymagania dostawy Wymagania implementacyjne Wymagania standardów Wymagania prawne Wymagania efektywnościowe Wymagania pamięciowe Wymagania ochrony prywatności Wymagania zabezpieczeń

24 Problemy z wymaganiami niefunkcjonalnymi Trudności z weryfikacją niektórych wymagań. Mogą one być podawane przez klienta w sposób odzwierciedlający jego ogólne dążenia, 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 i stwarza potencjalną możliwość konfliktów z klientem już po dostarczeniu systemu.

25 Rozwiązywanie problemów z wymaganiami niefunkcjonalnymi WYMAGANIA MUSZĄ BYĆ WERYFIKOWALNE (powinny dać się zmierzyć/zweryfikować/sprawdzić za pomocą przyjętych metryk) Wymaganie nieweryfikowalne System powinien być łatwy w użyciu dla doświadczonych użytkowników, a sposób jego organizacji powinien minimalizować liczbę błędów użytkownika. Poprawione, weryfikowalne wymaganie Doświadczeni użytkownicy powinni móc używać wszystkich funkcji systemu po szkoleniu trwającym dwie godziny. Po tym szkoleniu, średnia liczba błędów popełnianych przez użytkowników nie powinna przekroczyć dwóch dziennie.

26 Miary do 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żenia ekranu Kilobajty, Megabajty itp. Liczba układów pamięci RAM Czas szkolenia Liczba okien pomocy Średni czas bez awarii Częstość błędów Czas uruchomienia systemu po awarii Procent zdarzeń powodujących awarie Prawdopodobieństwo zniszczenia danych podczas awarii Procent kodu zależnego od platformy Liczba docelowych systemów

27 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 np. ustalać sposób wykonywania konkretnych funkcji. Wymagania dziedzinowe są istotne, ponieważ jeśli nie są spełnione, to system może nie działać w sposób zadowalający lub np. nie uzyskać wymaganych atestów.

28 Przykłady wymagań dziedzinowych Czytelnia norm: D1. Wszystkie bazy danych powinny być dostępne przez jednolity interfejs użytkownika, którego podstawą jest standard Z D2. Ze względu na ochronę praw autorskich system powinien udostępniać normy jedynie w formie przeznaczonej do odczytu na ekranie monitora, bez możliwości pobrania pliku ani jego wydruku. Jedynie po uzyskaniu potwierdzenia dokonania wpłaty, system powinien umożliwić wydruk dokumentu lub jego pobranie. System sterowania ruchem pociągu: D1. Tempo hamowania pociągu będzie wyznaczane następująco: D pociągu = D sterowania + D nachylenia gdzie D nachylenia wynosi 9,81m/s2 * nachylenie / alfa, a współczynniki alfa są znane dla różnych typów pociągów.

29 Problemy z wymaganiami dziedzinowymi Są one zwykle 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ąć jakąś 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 nieprawidłowy.

30 Trudności z pozyskiwaniem wymagań Klienci mogą nie wiedzieć, czego naprawdę potrzebują. Z drugiej strony, jeżeli podane wymagania zawierają zbyt wiele informacji, ograniczają wybór innowacyjnych rozwiązań oraz utrudniają zrozumienie wymagań. Klienci mogą nie być w stanie przetłumaczyć swoich celów na wymagania ilościowe. Wymagania niefunkcjonalne są często sprzeczne lub powiązane z innymi wymaganiami funkcjonalnymi. Zawsze należy starać się odróżnić wymagania funkcjonalne i niefunkcjonalne w dokumentacji wymagań. W praktyce jest to jednak czasami dość trudne.

31 Zapisywanie wymagań. 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 przegadanymi i nieczytelnymi. Sprzeczność wymagań Trudno jest jasno rozgraniczać wymagania funkcjonalne, niefunkcjonalne, cele systemu i elementy projektu, co często powoduje narastanie sprzeczności. Łączenie wymagań Kilka różnych wymagań może być zapisanych razem jako jedno wymaganie (albo odwrotnie).

32 Zapisywanie wymagań. Dobre praktyki Opracuj standardowy format i spraw, aby wszystkie definicje wymagań były z nim zgodne (np. opracuj formatkę dla wymagań systemowych, a wymagania użytkownika zapisuj w formie graficznej diagramu przypadków użycia z opisem scenariuszy). Konsekwentnie używaj pojęć językowych. Rozróżnij wymagania kluczowe od opcjonalnych. Stosuj wyróżnienia (wytłuszczenia, kursywy) do zaznaczania głównych części wymagania. Unikaj, jeżeli tylko się da, żargonu komputerowego. Zapisuj uzasadnienia związane z wymaganiami (szczególnie niefunkcjonalnymi i dziedzinowymi). Pomagają one wytwórcom i konserwatorom systemu w zrozumieniu, dlaczego takie wymaganie się pojawiło, i w ocenie wpływu zmiany tego wymagania.

33 Karta wymagania. Opis Uwagi Każde wymaganie powinno być zapisane w osobnej karcie Nie wszystkie pola mają sens w przypadku wymagań niefunkcjonalnych i dziedzinowych

34 Formalne techniki specyfikowania wymagań Stosowane, gdy ewentualne niepowodzenie zagraża zdrowiu lub życiu ludzkiemu, bądź może spowodować ogromne straty finansowe (systemy krytyczne) Powinny być używanie zgodnie z zasadą zdrowego rozsądku Należy używać tylko jednej metody do opisu wszystkich wymagań Należy opisywać podobne systemy w ten sam sposób Metody: Pseudokod Maszyny o skończonej ilości stanów (UML: State machine diagram) Drzewo decyzyjne Diagramy czynności (UML: Activity diagram), schematy blokowe Modele związków jednostek Analiza obiektowa (UML: Diagram obiektów) Analiza strukturalna

35 Formalne techniki specyfikowania wymagań. Pseudokod Przykład w języku PDL: if pixel_mode == random then Create three random values for x, y and color. else if pixel_mode == linear then Increment x value by 1. Create a random value for color. end if

36 Formalne techniki specyfikowania wymagań. Diagram maszyny stanowej oraz macierz stanów

37 Formalne techniki specyfikowania wymagań. Drzewo decyzyjne

38 Formalne techniki specyfikowania wymagań. Diagram czynności

39 Formalne techniki specyfikowania wymagań. Model związków jednostek

40 Formalne techniki specyfikowania wymagań. Analiza obiektowa (diagram obiektów)

41 Formalne techniki specyfikowania wymagań. Analiza strukturalna

42 I na koniec: lektura obowiązkowa. Z blogu Joela Spolsky ego Painless Functional Specifications Part 1: Why Bother Part 2: What's a Spec? Part 3: But... How? Part 4: Tips