Pobieranie prezentacji. Proszę czekać

Pobieranie prezentacji. Proszę czekać

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 1 Wymagania stawiane oprogramowaniu l Opis i specyfikacja systemu.

Podobne prezentacje


Prezentacja na temat: "©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 1 Wymagania stawiane oprogramowaniu l Opis i specyfikacja systemu."— Zapis prezentacji:

1 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 1 Wymagania stawiane oprogramowaniu l Opis i specyfikacja systemu

2 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 2 Cele l Rozumienie pojęć wymagań użytkownika i wymagań systemowych l Rozumienie różnic pomiędzy wymaganiami funkcjonalnymi i niefunkcjonalnymi l Poznanie dwóch metod zapisywania wymagań l Wiedza, jak wymagania mogą być organizowane w dokumentacji

3 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 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 Software Engineering, 6th edition. Chapter 5 Slide 4 Inżynieria wymagań l Proces ustalenia jakich usług użytkownik oczekuje od systemu i ograniczeń, które system musi spełniać zarówno podczas tworzenia jak i podczas działania l Wymagania to opisy usług, które system ma udostępniać i ograniczeń, które musi spełniać

5 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 5 Co to jest wymaganie l Może być zarówno abstrakcyjnym wysokiego poziomu opisem usługi jak również precyzyjnym matematycznym opisem działania konkretnej funkcji l Jest to nieuniknione gdyż wymagania mogą służyć w różnych celach Podstawa do podpisania kontraktu, czyli wymaganie otwarte Podstawa do stworzenia oprogramowania, czyli precyzyjne wymaganie zamknięte Oba te zdania opisują coś co nazywa się wymaganiami

6 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 6 Typy wymagań l Wymagania użytkownika Wyrażenia w języku naturalnym oraz diagramy o usługach oczekiwanych od systemu oraz o ograniczeniach. Pisane dla klienta l Wymagania systemowe Precyzyjna dokumentacja opisująca szczegółowo wszystkie usługi systemu i ograniczenia. Część kontraktu pomiędzy klientem a dostawcą l Specyfikacja projektu oprogramowania Abstrakcyjny opis projektu oprogramowania, który jest podstawą bardziej szczegółowego projektu i implementacji. Pisana dla programistów

7 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 7 Definicje i specyfikacje Definicja wymagań użytkownika Specyfikacja wymagań systemowych 1.Oprogramowanie musi zapewnić mechanizmy reprezentowania i dostępu do plików zewnętrznych tworzonych przez inne narzędzia a.Użytkownik powinien mieć możliwość definiowania typów plików zewnętrznych b.Każdy typ pliku zewnętrznego może mieć przypisane narzędzie do obróbki tego typu plików c.Każdy typ pliku zewnętrznego może być przedstawiony w postaci charakterystycznej ikony na ekranie użytkownika d.Należy zapewnić udogodnienia do definiowana przez użytkownika ikon odpowiadających typom plików zewnętrznych e.Gdy użytkownik wybierze ikonę powiązaną z plikiem zewnętrznym, następuje zastosowanie do tego pliku narzędzia skojarzonego z typem tego pliku

8 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 8 Czytelnicy różnych wymagań Wymagania użytkownika Wymagania systemowe Specyfikacja projektu oprogramowania Menedżerowie klienta Użytkownicy systemu Inżynierowie klienta Menedżerowi zleceniodawcy Architekci systemu Użytkownicy systemu Inżynierowie klienta Architekci systemu Twórcy oprogramowania Inżynierowie klienta (być może) Architekci systemu Twórcy oprogramowania

9 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 9 Wymagania funkcjonalne i niefunkcjonalne l Wymagania funkcjonalne Stwierdzenia opisujące, jakie usługi ma oferować system, jak ma reagować na określone dane wejściowe oraz jak ma reagować w określonych sytuacjach. l Wymagania niefunkcjonalne Ograniczenia usług i funkcji systemu obejmujące: ograniczenia czasowe, ograniczenia dotyczące procesu tworzenia, standardy itd. l Wymagania dziedzinowe Wymagania pochodzące z dziedziny zastosowania systemu i odzwierciedlające jego charakterystykę

10 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 10 Wymagania funkcjonalne l 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 Wymagania użytkownika mają zazwyczaj postać ogólną,,natomiast systemowe szczegółowo definiują funkcje systemu, wejścia wyjścia wyjątki itd..

11 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 11 Przykłady wymagań funkcjonalnych l Użytkownik będzie mógł przeszukać zbiór wszystkich danych lub wybrany podzbiór. l System dostarczy narzędzi do przeglądania dokumentów ze magazynu dokumentów. l Każde zamówienie będzie oznaczone unikatowym identyfikatorem (ORDER_ID), który będzie można skopiować do pamięci trwałej konta użytkownika.

