Wymagania stawiane oprogramowaniu Opis i specyfikacja systemu

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

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

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ć

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

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

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

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

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ę

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..

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.

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

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ń

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.

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.

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ń

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

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

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.

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

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?

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

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ą.

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

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

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

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

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

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.

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ę)

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.

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

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

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

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

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

Alternatywy dla JN

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

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

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.

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

Część specyfikacji bankomatu

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

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

Opis interfejsu w PDL

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ć.

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ń

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

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

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

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

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