Pobieranie prezentacji. Proszę czekać

Pobieranie prezentacji. Proszę czekać

Inżynieria Oprogramowania 2. Wymagania Leszek J Chmielewski Wydział Zastosowań Informatyki i Matematyki SGGW lchmiel.pl.

Podobne prezentacje


Prezentacja na temat: "Inżynieria Oprogramowania 2. Wymagania Leszek J Chmielewski Wydział Zastosowań Informatyki i Matematyki SGGW lchmiel.pl."— Zapis prezentacji:

1 Inżynieria Oprogramowania 2. Wymagania Leszek J Chmielewski Wydział Zastosowań Informatyki i Matematyki SGGW lchmiel.pl

2 Inżynieria oprogramowania 2. Wymagania 2/58 Literatura Ian Sommerville - rozdział 5 i 6

3 Inżynieria oprogramowania 2. Wymagania 3/58 Cele Rozumieć pojęcie wymagań użytkownika i wymagań systemowych oraz wiedzieć, dlaczego te dwa rodzaje wymagań mogą być zapisywane za pomocą różnych notacji Rozumieć różnice między wymaganiami funkcjonalnymi i niefunkcjonalnymi Znać metody zapisywania wymagań Wiedzieć, jak wymagania mogą być zorganizowane w dokumentacji wymagań stawianych oprogramowaniu

4 Inżynieria oprogramowania 2. Wymagania 4/58 Plan Wstęp Wymagania funkcjonalne i niefunkcjonalne Wymagania użytkownika Wymagania systemowe Dokumentacja wymagań stawianych oprogramowaniu

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

6 Inżynieria oprogramowania 2. Wymagania 6/58 Co to jest wymaganie? W przemyśle informatycznym pojęcie wymagania 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.

7 Inżynieria oprogramowania 2. Wymagania 7/58 Dlaczego występują rozbieżności Jeśli firma chce podpisać kontrakt na wielkie przedsięwzięcie budowy oprogramowania, to musi najpierw określić swoje wymagania w odpowiednio abstrakcyjny sposób, aby z góry nie definiować rozwiązań. Wymagania muszą być spisane, aby różni wykonawcy mogli ubiegać się o ten kontrakt, być może oferując różne sposoby spełniania oczekiwać firmy – klienta. Gdy kontrakt jest już podpisany, wykonawca musi zapisać klientowi definicję systemu, podając więcej szczegółów, aby klient mógł zrozumieć i zweryfikować to, co system będzie robił. Oba te dokumenty mogą nosić nazwę dokumentacji wymagań stawianych systemowi.

8 Inżynieria oprogramowania 2. Wymagania 8/58 Typy wymagań Wymagania użytkownika wyrażenia w języku naturalnym lub diagramy o usługach oczekiwanych od systemu o ograniczeniach, w których system ma działać Wymagania systemowe szczegółowo ustalają usługi systemu i ograniczenia zwane czasem specyfikacją funkcjonalną precyzyjne Specyfikacja projektu oprogramowania abstrakcyjny opis projektu oprogramowania jest podstawą bardziej szczegółowego projektu i implementacji

9 Inżynieria oprogramowania 2. Wymagania 9/58 Wymagania użytkownika systemu Wymagania użytkownika Oprogramowanie musi zapewniać mechanizmy reprezentowania i dostępu do plików zewnętrznych tworzonych przez inne narzędzia. Wymagania systemowe 1.Użytkownik powinien mieć możliwość definiowania typów plików zewnętrznych. 2.Każdy typ pliku zewnętrznego może mieć przypisane narzędzie do obróbki takich plików. 3.Każdy typ pliku zewnętrznego może być przedstawiony w postaci charakterystycznej ikony na ekranie użytkownika. 4.Należy zapewnić udogodnienia do definiowania przez użytkownika ikon odpowiadających typom plików zewnętrznych. 5.Gdy użytkownik wybierze ikonę powiązaną z plikiem zewnętrznym, następuje zastosowanie do tego pliku narzędzia skojarzonego z typem tego pliku.

10 Inżynieria oprogramowania 2. Wymagania 10/58 Czytelnicy rodzajów specyfikacji Wymagania użytkownika Wymagania systemowe Specyfikacja projektu oprogramowania Menedżerowie klienta Użytkownicy systemu Inżynierowie klienta Menedżerowie zleceniobiorcy Architekci systemu Użytkownicy systemu Inżynierowie klienta Architekci systemu Twórcy oprogramowania Inżynierowie klienta Architekci systemu Twórcy oprogramowania

