Upload
vonguyet
View
224
Download
0
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ń. Analiza obiektowa (diagram obiektów)
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