Pobieranie prezentacji. Proszę czekać

Pobieranie prezentacji. Proszę czekać

©Ian Sommerville 2000 Inżynieria oprogramowania,, Rozdział 5 Slide 1 Wymagania stawiane oprogramowaniu l Przedstawienie zagadnienia wymagań stawianych.

Podobne prezentacje


Prezentacja na temat: "©Ian Sommerville 2000 Inżynieria oprogramowania,, Rozdział 5 Slide 1 Wymagania stawiane oprogramowaniu l Przedstawienie zagadnienia wymagań stawianych."— Zapis prezentacji:

1 ©Ian Sommerville 2000 Inżynieria oprogramowania,, Rozdział 5 Slide 1 Wymagania stawiane oprogramowaniu l Przedstawienie zagadnienia wymagań stawianych systemowi oprogramowania i opisanie różnych sposobów wyrażania tych wymagań.

2 ©Ian Sommerville 2000 Inżynieria oprogramowania,, Rozdział 5 Slide 2 Cele l Rozumieć pojęcie wymagań użytkownika i wymagań systemowych oraz wiedzieć, dlaczego te dwa rodzaje wymagań mogą być zapisywane za pomocą różnych notacji. l Rozumieć różnice między wymaganiami funkcjonalnymi i niefunkcjonalnymi. l Znać dwie metody zapisywania wymagań, tzn. strukturalny język naturalny i opisy oparte na językach programowania. l Wiedzieć, jak wymagania mogą być zorganizowane w dokumentacji wymagań stawianych oprogramowaniu.

3 ©Ian Sommerville 2000 Inżynieria oprogramowania,, Rozdział 5 Slide 3 Zawartość l Wymagania funkcjonalne i niefunkcjonalne l Wymagania użytkownika l Wymagania systemowe l Dokumentacja wymagań stawianych oprogramowaniu

4 ©Ian Sommerville 2000 Inżynieria oprogramowania,, Rozdział 5 Slide 4 Inżynieria wymagań l Opisy usług i ograniczeń są wymaganiami stawianymi systemowi. l Proces wynajdowania, analizowania, dokumentowania oraz sprawdzania usług i ograniczeń nosi nazwę inżynierii wymagań.

5 ©Ian Sommerville 2000 Inżynieria oprogramowania,, Rozdział 5 Slide 5 Co to jest wymóg? l W przemyśle informatycznym pojęcie wymaganie nie jest stosowane konsekwentnie. l Niekiedy wymaganie jest postrzegane jako zapisane na wysokim poziomie, abstrakcyjne określenie usług, które system powinien oferować, albo ograniczenie działania systemu. l Niektórzy określają wymaganie jako szczegółową, matematycznie formalną definicję funkcji systemu.

6 ©Ian Sommerville 2000 Inżynieria oprogramowania,, Rozdział 5 Slide 6 Dlaczego występują rozbieżności (Davis,1993)

7 ©Ian Sommerville 2000 Inżynieria oprogramowania,, Rozdział 5 Slide 7 Typy wymagań l 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ć. l Wymagania systemowe Szczegółowo ustalają usługi systemu i ograniczenia. Dokumentacja wymagań systemowych, zwana czasem specyfikacją funkcjonalną, powinna być precyzyjna. l Specyfikacja projektu oprogramowania Jest abstrakcyjnym opisem projektu oprogramowania, który jest podstawa bardziej szczegółowego projektu i implementacji.

8 ©Ian Sommerville 2000 Inżynieria oprogramowania,, Rozdział 5 Slide 8 Wymagania użytkownika systemu Definicja wymagań użytkownika 1.Oprogramowanie musi zapewniać mechanizmy reprezentowania i dostępu do plików zewnętrznych tworzonych przez inne narzędzia. Specyfikacja wymagań systemowych 1.1 Użytkownik powinien mieć możliwość definiowania typów plików zewnętrznych. 1.2 Każdy typ pliku zewnętrznego może mieć przypisane narzędzie do obróbki takich plików. 1.3 Każdy typ pliku zewnętrznego może być przedstawiony w postaci charakterystycznej ikony na ekranie użytkownika. 1.4 Należy zapewnić udogodnienia do definiowania przez użytkownika ikon odpowiadających typom plików zewnętrznych. 1.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.