11 Inżynieria oprogramowania 2. Wymagania 11/58 Wymagania funkcjonalne stwierdzenia, jakie usługi ma oferować system, jak ma reagować na określone dane wejściowe, jak ma się zachowywać w określonych sytuacjach; czego system nie powinien robić Wymagania niefunkcjonalne ograniczenia usług i funkcji systemu: ograniczenia czasowe, ograniczenia dotyczące procesu tworzenia, standardy itd. Wymagania dziedzinowe – f. lub nief. Pochodzą z dziedziny zastosowania systemu, odzwierciedlają jej charakterystykę W. funkcjonalne, niefunkcjonalne,...

12 Inżynieria oprogramowania 2. Wymagania 12/58 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.

13 Inżynieria oprogramowania 2. Wymagania 13/58 Przykłady wymagań systemowych 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, który będzie można skopiować do pamięci trwałej konta użytkownika

14 Inżynieria oprogramowania 2. Wymagania 14/58 Nieścisłe formułowanie wymagań Natura programisty każe mu interpretować jednoznaczne wymagania tak, aby uprościć implementację. Zwykle nie jest to jednak to, czego chciał klient. Należy opracować nowe wymagania i dokonać zmian w systemie. Opóźnia to dostarczenie systemu i podnosi koszty. Rozważmy wymaganie stawiane systemowi biblioteki, które mówi o odpowiednich narzędziach do oglądania: Celem tego wymagania jest zapewnienie narzędzia do oglądania wszystkich tych formatów. Programista działający pod presją czasu może udostępnić po prostu narzędzie do oglądania tekstu i ogłosić spełnienie wymagania.

15 Inżynieria oprogramowania 2. Wymagania 15/58 Kompletność i spójność 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 wielkich złożonych systemów nie da się 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

16 Inżynieria oprogramowania 2. Wymagania 16/58 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.

17 Inżynieria oprogramowania 2. Wymagania 17/58 Klasyfikacja w.niefunkcjonalnych Wymagania produktowe Określają zachowanie produktu. Np.: 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 - kliencie i w firmie - wytwórcy. Wymagania zewnętrzne Szeroka kategoria Np. interakcje systemu z innymi systemami wymagania prawne.

18 Inżynieria oprogramowania 2. Wymagania 18/58 Typy wymagań niefunkcjonalnych Wymagania niefunkcjonalne Wymagania przenośności Wymagania niezawodności Wymagania sprawnościowe Wymagania etyczne Wymagania zewnętrzne Wymagania współpracy Wymagania produktowe Wymagania organizacyjne Wymagania efektywnościowe Wymagania użyteczności Wymagania dostawy Wymagania implementacyjne Wymagania standardów Wymagania prawne Wymagania pamięciowe Wymagania ochrony prywatności Wymagania zabezpieczeń

19 Inżynieria oprogramowania 2. Wymagania 19/58 Przykłady w. niefunkcjonalnych Wymaganie produktowe Wszelka niezbędna komunikacja między systemem a 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 określonym standardzie. Wymaganie zewnętrzne System nie powinien ujawniać operatorom żadnych danych osobowych klientów oprócz nazwisk i numerów identyfikacyjnych.

20 Inżynieria oprogramowania 2. Wymagania 20/58 Cele i wymagania Powszechny problem: Trudno zweryfikować wymagania niefunkcjonalne

21 Inżynieria oprogramowania 2. Wymagania 21/58 Przykłady Cel systemu System powinien być łatwy w użyciu dla doświadczonych kontrolerów, a sposób jego organizacji powinien zmniejszać liczbę błędów użytkownika. Weryfikowalne wymaganie niefunkcjonalne Doświadczeni kontrolerzy powinni móc używać wszystkich funkcji systemu po szkoleniu trwającym dwie godziny. Po tym szkoleniu średnia liczba błędów robionych przez doświadczonych użytkowników nie powinna przekroczyć dwóch dziennie.

22 Inżynieria oprogramowania 2. Wymagania 22/58 Miary do specyfikowania wymagań niefunkcjonalnych 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żytkownika Czas odświeżenia ekranu Kilobajty Liczba układów pamięci Czas szkolenia Liczba okien pomocy Średni czas bez awarii Prawdopodobieństwo niedostępności Częstość błędów Dostępność Czas uruchamiania po awarii Ułamek zdarzeń powodujących awarie Prawdopodobieństwo zniszczenia danych po awarii Procent poleceń zależnych od platformy Liczba docelowych systemów