12 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 12 Nieprecyzyjność wymagań l Kiedy wymagania nie są precyzyjnie wyrażone powstają problemy l Nieprecyzyjne wymagania są różnie interpretowane przez użytkowników i programistów l Rozważ użycie odpowiedniego rzecznika Intencje użytkownika Interpretacja programisty

13 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 13 Spójność i pełność wymagań l W założeniach wymagania powinny być spójne i pełne l Pełność Powinny opisywać wszystkie wymagane oczekiwania l Pełne Nie powinno być sprzeczności pomiędzy opisywanymi oczekiwaniami l W praktyce nie można stworzyć spójnego i pełnego opisu wymagań

14 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 14 Wymagania niefunkcjonalne l Opisują właściwości i ograniczenia systemu np. niezawodność, czas odpowiedzi, ilość miejsca na dysku. l Wymagania stawiane procesowi mogą specyfikować użycie określonego narzędzia, języka programowania lub metodologii projektowej. l Wymagania niefunkcjonalne mogą być istotniejsze od funkcjonalnych. Jeśli nie będą spełnione system będzie bezużyteczny.

15 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 15 Klasyfikacja wymagań niefunkcjonalnych l Dotyczące produktu Wymagania określające jak ma się zachowywać produkt. Np. wydajność, niezawodność l Dotyczące organizacji Wynikające ze strategii i procedur w firmach np. standardy procesu, wymagana dokumentacja, metoda projektowania. l Wymagania zewnętrzne Wynikające z czynników zewnętrznych dla systemu np. interakcja z systemami innych firm, wymagania prawne.

16 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 16 Typy wymagań niefunkcjonalnych Wymagania niefunkcjonalne Wymagania produktowe Wymagania organizacyjne Wymagania zewnętrzne Wymagania sprawnościowe Wymagania niezawodności Wymagania przenośności Wymagania współpracy Wymagania etyczne Wymagania zabezpieczeń Wymagania prawne Wymagania ochrony prywatności Wymagania implementacyjne Wymagania standardów Wymagania dostawy Wymagania użyteczności Wymagania efektywnościowe Wymagania pamięciowe

17 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 17 Przykłady wymagań niefunkcjonalnych l Wymaganie produktowe 4.C.8 Wszelka niezbędna komunikacja między APSE i użytkownikiem powinna dać się wyrazić za pomocą standardowego zestawu symboli Ady l Wymagania organizacyjne Proces tworzenia systemu i końcowe dokumenty powinny być zgodne z procesem i produktami zdefiniowanymi w XYZCo-SP-STAN-95 l Wymagania zewnętrzne System nie powinien ujawniać operatorom żadnych danych osobowych klientów oprócz nazwisk i numerów identyfikacyjnych

18 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 18 Cele i wymagania l Wymagania niefunkcjonalne mogą być trudne do precyzyjnego zapisania a nieprecyzyjne wymagania mogą być trudne do zweryfikowania l Cel Generalna intencja aby system coś spełniał l Weryfikowalne wymaganie niefunkcjonalne Stwierdzenie używające jakiejś miary, która może być obiektywne zmierzona l Cele mogą być przydatne dla programistów, gdyż przekazują wskazówki o priorytetach klienta

19 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 19 Przykłady l Cel System powinien być łatwy w użyciu dla doświadczonych kontrolerów, a sposób 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.

20 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 20 Miary wymagań WłaściwośćMiara SzybkośćLiczba transakcji na sek. Czas reakcji na zdarzenie Czas odświeżania ekranu RozmiarKilobajty Liczba układów pamięci RAM Łatwość użyciaCzas szkolenia Liczba okien pomocy NiezawodnośćŚredni czas bez awarii Prawdopodobieństwo niedostępności Częstość błędów Dostępność SolidnośćCzas uruchomienia po awarii Ułamek zdarzeń powodujących awarie Prawdopodobieństwo zniszczenia danych PrzenośnośćProcent poleceń zależnych od platformy Liczba docelowych systemów

21 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 21 Zależności między wymaganiami l W dużych systemach często występują konflikty pomiędzy wymaganiami funkcjonalnymi i niefunkcjonalnymi l System stacji kosmicznej Dla zminimalizowania wagi liczba chipów powinna być jak najmniejsza Dla oszczędności energii chipy powinny być energooszczędne Ale energooszczędne chipy będą zajmowały więcej miejsca, gdyż będzie ich potrzeba więcej. Które wymaganie jest ważniejsze?