9 ©Ian Sommerville 2000 Inżynieria oprogramowania,, Rozdział 5 Slide 9 Czytelnicy różnych 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 (być może) Architekci systemu Twórcy oprogramowania

10 ©Ian Sommerville 2000 Inżynieria oprogramowania,, Rozdział 5 Slide 10 Wymagania stawiane systemom oprogramowania l 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ć. l Wymagania niefunkcjonalne To ograniczenia usług i funkcji systemu. Obejmują ograniczenia czasowe, ograniczenia dotyczące procesu tworzenia, standardy itd. l Wymagania dziedzinowe Pochodzą z dziedziny zastosowania systemu odzwierciedlają jej charakterystykę. Mogą być funkcjonalne lub niefunkcjonalne.

11 ©Ian Sommerville 2000 Inżynieria oprogramowania,, Rozdział 5 Slide 11 Wymagania funkcjonalne l Wymagania funkcjonalne stawiane systemowi opisują funkcjonalność lub usługi, które system powinien oferować. l Zależą od rodzaju tworzonego oprogramowania, spodziewanych użytkowników oprogramowania i rodzaju wytwarzanego systemu. l 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.

12 ©Ian Sommerville 2000 Inżynieria oprogramowania,, Rozdział 5 Slide 12 Przykłady wymagań systemowych l Użytkownik będzie mógł przeszukać zbiór wszystkich baz danych lub wybrać tylko ich podzbiór. l System udostępni odpowiednie narzędzia do oglądania, aby użytkownik mógł czytać dokumenty z magazynu. l 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.

13 ©Ian Sommerville 2000 Inżynieria oprogramowania,, Rozdział 5 Slide 13 Problemy wynikające z braku ścisłego określania specyfikacji wymagań l Natura programisty każe mu interpretować jednoznaczne wymagania tak, aby uprościć implementację. Zwykle nie jest to jednak to, czego chciał klient. l Należy opracować nowe wymagania i dokonać zmian w systemie. Opóźnia to dostarczenie systemu i podnosi koszty. l Rozważmy drugie na tej liście wymaganie stawiane systemowi biblioteki, które mówi o odpowiednich narzędziach do oglądania. l Celem tego wymagania jest zapewnienie narzędzia do oglądania wszystkich tych formatów. l 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.

14 ©Ian Sommerville 2000 Inżynieria oprogramowania,, Rozdział 5 Slide 14 Kompletność i spójność specyfikacji wymagań funkcjonalnych l W zasadzie specyfikacja wymagań funkcjonalnych stawianych systemowi powinna być kompletna i spójna. l Kompletność oznacza, że wszystkie potrzebne użytkownikowi usługi powinny być zdefiniowane. l Spójność oznacza, że wymagania nie powinny mieć sprzecznych definicji. l 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.

15 ©Ian Sommerville 2000 Inżynieria oprogramowania,, Rozdział 5 Slide 15 Wymagania niefunkcjonalne l Mogą definiować ograniczenia systemu, takie jak możliwości urządzeń wejścia-wyjścia i reprezentacje danych używane przez interfejsy systemu. l 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ć. l 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.

16 ©Ian Sommerville 2000 Inżynieria oprogramowania,, Rozdział 5 Slide 16 Klasyfikacja wymagań niefunkcjonalnych l 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. l Wymagania organizacyjne Wynikają ze strategii i procedur w firmie klienta i w firmie wytwórcy. l 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.

17 ©Ian Sommerville 2000 Inżynieria oprogramowania,, Rozdział 5 Slide 17 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ń

18 ©Ian Sommerville 2000 Inżynieria oprogramowania,, Rozdział 5 Slide 18 Przykłady wymagań niefunkcjonalnych l Wymaganie produktowe 4.C.8 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. l Wymaganie organizacyjne Proces tworzenia systemu i końcowe dokumenty powinny być zgodne z procesem i produktami zdefiniowanymi w standardzie XYZCo-SP-STAN-95. l Wymaganie zewnętrzne System nie powinien ujawniać operatorom żadnych danych osobowych klientów oprócz nazwisk i numerów identyfikacyjnych

19 ©Ian Sommerville 2000 Inżynieria oprogramowania,, Rozdział 5 Slide 19 Problemy związane z wymaganiami niefunkcjonalnymi l Powszechnie występującym problemem z wymaganiami niefunkcjonalnymi jest fakt, że czasem trudno je zweryfikować. l 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. l To jednak zostawia bardzo duży margines do interpretacji.

