42
INŻYNIERIA OPROGRAMOWANIA INŻYNIERIA OPROGRAMOWANIA 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

Inżynieria wymagań. Wymagania stawiane oprogramowaniu · „Inżynieria wymagań jest relatywnie nowym terminem, ... systemów nie da się osiągnąć ... efektywnościowe dotyczące

Embed Size (px)

Citation preview

INŻYNIERIA OPROGRAMOWANIA INŻYNIERIAOPROGRAMOWANIA

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

Czym jest inżynieria wymagań? INŻYNIERIAOPROGRAMOWANIA

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

Wymaganie – formalna definicja INŻYNIERIAOPROGRAMOWANIA

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

Wymaganie – pierwszy przykład INŻYNIERIAOPROGRAMOWANIA

„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

Cechy dobrego wymagania INŻYNIERIAOPROGRAMOWANIA

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

Określanie wymagań INŻYNIERIAOPROGRAMOWANIA

Innymi słowy: chcemy ustalić co system powinien robić,

przy uwzględnieniu istniejących ograniczeń.

Dlaczego to w ogóle jest takie ważne? INŻYNIERIAOPROGRAMOWANIA

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

Rodzaje specyfikacji wymagań i jej zapis INŻYNIERIAOPROGRAMOWANIA

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.

Specyfikacja wymagań INŻYNIERIAOPROGRAMOWANIA

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

Cechy poprawnej specyfikacji wymagań INŻYNIERIAOPROGRAMOWANIA

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

Kto czyta dany rodzaj specyfikacji? INŻYNIERIAOPROGRAMOWANIA

Wymaganiaużytkownika

Wymaganiasystemowe

Menedżerowie klientaUżytkownicy systemuInżynierowie klienta

Menedżerowie zleceniobiorcyProjektanci systemu

Użytkownicy systemuInżynierowie klientaProjektanci systemu

Programiści

Największy zarzut, który usłyszysz od osób piszących specyfikację brzmi, że "nikt jej nie czyta".

Joel Spolsky, http://www.joelonsoftware.com/articles/fog0000000033.html

Kto i do czego używa specyfikacji? INŻYNIERIAOPROGRAMOWANIA

Użytkownicy systemu i inżynierowie klienta

Menedżerowie klientai zleceniobiorcy

Projektanci systemu, programiści

Testerzy

Inżynierowiekonserwacji systemu

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

Używają wymagań jako pomocy w zrozumieniu systemu

i związków między jego częściami

Podział wymagań stawianych oprogramowaniu INŻYNIERIAOPROGRAMOWANIA

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

Wymagania ogólne (biznesowe) INŻYNIERIAOPROGRAMOWANIA

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.

Wymagania funkcjonalne INŻYNIERIAOPROGRAMOWANIA

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

Przykłady wymagań funkcjonalnych INŻYNIERIAOPROGRAMOWANIA

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.

Przykłady wymagań funkcjonalnych INŻYNIERIAOPROGRAMOWANIA

Wymagania użytkownika zapisane w postaci tzw. diagramu przypadków użycia (Use Cases):

Diagram przypadków użyciabędzie szczegółowo omówiony na kolejnym wykładzie

Diagramowi temu towarzyszyzwykle opis scenariuszy

Przykłady wymagań funkcjonalnych INŻYNIERIAOPROGRAMOWANIA

Wymaganie użytkownika F6 przepisane jako wymaganie systemowe:

Kompletność i spójność wymagań funkcjonalnych INŻYNIERIAOPROGRAMOWANIA

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.

Wymagania niefunkcjonalne INŻYNIERIAOPROGRAMOWANIA

� 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ść.

Przykłady wymagań niefunkcjonalnych INŻYNIERIAOPROGRAMOWANIA

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

Klasyfikacja wymagań niefunkcjonalnych INŻYNIERIAOPROGRAMOWANIA

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

Podział szczegółowy wymagań niefunkcjonalnych INŻYNIERIAOPROGRAMOWANIA

Wymaganiaprzenośności

Wymaganianiezawodności

Wymaganiasprawnościowe

Wymaganiaetyczne