22 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 22 Wymagania dziedzinowe l Wynikają bardziej z dziedziny zastosowania systemu niż z konkretnych potrzeb użytkowników l Mogą być nowymi wymaganiami funkcjonalnymi, ograniczać istniejące albo ustalać sposób wykonania konkretnych obliczeń l Jeśli będą niespełnione system może być bezużyteczny

23 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 23 Wymagania dziedzinowe systemu bibliotecznego l Wszystkie bazy danych powinny być dostępne przez standardowy interfejs zgodny ze standardem Z l Ze względu na ochronę praw autorskich niektóre dokumenty należy skasować natychmiast po ich otrzymaniu. Zależnie od wymagań użytkownika, dokumenty te będą drukowane lokalnie na serwerze systemowym i przekazywane do rąk użytkownika albo wysyłane na drukarkę sieciową.

24 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 24 System bezpieczeństwa ruchu kolei l Tempo hamowania pociągu powinno być obliczone jako: D train = D control + D gradient gdzie D gradient to 9.81ms 2 * wyrównane nachylenie/alfa a wartości 9.81ms 2 /alfa są różne dla różnych typów pociągów

25 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 25 Problemy z wymaganiami dziedzinowymi l Zrozumienie Wymagania są wyrażone w języku typowym dla dziedziny To często nie jest zrozumiałe dla programistów tworzących system l Milczące założenia Specjaliści w dziedzinie są tak przyzwyczajeni do danego wymagania, że często nie wyrażają go w postaci dokumentu

26 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 26 Wymagania użytkownika l Powinny opisywać funkcjonalne i niefunkcjonalne wymagania tak, aby były zrozumiałe dla użytkowników systemu nie posiadających wiedzy technicznej l Należy je zapisywać w języku naturalnym używając formularzy i intuicyjnych diagramów

27 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 27 Problemy z językiem naturalnym l Brak jasności Trudno uzyskać precyzję bez czynienia dokumentów nieczytelnymi i gadatliwymi l Sprzeczność wymagań Wymagania funkcjonalne i niefunkcjonalne łatwo się mieszają l Łączenie wymagań Kilka wymagań może być wyrażonych wspólnie

28 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 28 Wymaganie dla bazy danych 4.A.5 Baza danych powinna wspierać 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

29 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 29 Wymaganie dla siatki edytora 2.6 Udogodnienia siatki. Przez opcję panelu sterowania użytkownik może uaktywnić siatkę w centymetrach lub calach, która będzie pomagała w umieszczeniu bytów na diagramie. Siatka może być włączana i wyłączana 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.

30 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 30 Problemy z wymaganiami l Wymagania dla bazy danych zawierają zarówno opisy ogólne jak i szczegółowe Opisują koncepcję sterowania Zawierają szczegóły o tym, że grupy powinny być dostępne za pomocą niepełnych nazw l Wymagania dla edytora siatki łączą trzy grupy wymagań Pojęciowe wymagania funkcjonalne (istnienie siatki) Wymaganie niefunkcjonalne (cale lub centymetry) Niefunkcjonalne wymaganie stawiane interfejsowi użytkownika (jak się włącza i wyłącza siatkę)

31 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 31 Dobra struktura 2.6 Siatka Edytor będzie udostępniał siatkę, tzn. matrycę linii poziomych i pionowych jako tło okna edytora. Ta 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.

32 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 32 Precyzyjnie opisane wymaganie 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 zlecić dodanie symbolu 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

33 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 33 Rady dla piszących wymagania l Opracuj standard i używaj go dla wszystkich wymagań l Konsekwentnie używaj języka. Używaj będzie dla wymagań obowiązkowych a powinien dla oczekiwanych. l Stosuj wyróżnienia do zaznaczania głównych części wymagania l Unikaj żargonu komputerowego

34 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 34 Wymagania systemowe l Dokładniejsze wyrażenie wymagań użytkownika l Służą jako podstawa do zaprojektowania systemu l Mogą być użyte jako część kontraktu l Można je przedstawiać za pomocą modeli

35 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 35 Wymagania i projekt l Teoretycznie, wymagania powinny mówić co system powinien robić a projekt jak system powinien to robić l W praktyce trudno oddzielić projekt od wymagań Architektura może być zaprojektowana dla ustrukturalizowania wymagań System może współpracować z innymi systemami co ogranicza projekt Użycie specyficznego projektu może być zewnętrznym wymaganiem systemowym