23 Inżynieria oprogramowania 2. Wymagania 23/58 Problemy z określeniem 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. W zasadzie należy odróżnić wymagania funkcjonalne i niefunkcjonalne w dokumentacji wymagań. W praktyce jest to jednak trudne.

24 Inżynieria oprogramowania 2. Wymagania 24/58 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.

25 Inżynieria oprogramowania 2. Wymagania 25/58 Wymagania stawiane systemowi biblioteki Wszystkie bazy danych powinny być dostępne przez jednolity interfejs użytkownika, którego podstawą jest przyjęty standard. Ze względu na ochronę praw autorskich niektóre dokumenty należy składać natychmiast po ich otrzymaniu. Zależnie od wymagań użytkownika, dokumenty te będą drukowane lokalnie na serwerze systemowym i przekazywane do rąk czytelnika albo wysyłane na drukarkę sieciową.

26 Inżynieria oprogramowania 2. Wymagania 26/58 Wymagania dziedzinowe Opóźnienie hamującego pociągu – zależne od sterowania, nachylenia terenu, typu pociągu Czas między przeglądami samochodu w wypożyczalni – krótszy, niż samochodu flotowego firmy Obliczenia fizyczne – równania różniczkowe, układy równań nieliniowych itp.

27 Inżynieria oprogramowania 2. Wymagania 27/58 Problemy z w. dziedzinowymi Język specyficzny dla dziedziny – inżynierowie oprogramowania nie rozumieją Eksperci pomijają informację, ponieważ jest dla nich oczywista Nieoczywista dla twórców systemu – niezadowalająca implementacja

28 Inżynieria oprogramowania 2. Wymagania 28/58 Wymagania użytkownika wyrażenia w języku naturalnym lub diagramy o usługach oczekiwanych od systemu o ograniczeniach, w których system ma działać Wymagania systemowe szczegółowo ustalają usługi systemu i ograniczenia zwane czasem specyfikacją funkcjonalną precyzyjne Specyfikacja projektu oprogramowania abstrakcyjny opis projektu oprogramowania jest podstawą bardziej szczegółowego projektu i implementacji

29 Inżynieria oprogramowania 2. Wymagania 29/58 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

30 Inżynieria oprogramowania 2. Wymagania 30/58 Problemy z językiem naturalnym Brak jasności trudno wyrażać się precyzyjnie i jednoznacznie bez nadmiernej długości tekstu nieczytelność 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

31 Inżynieria oprogramowania 2. Wymagania 31/58 Przykład: baza danych Baza danych powinna wspomagać generowanie obiektów sterujących i konfiguracyjnych, tzn. obiektów, które same są grupami innych obiektów bazy danych. Udogodnienia do sterowania konfiguracją powinny umożliwiać dostęp do obiektów w pewnej wersji grupy za pomocą niepełnej nazwy.

32 Inżynieria oprogramowania 2. Wymagania 32/58 Przykład: siatka edytora Udogodnienia siatki. Przez opcje panelu sterowania użytkownik może uaktywnić siatkę w centymetrach lub w calach, która będzie pomagała w umieszczaniu bytów na diagramie. Siatka może być włączona i wyłączona w dowolnej chwili sesji edycji; to samo dotyczy przełączania między calami i centymetrami. Opcja siatki będzie dostępna w widoku zmniejsz, aby dopasować, ale liczba linii siatki będzie wówczas zmniejszona, aby uniknąć zapełnienia małego diagramu liniami siatki.

33 Inżynieria oprogramowania 2. Wymagania 33/58 Problemy przy stawianiu wymagań Unikać zbyt wielu informacji: ogranicza to wolność twórców systemu w wyborze innowacyjnych rozwiązań utrudnia zrozumienie Uzasadnienia 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 tylko tam, gdzie jest opis działania