20 ©Ian Sommerville 2000 Inżynieria oprogramowania,, Rozdział 5 Slide 20 Przykłady l 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. l 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.

21 ©Ian Sommerville 2000 Inżynieria oprogramowania,, Rozdział 5 Slide 21 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

22 ©Ian Sommerville 2000 Inżynieria oprogramowania,, Rozdział 5 Slide 22 Trudności z określeniem wymagań l Klienci mogą nie być w stanie przetłumaczyć swoich celów na wymagania ilościowe. l Wymagania niefunkcjonalne są często sprzeczne lub powiązane z innymi wymaganiami funkcjonalnymi. l W zasadzie należy odróżnić wymagania funkcjonalne i niefunkcjonalne w dokumentacji wymagań. W praktyce jest to jednak trudne.

23 ©Ian Sommerville 2000 Inżynieria oprogramowania,, Rozdział 5 Slide 23 Wymagania dziedzinowe l Wymagania dziedzinowe wynikają bardziej z dziedziny zastosowania systemu niż z konkretnych potrzeb użytkowników. l Mogą być nowymi wymaganiami funkcjonalnymi, ograniczać istniejące wymagania funkcjonalne albo ustalać sposób wykonywania konkretnych obliczeń. l 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.

24 ©Ian Sommerville 2000 Inżynieria oprogramowania,, Rozdział 5 Slide 24 Przykład: wymagania stawiane systemowi biblioteki 1. Wszystkie bazy danych powinny być dostępne przez jednolity interfejs użytkownika, którego podstawą jest standard Z 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ą.

25 ©Ian Sommerville 2000 Inżynieria oprogramowania,, Rozdział 5 Slide 25 Wymagania dziedzinowe z systemu bezpieczeństwa ruchu pociągów l Tempo zmniejszania prędkości pociągu jest wyznaczane następująco: D pociągu = D sterowania + D nachylenia przy czym D nachylenia wynosi 9,81m/s 2 * wyrównane nachylenie/alfa, a 9,81m/s 2 /alfa są znane dla różnych typów pociągów.

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

27 ©Ian Sommerville 2000 Inżynieria oprogramowania,, Rozdział 5 Slide 27 Wymagania użytkownika l 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. l Należy je zapisywać w języku naturalnym, używając formularzy i prostych intuicyjnych diagramów.

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

29 ©Ian Sommerville 2000 Inżynieria oprogramowania,, Rozdział 5 Slide 29 Przykład: wymaganie stawiane bazie danych 4.A.5 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.

30 ©Ian Sommerville 2000 Inżynieria oprogramowania,, Rozdział 5 Slide 30 Przykład: wymaganie użytkownika stawiane siatce edytora 2.6 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.

31 ©Ian Sommerville 2000 Inżynieria oprogramowania,, Rozdział 5 Slide 31 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.

32 ©Ian Sommerville 2000 Inżynieria oprogramowania,, Rozdział 5 Slide 32 Definicja siatki w edytorze 2.6 Siatka Edytor będzie udostępniał siatkę, tzn. matrycę linii pionowych jako tło okna edytora. Ta sama 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

33 ©Ian Sommerville 2000 Inżynieria oprogramowania,, Rozdział 5 Slide 33 Wymagania użytkownika wobec dodawania węzłów 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

34 ©Ian Sommerville 2000 Inżynieria oprogramowania,, Rozdział 5 Slide 34 Rady do zapisywania wymagań użytkownika l Opracuj standardowy format i spraw, aby wszystkie definicje wymagań były z nim zgodne. l Konsekwentnie używaj pojęć językowych. W szczególności rozróżnij wymagania obowiązkowe od wskazanych. l Stosuj wyróżnienia (wytłuszczenia, kursywy) do zaznaczania głównych części wymagania. l Unikaj, jak tylko się da, żargonu komputerowego.

35 ©Ian Sommerville 2000 Inżynieria oprogramowania,, Rozdział 5 Slide 35 Wymagania systemowe l Wymagania systemowe są bardziej szczegółowymi opisami wymagań użytkownika. l Mogą być podstawą kontraktu na implementacje systemu, powinny być zatem pełną i niesprzeczną specyfikacją całego systemu. l Są traktowane przez inżynierów oprogramowania jako punkt wyjścia do projektowania systemu. l Specyfikacja wymagań systemowych może zawierać różne modele systemu.