Wymaganiazewnętrzne

Wymaganiawspółpracy

Wymaganiaproduktowe

Wymaganiaorganizacyjne

Wymaganiaefektywnościowe

Wymaganiaużyteczności

Wymaganiadostawy

Wymaganiaimplementacyjne

Wymaganiastandardów

Wymaganiaprawne

Wymaganiapamięciowe Wymagania

ochronyprywatności

Wymaganiazabezpieczeń

Problemy z wymaganiami niefunkcjonalnymi INŻYNIERIAOPROGRAMOWANIA

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.

Rozwiązywanie problemów z wymaganiami niefunkcjonalnymi

INŻYNIERIAOPROGRAMOWANIA

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.

Miary do specyfikowania wymagań niefunkcjonalnych

INŻYNIERIAOPROGRAMOWANIA

Właściwość Miara

Szybkość

Rozmiar

Łatwość użycia

Niezawodność

Solidność

Przenośność

Liczba przetworzonych transakcji na sekundęCzas reakcji na zdarzenie wywołane przez użytkownikaCzas odświeżenia ekranu

Kilobajty, Megabajty itp.Liczba układów pamięci RAM

Czas szkoleniaLiczba okien pomocy

Średni czas bez awariiCzęstość błędów

Czas uruchomienia systemu po awariiProcent zdarzeń powodujących awariePrawdopodobieństwo zniszczenia danych podczas awarii

Procent kodu zależnego od platformyLiczba docelowych systemów

Wymagania dziedzinowe INŻYNIERIAOPROGRAMOWANIA

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

Przykłady wymagań dziedzinowych INŻYNIERIAOPROGRAMOWANIA

� Czytelnia norm:

D1. Wszystkie bazy danych powinny być dostępne przez jednolity interfejs użytkownika, którego podstawą jest standard Z39.50.

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:

Dpociągu = Dsterowania + Dnachyleniagdzie Dnachylenia wynosi 9,81m/s2 * nachylenie / alfa,

a współczynniki alfa są znane dla różnych typów pociągów.

Problemy z wymaganiami dziedzinowymi INŻYNIERIAOPROGRAMOWANIA

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

Trudności z pozyskiwaniem wymagań INŻYNIERIAOPROGRAMOWANIA

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

Zapisywanie wymagań. Problemy z językiem naturalnym

INŻYNIERIAOPROGRAMOWANIA

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

Zapisywanie wymagań. Dobre praktyki INŻYNIERIAOPROGRAMOWANIA

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

Karta wymagania. Opis INŻYNIERIAOPROGRAMOWANIA

Uwagi

� Każde wymaganie powinno być zapisane w osobnej karcie

� Nie wszystkie pola mają sens w przypadku wymagań niefunkcjonalnych i dziedzinowych

Formalne techniki specyfikowania wymagań INŻYNIERIAOPROGRAMOWANIA

� 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

Formalne techniki specyfikowania wymagań. Pseudokod

INŻYNIERIAOPROGRAMOWANIA

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

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

INŻYNIERIAOPROGRAMOWANIA

Formalne techniki specyfikowania wymagań. Drzewo decyzyjne

INŻYNIERIAOPROGRAMOWANIA

Formalne techniki specyfikowania wymagań. Diagram czynności

INŻYNIERIAOPROGRAMOWANIA

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

INŻYNIERIAOPROGRAMOWANIA

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

INŻYNIERIAOPROGRAMOWANIA

Formalne techniki specyfikowania wymagań. Analiza strukturalna

INŻYNIERIAOPROGRAMOWANIA

I na koniec: lektura obowiązkowa. Z blogu Joela Spolsky’ego…

INŻYNIERIAOPROGRAMOWANIA

Painless Functional Specifications

� Part 1: Why Bother http://www.joelonsoftware.com/articles/fog0000000036.html

� Part 2: What's a Spec? http://www.joelonsoftware.com/articles/fog0000000035.html

� Part 3: But... How? http://www.joelonsoftware.com/articles/fog0000000034.html

� Part 4: Tips http://www.joelonsoftware.com/articles/fog0000000033.html