34 Inżynieria oprogramowania 2. Wymagania 34/58 Przykł.: Siatka edytora 2.6 Siatka Edytor będzie udostępniał siatkę, tzn. matrycę linii pionowych jako tło okna edytora. Siatka powinna być pasywna, tzn. za układanie bytów odpowiada użytkownik. Uzasadnienie: Siatka pomaga użytkownikowi w tworzeniu schludnego diagramu ze starannie poukładanymi bytami. Chociaż siatka aktywna, przy której byty przeskakują do linii siatki, może być użyteczna, jednak wówczas układ diagramu jest nieprecyzyjny. Użytkownik jest najwłaściwszą osobą do decydowania o położeniu bytów. Specyfikacja: ECLIPSE/WS/Tools/DE/FS Punkt 5.6

35 Inżynieria oprogramowania 2. Wymagania 35/58 Przykład: Węzły Dodawanie węzłów do projektu Edytor będzie udostępniał użytkownikom udogodnienia do dodawania do swoich projektów węzłów określonego typu Sekwencja czynności, które prowadzą do dodania węzła, powinna być następująca: 1. Użytkownik powinien wybrać typ węzła, jaki należy dodać 2. Użytkownik powinien przesunąć wskaźnik do przybliżonego miejsca nowego węzła na diagramie i zalecić dodanie symbolu węzła w tym punkcie 3. Użytkownik powinien następnie przeciągnąć węzeł do jego ostatecznego położenia Uzasadnienie: Użytkownik jest najwłaściwszą osobą do decydowania o położeniu węzłów na diagramie. Takie podejście daje użytkownikowi całkowite panowanie nad wyborem typu węzła i jego umiejscowieniem Specyfikacja: ECLIPSE/WS/Tools/DE/FS Punkt 3.5.1

36 Inżynieria oprogramowania 2. Wymagania 36/58 Opracuj standardowy format Konsekwentnie używaj języka W szczególności rozróżnij wymagania obowiązkowe od wskazanych Wyróżniaj (wytłuszczenia, kursywy) główne części wymagania. Unikaj, jak tylko się da, żargonu komputerowego. Wymagania użytkownika: Porady

37 Inżynieria oprogramowania 2. Wymagania 37/58 Wymagania systemowe Wymagania użytkownika wyrażenia w języku naturalnym lub diagramy o usługach oczekiwanych od systemu o ograniczeniach, w których system ma działać Wymagania systemowe szczegółowo ustalają usługi systemu i ograniczenia zwane czasem specyfikacją funkcjonalną precyzyjne Specyfikacja projektu oprogramowania abstrakcyjny opis projektu oprogramowania jest podstawą bardziej szczegółowego projektu i implementacji

38 Inżynieria oprogramowania 2. Wymagania 38/58 Wymagania systemowe Wymagania systemowe są bardziej szczegółowymi opisami wymagań użytkownika. Mogą być podstawą kontraktu na implementacje 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.

39 Inżynieria oprogramowania 2. Wymagania 39/58 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.

40 Inżynieria oprogramowania 2. Wymagania 40/58 Dalsze kłopoty z językiem naturalnym Niejednoznaczność języka naturalnego prowadzi do nieporozumień. Jackson (1995) daje wyśmienity przykład takiej sytuacji, opisując symbole wyświetlane przez ruchome schody. Mówią one buty trzeba założyć i psy trzeba nieść Do czytelnika należy stwierdzenie, czy dwa wymagania są takie same, czy też się od siebie różnią. Nie ma łatwego podziału wymagań w języku naturalnym na moduły. Znalezienie wszystkich powiązanych wymagań może być trudne.

41 Inżynieria oprogramowania 2. Wymagania 41/58 Notacje specyfikacji wymagań NotacjaOpis Strukturalny język naturalny Tak, ale ograniczony, sformalizowany, uściślony. Formularze i szablony Języki opisu projektu Język podobny do języka programowania, z odpowiednimi udogodnieniami Notacje graficzne Języki graficzne z dopiskami tekstowymi. Pierwszy taki język: SADT, Obecnie: UML. Przypadki użycia. Specyfikacje matematycz- ne Skończone maszyny stanowe, zbiory,.... Ścisłe, ale niezrozumiałe dla większości klientów. Zazwyczaj nie do zastosowania w kontrakcie.

42 Inżynieria oprogramowania 2. Wymagania 42/58 Ograniczony podzbiór języka naturalnego, przeznaczony do zapisywania wymagań systemowych Zaleta: zachowując wyrazistość i zrozumiałość języka naturalnego zapewnia w pewnym stopniu jednolitość specyfikacji Notacje mogą ograniczać używaną terminologię Używa się szablonów Dodane konstrukcje sterujące podobne do spotykanych w językach oprogramowania i graficzne wyróżnienia do podziału specyfikacji Strukturalny język naturalny