36 ©Ian Sommerville 2000 Inżynieria oprogramowania,, Rozdział 5 Slide 36 Wymagania, a projekt l W dokumentacji wymagań można zdefiniować wstępną architekturę systemu, aby nadać specyfikacji odpowiednia strukturę. Wymagania systemowe są zorganizowane zgodnie z podziałem na podsystemy wchodzące w skład systemu. l 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. l Użycie specyficznego projektu może być zewnętrznym wymaganiem systemowym.

37 ©Ian Sommerville 2000 Inżynieria oprogramowania,, Rozdział 5 Slide 37 Zapis wymagań systemowych w języku naturalnym l 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ść l Specyfikacje wymagań są zbyt elastyczne. Tę samą rzecz można wyrazić na kilka sposobów. Do czytelnika należy stwierdzenie, czy dwa wymagania są takie same, czy też się od siebie różnią. l Nie ma łatwego podziału wymagań w języku naturalnym na moduły. Znalezienie wszystkich powiązanych wymagań może być trudne.

38 ©Ian Sommerville 2000 Inżynieria oprogramowania,, Rozdział 5 Slide 38 Notacje specyfikacji wymagań Notacja Opis Strukturalny język To podejście polega na definiowaniu standardowych formularzy naturalny i szablonów do wyrażania specyfikacji wymagań Języki opisu W tym podejściu używa się języka podobnego do języka programowania, projektu ale z bardziej abstrakcyjnymi elementami do specyfikowania wymagań poprzez model operacyjny systemu Notacje graficzne Do definiowania wymagań funkcjonalnych stawianych systemowi używa się języka graficznego z tekstowymi dopiskami. Ostatnio używa się przypadków użycia (Jacobsen i inni,1993). Specyfikacje 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.

39 ©Ian Sommerville 2000 Inżynieria oprogramowania,, Rozdział 5 Slide 39 Strukturalny język naturalny l Strukturalny język naturalny jest ograniczoną postacią języka naturalnego, przeznaczoną do zapisywania wymagań systemowych. l Zaleta tego podejścia jest to, że zachowując wyrazistość i zrozumiałość języka naturalnego potrafi zapewnić w jednolitość specyfikacji. l Notacje oparte na języku strukturalnym mogą ograniczać używaną terminologię i obejmować szablony do specyfikowania wymagań systemowych. l Zawierają zwykle konstrukcje sterujące podobne do spotykanych w językach oprogramowania i graficzne wyróżnienia do podziału specyfikacji.

40 ©Ian Sommerville 2000 Inżynieria oprogramowania,, Rozdział 5 Slide 40 Formularz do definiowania wymagań funkcjonalnych l Opis specyfikowanej funkcji lub bytu. l Opis jej danych wejściowych i źródło ich pochodzenia. l Opis jej danych wyjściowych i miejsce ich przeznaczenia. l Określenie, z których innych bytów się korzysta. l Jeśli użyto podejścia funkcjonalnego, to należy określić 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. l Opis efektów ubocznych operacji (jeśli występują).

41 ©Ian Sommerville 2000 Inżynieria oprogramowania,, Rozdział 5 Slide 41 Specyfikacja wymagań systemu z użyciem standardowego formularza 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

42 ©Ian Sommerville 2000 Inżynieria oprogramowania,, Rozdział 5 Slide 42 Specyfikacje wymagań w PDL l Niejednoznaczności charakterystycznych dla języka naturalnego można uniknąć przez opisywanie wymagań operacyjnie za pomocą języka opisu programów (Program Description Language, PDL). Jest on podobny do języków programowania takich jak Java i Ada. l Proponuje się używać PDL w dwóch następujących sytuacjach: 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.