36 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 36 Problemy ze specyfikacją w JN l Niejednoznaczność Czytający i piszący mogą rozumieć inne pojęcia pod postacią tych samych słów. l Elastyczność Ta sama rzecz może być wyrażona na wiele sposobów w specyfikacji l Brak modularności Struktury JN są nieadekwatne do struktury dokumentów opisujących wymagania

37 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 37 Alternatywy dla JN

38 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 38 Strukturalny język naturalny l Ograniczona postać języka naturalnego, przeznaczona do zapisywania wymagań systemowych l Usuwa niektóre z niejednoznaczności i elastyczności języka naturalnego zapewniając w pewnym stopniu jednolitość specyfikacji l Często wspierany przez szablony

39 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 39 Specyfikacje przy użyciu formularzy l Definicja funkcji lub wejścia l Opis danych wejściowych i źródła pochodzenia l Opis danych wyjściowych i ich celu l Określenie z jakich innych bytów się korzysta l Warunki wstępne i wyjściowe l Efekty uboczne

40 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 40 Specyfikacja wymagań z użyciem standardowego formularza 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 i położenie węzła pochodzą od użytkownika, a identyfikator projektu z bazy danych. 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. Brak.

41 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 41 Specyfikacje w PDL l Wymagania są określane przy użyciu języka opisu programów, który zawiera instrukcje zwiększające wyrazistość. l Do stosowania gdy: Funkcja jest ciągiem akcji, a kolejność wykonania tych akcji jest istotna Trzeba wyspecyfikować interfejsy programowe lub sprzętowe l Wady W PDL nie da się wyrazić wymagań dziedzinowych Specyfikacja jest traktowana jako projekt a nie jako specyfikacja

42 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 42 Część specyfikacji bankomatu

43 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 43 Wady PDL l PDL nie jest wystarczający do wyrażania wymagań w sposób zrozumiały l Notacja jest zrozumiała dla ludzi znających języki programowania l Wymagania są traktowane jako projekt, a nie jako model mający na celu zrozumienie systemu

44 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 44 Specyfikacja interfejsów l Większość systemów musi współpracować z innymi systemami a interfejsy między nimi są częścią specyfikacji l Można wyróżnić trzy typy interfejsów Proceduralne Wymieniane struktury danych Reprezentacje danych l Formalne notacje umożliwiają definiowanie interfejsów w sposób jednoznaczny

45 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 45 Opis interfejsu w PDL

46 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 46 Dokumentacja wymagań l Dokumentacja wymagań stawianych oprogramowaniu jest oficjalną deklaracją tego, co jest wymagane od wytwórców systemu l Powinien zawierać zarówno wymagania użytkownika jak i wymagania systemowe l Nie jest częścią projektu. Powinien mówić CO zrobić a nie JAK to zrobić.

47 Użytkownicy dokumentacji wymagań Klienci Menedżerowie Inżynierowie systemu Inżynierowie testów Inżynierowie pielęgnacji 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

48 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 48 Dokumentacja wymagań l Określa zachowanie systemu jedynie z zewnątrz l Określa ograniczenia implementacji l Łatwo ją modyfikować l Jest informatorem dla konserwatorów systemu l Obejmuje przewidywania przyszłego cyklu życia systemu l Charakteryzuje reakcje na niepożądane zdarzenia

49 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 49 Standard wymagań IEEE l Wstęp l Ogólny opis l Szczegółowe wymagania l Dodatki l Skorowidz l To jest ogólna struktura, która musi być dopasowana do konkretnych systemów

50 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 50 Struktura dokumentacji wymagań l Wstęp l Słownik l Wymagania użytkownika l Architektura systemu l Specyfikacja wymagań systemowych l Modele systemu l Ewolucja systemu l Dodatki l Skorowidz

51 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 51 Główne tezy l W wymaganiach stawianych systemowi określa się, co powinien system robić oraz definiuje ograniczenia l Wymagania funkcjonalne opisują usługi, których system ma dostarczać l Wymagania niefunkcjonalne opisują ograniczenia w jakich system ma działać l Wymagania użytkownika są stwierdzeniami wysokiego poziomu i opisują oczekiwania użytkowników

52 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 52 Główne tezy l Wymagania użytkownika zapisuje się w języku naturalnym z pomocą tabel i diagramów l Wymagania systemowe opisują wszystkie funkcje jakich system musi dostarczać l Wymagania systemowe można zapisywać za pomocą strukturalnego języka naturalnego, PDL lub innych języków stworzonych w tym celu l Dokumentacja wymagań stawianych oprogramowaniu jest uzgodnionym zapisem wymagań systemowych


Pobierz ppt "©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 1 Wymagania stawiane oprogramowaniu l Opis i specyfikacja systemu."

Podobne prezentacje


Reklamy Google