Wymagania stawiane oprogramowaniu

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 • 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 • 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. • 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 • 9.3.2 Proces tworzenia systemu i końcowe dokumenty powinny być zgodne z procesem i produktami zdefiniowanymi w XYZCo-SP-STAN-95 • Wymagania zewnętrzne • 7.6.5 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 • 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. 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 Miary wymagań

21. Zależności międzywymaganiami • 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.5Baza 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. Przezopcję 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 • 3.5.1. Dodawanie węzłów do projektu • 3.5.1.1. Edytor będzie udostępniał użytkownikom udogodnienia do dodawania do swoich projektów węzłów określonego typu. • 3.5.1.2. 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

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