Wymagania stawiane oprogramowaniu

Prezentacja na temat: "Wymagania stawiane oprogramowaniu"— Zapis prezentacji:

1 Wymagania stawiane oprogramowaniu
Opis i specyfikacja systemu

2 Cele Rozumienie pojęć wymagań użytkownika i wymagań systemowych
Rozumienie różnic pomiędzy wymaganiami funkcjonalnymi i niefunkcjonalnymi Poznanie dwóch metod zapisywania wymagań Wiedza, jak wymagania mogą być organizowane w dokumentacji

3 Zawartość Wymagania funkcjonalne i niefunkcjonalne
Wymagania użytkownika Wymagania systemowe Dokumentacja wymagań stawianych oprogramowaniu

4 Inżynieria wymagań 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 Wymagania to opisy usług, które system ma udostępniać i ograniczeń, które musi spełniać

5 Co to jest wymaganie Może być zarówno abstrakcyjnym wysokiego poziomu opisem usługi jak również precyzyjnym matematycznym opisem działania konkretnej funkcji 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 Typy wymagań Wymagania użytkownika Wymagania systemowe
Wyrażenia w języku naturalnym oraz diagramy o usługach oczekiwanych od systemu oraz o ograniczeniach. Pisane dla klienta Wymagania systemowe Precyzyjna dokumentacja opisująca szczegółowo wszystkie usługi systemu i ograniczenia. Część kontraktu pomiędzy klientem a dostawcą Specyfikacja projektu oprogramowania Abstrakcyjny opis projektu oprogramowania, który jest podstawą bardziej szczegółowego projektu i implementacji. Pisana dla programistów

7 Definicje i specyfikacje
Definicja wymagań użytkownika Oprogramowanie musi zapewnić mechanizmy reprezentowania i dostępu do plików zewnętrznych tworzonych przez inne narzędzia Specyfikacja wymagań systemowych Użytkownik powinien mieć możliwość definiowania typów plików zewnętrznych Każdy typ pliku zewnętrznego może mieć przypisane narzędzie do obróbki tego typu plików Każdy typ pliku zewnętrznego może być przedstawiony w postaci charakterystycznej ikony na ekranie użytkownika Należy zapewnić udogodnienia do definiowana przez użytkownika ikon odpowiadających typom plików zewnętrznych 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 Czytelnicy różnych wymagań
Menedżerowie klienta Użytkownicy systemu Inżynierowie klienta Menedżerowi zleceniodawcy Architekci systemu Wymagania użytkownika Użytkownicy systemu Inżynierowie klienta Architekci systemu Twórcy oprogramowania Wymagania systemowe Specyfikacja projektu oprogramowania Inżynierowie klienta (być może) Architekci systemu Twórcy oprogramowania

9 Wymagania funkcjonalne i niefunkcjonalne
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. Wymagania niefunkcjonalne Ograniczenia usług i funkcji systemu obejmujące: ograniczenia czasowe, ograniczenia dotyczące procesu tworzenia, standardy itd. Wymagania dziedzinowe Wymagania pochodzące z dziedziny zastosowania systemu i odzwierciedlające jego charakterystykę

10 Wymagania funkcjonalne
Opisują funkcjonalność lub usługi, które system powinien oferować Zależą od rodzaju tworzonego oprogramowania, spodziewanych użytkowników oprogramowania i rodzaju wytwarzanego systemu Wymagania użytkownika mają zazwyczaj postać ogólną, ,natomiast systemowe szczegółowo definiują funkcje systemu, wejścia wyjścia wyjątki itd..

11 Przykłady wymagań funkcjonalnych
Użytkownik będzie mógł przeszukać zbiór wszystkich danych lub wybrany podzbiór. System dostarczy narzędzi do przeglądania dokumentów ze magazynu dokumentów. 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 Nieprecyzyjność wymagań
Kiedy wymagania nie są precyzyjnie wyrażone powstają problemy Nieprecyzyjne wymagania są różnie interpretowane przez użytkowników i programistów Rozważ użycie ‘odpowiedniego rzecznika’ Intencje użytkownika Interpretacja programisty