43 Inżynieria oprogramowania 2. Wymagania 43/58 Formularz do definiowania wymagań Opis specyfikowanej funkcji lub bytu Opis jej danych wejściowych i źródło ich pochodzenia Opis jej danych wyjściowych i miejsce ich przeznaczenia Określenie, z których innych bytów się korzysta (część wymaga) Jeśli użyto podejścia funkcjonalnego, to jest wywołany warunek początkowy, który musi być prawdziwy przed wywołaniem tej funkcji, oraz warunek końcowy, który musi być prawdziwy po wywołaniu funkcji. Opis efektów ubocznych operacji (jeśli występują)

44 Inżynieria oprogramowania 2. Wymagania 44/58 Przykł: Standardowy formularz ECLIPSE/Workstation/Tools/DE/FS/3.5.1 Funkcja. Dodaj węzeł Opis. Dodaje węzeł do istniejącego projektu. Użytkownik wybiera typ i położenie węzła. Po dodaniu do projektu węzeł jest zaznaczony. Użytkownik wybiera miejsce węzła przesuwając wskaźnik na obszar, w którym dodano węzeł. Dane wejściowe. Typ węzła, Położenie węzła, Identyfikator projektu Źródło. Typ węzła i Położenie węzła pochodzą od użytkownika, a Identyfikator projektu z bazy danych Dane wejściowe. Identyfikator projektu Przeznaczenie. Baza danych projektów. Projekt jest utrwalany w bazie danych po zakończeniu operacji Wymagania. Korzeniem grafu projektu musi być dany identyfikator projektu Warunek początkowy. Projekt jest otwarty i wyświetlony na ekranie użytkownika Warunek końcowy. Projekt nie uległ zmianie z wyjątkiem dodania węzła zadanego typu o zadanym położeniu Efekty uboczne. Nie ma

45 Inżynieria oprogramowania 2. Wymagania 45/58 PDL: Program Description Language Unikamy niejednoznaczności charakterystycznych dla języka naturalnego Używamy PDL: Gdy operacja jest specyfikowana jako ciąg prostszych akcji, których kolejność wykonania jest istotna. Opisy takich sekwencji w języku naturalnym są czasami mylące, zwłaszcza gdy te ciągi obejmują zagnieżdżone warunki i pętle. Gdy trzeba wyspecyfikować interfejsy sprzętowe i programowe. W wielu wypadkach interfejsy między podsystemami są definiowane w specyfikacji wymagań systemowych. PDL umożliwia definiowanie typów i obiektów interfejsowych. Specyfikacje wymagań w PDL