43 ©Ian Sommerville 2000 Inżynieria oprogramowania,, Rozdział 5 Slide 43 Część opisu działania bankomatu za pomocą PDL 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 (!ta Karta.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;

44 ©Ian Sommerville 2000 Inżynieria oprogramowania,, Rozdział 5 Slide 44 Pewne wady użycia PDL do specyfikowania wymagań 1. Język używany do zapisu specyfikacji może nie być wystarczająco wyrazisty, aby określić funkcjonalność systemu. 2. Notacja jest zrozumiała jedynie dla osób, które znają podstawy języków programowania, ale można ją połączyć z użyciem strukturalnego języka naturalnego.

45 ©Ian Sommerville 2000 Inżynieria oprogramowania,, Rozdział 5 Slide 45 Specyfikacja interfejsów l Większość systemów oprogramowania musi współdziałać z innymi systemami, które już zaimplementowano i zainstalowano w ich środowisku. Taka sytuacja wymaga precyzyjnego wyspecyfikowania interfejsów pomiędzy nowym systemem a już działającymi systemami. l Trzy typy interfejsów: interfejsy proceduralne; struktury danych, które są przekazywane między podsystemami; reprezentacje danych. l Formalne notacje umożliwiają definiowanie interfejsów w sposób jednoznaczny, ale ich wyspecjalizowana natura oznacza, że są niezrozumiałe bez odrębnego szkolenia.

46 ©Ian Sommerville 2000 Inżynieria oprogramowania,, Rozdział 5 Slide 46 Opis interfejsu serwera drukowania za pomocą PDL opartego na Javie

47 ©Ian Sommerville 2000 Inżynieria oprogramowania,, Rozdział 5 Slide 47 Dokumentacja wymagań stawianych oprogramowaniu l Dokumentacja wymagań stawianych oprogramowaniu (nazywana czasem specyfikacją wymagań stawianych oprogramowaniu lub Software Requirements Specification, SRS) jest oficjalną deklaracją tego, co jest wymagane od wytwórców systemu. l Powinna zawierać zarówno wymagania użytkownika stawiane systemowi, jak i szczegółową specyfikacje wymagań systemowych l Nie jest projektem. Powinna opisywać co system ma robić, a nie jak to robić.

48 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ń

49 ©Ian Sommerville 2000 Inżynieria oprogramowania,, Rozdział 5 Slide 49 Wymagania, które powinny być spełnione przez dokumentację wymagań l Powinna określać zachowanie systemu jedynie z zewnątrz. l Powinna określać ograniczenia implementacji. l Powinno być łatwo ją zmieniać. l Powinna być informatorem dla konserwatorów systemu. l Powinna obejmować przewidywania przyszłego cyklu życia systemu. l Powinna charakteryzować akceptowalne relacje na niepożądane zdarzenia.

50 ©Ian Sommerville 2000 Inżynieria oprogramowania,, Rozdział 5 Slide 50 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

51 ©Ian Sommerville 2000 Inżynieria oprogramowania,, Rozdział 5 Slide 51 Struktura dokumentacji wymagań l Przedmowa l Wstęp l Słownik l Definicja wymagań użytkownika l Architektura systemu l Specyfikacja wymagań systemowych l Modele systemu l Ewolucja systemu l Dodatki l Skorowidz

52 ©Ian Sommerville 2000 Inżynieria oprogramowania,, Rozdział 5 Slide 52 Główne tezy l W wymaganiach stawianych systemowi oprogramowania ustala się co system powinien robić, oraz definiuje ograniczenia działania i implementację. l Wymagania funkcjonalne to charakterystyki usług, które system ma oferować, albo opisy sposobu przeprowadzania pewnych obliczeń. l Wymagania niefunkcjonalne dzieli się na wymagania produktowe, które ograniczają budowany system, wymagania procesu, które dotyczą procesu tworzenia, oraz 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.

53 ©Ian Sommerville 2000 Inżynieria oprogramowania,, Rozdział 5 Slide 53 Główne tezy l Wymagania użytkownika są przeznaczone dla osób, które mają używać i zaopatrywać się w system. Należy spisać je za pomocą języka naturalnego, tabel i diagramów tak, aby były zrozumiałe. l Wymagania systemowe służą do poinformowania w precyzyjny sposób o funkcjach, które system ma spełniać. Aby uniknąć niejednoznaczności, można je zapisać za pomocą jakiegoś języka strukturalnego. l Dokumentacja wymagań stawianych oprogramowaniu 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.


Pobierz ppt "©Ian Sommerville 2000 Inżynieria oprogramowania,, Rozdział 5 Slide 1 Wymagania stawiane oprogramowaniu l Przedstawienie zagadnienia wymagań stawianych."

Podobne prezentacje


Reklamy Google