13 Spójność i pełność wymagań
W założeniach wymagania powinny być spójne i pełne Pełność Powinny opisywać wszystkie wymagane oczekiwania Pełne Nie powinno być sprzeczności pomiędzy opisywanymi oczekiwaniami W praktyce nie można stworzyć spójnego i pełnego opisu wymagań

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

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

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

17 Przykłady wymagań niefunkcjonalnych
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 Wymagania organizacyjne Proces tworzenia systemu i końcowe dokumenty powinny być zgodne z procesem i produktami zdefiniowanymi w XYZCo-SP-STAN-95 Wymagania zewnętrzne System nie powinien ujawniać operatorom żadnych danych osobowych klientów oprócz nazwisk i numerów identyfikacyjnych

18 Cele i wymagania Wymagania niefunkcjonalne mogą być trudne do precyzyjnego zapisania a nieprecyzyjne wymagania mogą być trudne do zweryfikowania Cel Generalna intencja aby system coś spełniał Weryfikowalne wymaganie niefunkcjonalne Stwierdzenie używające jakiejś miary, która może być obiektywne zmierzona Cele mogą być przydatne dla programistów, gdyż przekazują wskazówki o priorytetach klienta

19 Przykłady Cel Weryfikowalne wymaganie niefunkcjonalne
System powinien być łatwy w użyciu dla doświadczonych kontrolerów, a sposób 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.

20 Miary wymagań Właściwość Miara Szybkość Liczba transakcji na sek.
Czas reakcji na zdarzenie Czas odświeżania ekranu Rozmiar Kilobajty Liczba układów pamięci RAM Łatwość użycia Czas 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 Zależności między wymaganiami
W dużych systemach często występują konflikty pomiędzy wymaganiami funkcjonalnymi i niefunkcjonalnymi 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 Wymagania dziedzinowe
Wynikają bardziej z dziedziny zastosowania systemu niż z konkretnych potrzeb użytkowników Mogą być nowymi wymaganiami funkcjonalnymi, ograniczać istniejące albo ustalać sposób wykonania konkretnych obliczeń Jeśli będą niespełnione system może być bezużyteczny

23 Wymagania dziedzinowe systemu bibliotecznego
Wszystkie bazy danych powinny być dostępne przez standardowy interfejs zgodny ze standardem Z39.50. 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 System bezpieczeństwa ruchu kolei
Tempo hamowania pociągu powinno być obliczone jako: Dtrain = Dcontrol + Dgradient gdzie Dgradient to 9.81ms2 * wyrównane nachylenie/alfa a wartości 9.81ms2 /alfa są różne dla różnych typów pociągów

25 Problemy z wymaganiami dziedzinowymi
Zrozumienie Wymagania są wyrażone w języku typowym dla dziedziny To często nie jest zrozumiałe dla programistów tworzących system 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 Wymagania użytkownika
Powinny opisywać funkcjonalne i niefunkcjonalne wymagania tak, aby były zrozumiałe dla użytkowników systemu nie posiadających wiedzy technicznej Należy je zapisywać w języku naturalnym używając formularzy i intuicyjnych diagramów

27 Problemy z językiem naturalnym
Brak jasności Trudno uzyskać precyzję bez czynienia dokumentów nieczytelnymi i gadatliwymi Sprzeczność wymagań Wymagania funkcjonalne i niefunkcjonalne łatwo się mieszają Łączenie wymagań Kilka wymagań może być wyrażonych wspólnie

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 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 Problemy z wymaganiami
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 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 Dobra struktura 2.6 Siatka
2.6.1 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 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: Użytkownik powinien wybrać typ węzła, jaki należy dodać Użytkownik powinien przesunąć wskaźnik do przybliżonego miejsca nowego węzła na diagramie i zlecić dodanie symbolu w tym punkcie 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 Rady dla piszących wymagania
Opracuj standard i używaj go dla wszystkich wymagań Konsekwentnie używaj języka. Używaj „będzie” dla wymagań obowiązkowych a „powinien” dla oczekiwanych. Stosuj wyróżnienia do zaznaczania głównych części wymagania Unikaj żargonu komputerowego

34 Wymagania systemowe Dokładniejsze wyrażenie wymagań użytkownika
Służą jako podstawa do zaprojektowania systemu Mogą być użyte jako część kontraktu Można je przedstawiać za pomocą modeli