46 Inżynieria oprogramowania 2. Wymagania 46/58 Przykład: PDL – bankomat Class Bankomat { // tu deklaracje public static void main (String args []) throws ZłaKarta { try { taKarta.odczytaj(); //może zgłosić wyjątek ZłaKarta pin = Klawiatura.odczytajPin();próby =1; while (!taKarta.pin.equals(pin) & próby < 4) { pin = Klawiatura.odczytajPin(); próby = próby + 1; } if (!taKarta. pin.equals(pin)) throw new ZłaKarta (Zły PIN); toSaldo = taKarta.odczytajSaldo(); do { Ekran.pytanie(Wybierz usługę); usługa = Ekran.dotkniętyKlawisz(); switch (usługa) { case Usługi.wypłataZPokwitowaniem: wymaganePokwitowanie = true;...

47 Inżynieria oprogramowania 2. Wymagania 47/58 Wady PDL Język może nie być wystarczająco wyrazisty, aby określić funkcjonalność systemu Notacja zrozumiała tylko dla osób, które znają podstawy języków programowania Wymaganie może być potraktowane jako specyfikacja projektu, a nie jako model, który ma pomóc użytkownikom w zrozumieniu systemu

48 Inżynieria oprogramowania 2. Wymagania 48/58 Wady języka naturalnego - przykład Żona informatyka wysyła go po zakupy. - Kup parówki, a jak będą jajka, to kup dziesięć. Człowiek po wejściu do sklepu pyta: - Czy są jajka? - Tak - odpowiada sprzedawca. - To poproszę dziesięć parówek. Kup parówki (Ile?) Jajka? 10 parówekIle parówek? (???) TakNie Niespójne. Nie wykonywać. Dopracować.

49 Inżynieria oprogramowania 2. Wymagania 49/58 Specyfikacja interfejsów Większość systemów oprogramowania musi współdziałać z innymi systemami, które już zaimplementowano i zainstalowano w ich środowisku Trzy typy interfejsów Interfejsy proceduralne: oferują usługi Struktury danych przekazywanych między podsystemami Reprezentacje danych (do poziomu bitów) przekazywanych między podsystemami Formalne notacje umożliwiają definiowanie interfejsów w sposób jednoznaczny, ale ich wyspecjalizowana natura oznacza, że są niezrozumiałe bez odrębnego szkolenia

50 Inżynieria oprogramowania 2. Wymagania 50/58 Przykład: Interfejs serwera druku

51 Inżynieria oprogramowania 2. Wymagania 51/58 Dokumentacja wymagań Dokumentacja (specyfikacja) wymagań stawianych oprogramowaniu – Software Requirements Specification (SRS) jest oficjalną deklaracją tego, co jest wymagane od wytwórców systemu Powinna zawierać zarówno wymagania użytkownika stawiane systemowi, jak i szczegółowe specyfikacje wymagań systemowych Nie jest projektem: powinna opisywać co system ma robić, a nie jak to robić

52 Inżynieria oprogramowania 2. Wymagania 52/58 Klienci systemu Menedżerowie Inżynierowie systemów Inżynierowie testów systemu Inżynierowie pielęgnacji systemów 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ć testy zatwierdzające system Używają wymagań jako pomocy w zrozumieniu systemu i związków między jego częściami Użytkownicy dokumentacji wymagań

53 Inżynieria oprogramowania 2. Wymagania 53/58 Określa zachowanie systemu jedynie z zewnątrz Określa ograniczenia implementacji Łatwa do zmian (giętka) Informator dla konserwatorów systemu Obejmuje przewidywania przyszłego cyklu życia systemu Charakteryzuje akceptowalne reakcje na niepożądane zdarzenia Wymagania dla dokumentacji wymagań

54 Inżynieria oprogramowania 2. Wymagania 54/58 Standard wymogów IEEE 1. Wstęp 1.1. Przeznaczenie tej dokumentacji wymagań 1.2. Zakres produktu 1.3 Definicje, akronimy i 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 – Standard IEEE zbyt ogólny jako standard firmowy – Dobra podstawa do modyfikacji

55 Inżynieria oprogramowania 2. Wymagania 55/58 Struktura dokumentacji wymagań Przedmowa Wstęp Słownik Definicja wymagań użytkownika Architektura systemu Specyfikacja wymagań systemowych Modele systemu Ewolucja systemu Dodatki Skorowidz

56 Inżynieria oprogramowania 2. Wymagania 56/58 Podsumowanie W wymaganiach stawianych systemowi oprogramowania ustala się co system powinien robić definiuje się ograniczenia działania i implementacji Wymagania funkcjonalne charakterystyki usług, które system ma oferować albo opisy sposobu przeprowadzania obliczeń Wymagania niefunkcjonalne wymagania produktowe: ograniczają system wymagania procesu: dotyczą procesu tworzenia wymagania zewnętrzne: zwykle są powiązane z pojawiającymi się właściwościami systemu, a zatem stosują się do systemu jako całości

57 Inżynieria oprogramowania 2. Wymagania 57/58 Podsumowanie Wymagania użytkownika przeznaczone dla osób, które mają używać i zaopatrywać się w system język naturalny, tabele i diagramy, zrozumiałe Wymagania systemowe informują precyzyjnie o funkcjach systemu dla jednoznaczności można je zapisać w języku strukturalnym; może to być strukturalna postać języka naturalnego, język oparty na języku oprogramowania wysokiego poziomu lub specjalny język do specyfikowania wymagań

58 Inżynieria oprogramowania 2. Wymagania 58/58 Podsumowanie Dokumentacja wymagań jest uzgodnionym zapisem wymagań systemowych należy nadać jej odpowiednią strukturę, aby mogła być używana zarówno przez klientów systemu, jak i twórców oprogramowania

59 Inżynieria oprogramowania 2. Wymagania 59/58 Dziękuję


Pobierz ppt "Inżynieria Oprogramowania 2. Wymagania Leszek J Chmielewski Wydział Zastosowań Informatyki i Matematyki SGGW lchmiel.pl."

Podobne prezentacje


Reklamy Google