35 Wymagania i projekt Teoretycznie, wymagania powinny mówić co system powinien robić a projekt jak system powinien to robić 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 Problemy ze specyfikacją w JN
Niejednoznaczność Czytający i piszący mogą rozumieć inne pojęcia pod postacią tych samych słów. Elastyczność Ta sama rzecz może być wyrażona na wiele sposobów w specyfikacji Brak modularności Struktury JN są nieadekwatne do struktury dokumentów opisujących wymagania

37 Alternatywy dla JN

38 Strukturalny język naturalny
Ograniczona postać języka naturalnego, przeznaczona do zapisywania wymagań systemowych Usuwa niektóre z niejednoznaczności i elastyczności języka naturalnego zapewniając w pewnym stopniu jednolitość specyfikacji Często wspierany przez szablony

39 Specyfikacje przy użyciu formularzy
Definicja funkcji lub wejścia Opis danych wejściowych i źródła pochodzenia Opis danych wyjściowych i ich celu Określenie z jakich innych bytów się korzysta Warunki wstępne i wyjściowe Efekty uboczne

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 Specyfikacje w PDL Wymagania są określane przy użyciu języka opisu programów, który zawiera instrukcje zwiększające wyrazistość. Do stosowania gdy: Funkcja jest ciągiem akcji, a kolejność wykonania tych akcji jest istotna Trzeba wyspecyfikować interfejsy programowe lub sprzętowe Wady W PDL nie da się wyrazić wymagań dziedzinowych Specyfikacja jest traktowana jako projekt a nie jako specyfikacja

42 Część specyfikacji bankomatu

43 Wady PDL PDL nie jest wystarczający do wyrażania wymagań w sposób zrozumiały Notacja jest zrozumiała dla ludzi znających języki programowania Wymagania są traktowane jako projekt, a nie jako model mający na celu zrozumienie systemu

44 Specyfikacja interfejsów
Większość systemów musi współpracować z innymi systemami a interfejsy między nimi są częścią specyfikacji Można wyróżnić trzy typy interfejsów Proceduralne Wymieniane struktury danych Reprezentacje danych Formalne notacje umożliwiają definiowanie interfejsów w sposób jednoznaczny

45 Opis interfejsu w PDL

46 Dokumentacja wymagań Dokumentacja wymagań stawianych oprogramowaniu jest oficjalną deklaracją tego, co jest wymagane od wytwórców systemu Powinien zawierać zarówno wymagania użytkownika jak i wymagania systemowe Nie jest częścią projektu. Powinien mówić CO zrobić a nie JAK to zrobić.

47 Użytkownicy dokumentacji wymagań
Klienci Określają wymagania i czytają je, aby sprawdzić, czy odpowiadają ich potrzebom. Określają także zmiany wymagań Menedżerowie Używają dokumentacji wymagań do planowania oferty budowy systemu i do planowania procesu jego tworzenia Inżynierowie systemu Używają wymagań, aby zrozumieć, jaki system ma być zbudowany Inżynierowie testów Używają wymagań, aby opracować testy zatwierdzające system Inżynierowie pielęgnacji Używają wymagań jako pomocy w zrozumieniu systemu i związków między jego częściami Użytkownicy dokumentacji wymagań

48 Dokumentacja wymagań Określa zachowanie systemu jedynie z zewnątrz
Określa ograniczenia implementacji Łatwo ją modyfikować Jest informatorem dla konserwatorów systemu Obejmuje przewidywania przyszłego cyklu życia systemu Charakteryzuje reakcje na niepożądane zdarzenia

49 Standard wymagań IEEE Wstęp Ogólny opis Szczegółowe wymagania Dodatki
Skorowidz To jest ogólna struktura, która musi być dopasowana do konkretnych systemów

50 Struktura dokumentacji wymagań
Wstęp Słownik Wymagania użytkownika Architektura systemu Specyfikacja wymagań systemowych Modele systemu Ewolucja systemu Dodatki Skorowidz

51 Główne tezy W wymaganiach stawianych systemowi określa się, co powinien system robić oraz definiuje ograniczenia Wymagania funkcjonalne opisują usługi, których system ma dostarczać Wymagania niefunkcjonalne opisują ograniczenia w jakich system ma działać Wymagania użytkownika są stwierdzeniami wysokiego poziomu i opisują oczekiwania użytkowników

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