Inżynieria oprogramowania wykład IV Faza określenia wymagań

Transkrypt

1 Inżynieria oprogramowania wykład IV Faza określenia wymagań prowadzący: dr inż. Krzysztof Bartecki

2 Faza określenia wymagań Wymagania Projektowanie Implementacja Testowanie Konserwacja Strategiczna Analiza Instalacja Dokumentacja Jej celem jest dokładne określenie wymagań klienta wobec tworzonego systemu. K. Bartecki, Inżynieria oprogramowania, IV/2

3 Faza określenia wymagań szczegóły W tej fazie dokonywana jest zamiana celów klienta na konkretne wymagania zapewniające osiągnięcie tych celów. Klient może nie rozumieć oprogramowania, ale wie czego chce. Zadaniem analizy wymagań jest określenie czego chce klient i opisanie tego w taki sposób, aby wytwarzanie mogło toczyć się dalej bez jego udziału. Podstawowym sposobem pracy jest wykonywanie wywiadów z różnymi osobami ze strony klienta są to z reguły przyszli użytkownicy systemu. K. Bartecki, Inżynieria oprogramowania, IV/3

4 Trudności w określeniu wymagań: klient nie wie, w jaki sposób osiągnąć założone cele, cele klienta można osiągnąć na wiele sposobów, duże systemy wykorzystywane są przez wielu użytkowników, których cele mogą być sprzeczne, zleceniodawcy i użytkownicy to inne osoby nie zawsze są oni w stanie właściwie przewidzieć potrzeby rzeczywistych użytkowników. Jeśli klient, dla którego jest przeznaczone oprogramowanie, nie zostanie wysłuchany i zrozumiany, to prawdopodobnie nie będzie zadowolony z wyniku. K. Bartecki, Inżynieria oprogramowania, IV/4

5 Kolejne poziomy opisu wymagań Definicja wymagań (ang. requirement definition) to ogólny opis sporządzony w języku naturalnym ( System powinien ), będący rezultatem wstępnych rozmów z klientem. Specyfikacja wymagań (ang. requirement specification) to zapis częściowo już ustrukturalizowany, wykorzystujący zarówno język naturalny, jak i proste sformalizowane notacje (tabele, formularze). Specyfikacja oprogramowania (ang. software specification) to w pełni formalny opis wymagań. Formalna specyfikacja oznacza dokładne zdekomponowanie wymagań (najlepiej w pewnym formularzu) na krótkie punkty, których interpretacja nie powinna nastręczać trudności lub prowadzić do niejednoznaczności. K. Bartecki, Inżynieria oprogramowania, IV/5

6 Zawartość typowego dokumentu z opisem wymagań: wprowadzenie cel, zakres i kontekst systemu (omówione na poprzednim wykładzie), opis wymagań funkcjonalnych, opis wymagań niefunkcjonalnych, opis ewolucji systemu przewidywanych zmian, które mogą nastąpić w wyniku ewolucji sprzętu, zmiany potrzeb użytkowników, itp., wstępny model analityczny systemu (modelowanie będzie omówione na kolejnych wykładach), słownik opis terminów niezrozumiałych dla każdej ze stron. K. Bartecki, Inżynieria oprogramowania, IV/6

7 Cechy dobrego opisu wymagań: jest kompletny oraz niesprzeczny, opisuje zewnętrzne zachowanie systemu z punktu widzenia użytkownika, a nie sposób jego realizacji, uwzględnia ograniczenia, przy jakich musi pracować system, jest łatwy w modyfikacji, opisuje zachowanie systemu również w sytuacjach niepożądanych. Najbardziej typowy błąd w tej fazie: koncentrowanie się na sytuacjach typowych i pomijanie wyjątków oraz przypadków granicznych. Zarówno użytkownicy, jak i analitycy mają tendencję do nie zauważania sytuacji nietypowych lub skrajnych. K. Bartecki, Inżynieria oprogramowania, IV/7

8 Podział wymagań systemowych funkcjonalne opisują funkcje (czynności), które system ma wykonywać niefunkcjonalne opisują ograniczenia, przy których system ma wykonywać swoje funkcje K. Bartecki, Inżynieria oprogramowania, IV/8

9 Wymagania funkcjonalne Określenie wymagań funkcjonalnych obejmuje następujące czynności: określenie wszystkich rodzajów użytkowników, którzy będą korzystać z systemu, określenie wszystkich rodzajów użytkowników, którzy są niezbędni do działania systemu (obsługa, wprowadzanie danych, administracja), dla każdego rodzaju użytkownika określenie funkcji systemu oraz sposobów korzystania z planowanego systemu, określenie systemów zewnętrznych (obcych baz danych, sieci, Internetu), które będą wykorzystywane podczas działania systemu, ustalenie struktur organizacyjnych, przepisów prawnych, statutów, zarządzeń, instrukcji, itd., które pośrednio lub bezpośrednio określają funkcje wykonywane przez planowany system. K. Bartecki, Inżynieria oprogramowania, IV/9

10 Fragment przykładowego opisu wymagań w języku naturalnym System powinien umożliwiać wprowadzanie przechowywanie i drukowanie wielu wzorców tekstów umów zlecenia i umów o dzieło (łącznie co najmniej kilkunastu). Druk polegałby na wybraniu jednego ze wzorców i jednego z zleceniobiorców. System powinien uzupełnić wzorzec o dane zleceniobiorcy i umożliwiać dodanie tekstu przez użytkownika. System powinien umożliwiać drukowanie rachunków za wykonanie umowy zlecenie i umowy o dzieło z wyliczonymi poprawnie wszystkimi jego elementami. System powinien uwzględniać wszystkie zgodne z przepisami warianty naliczaniu ubezpieczeń społecznych i podatków K. Bartecki, Inżynieria oprogramowania, IV/10

11 Zalety opisu wymagań w języku naturalnym: stosunkowo łatwy do sporządzenia, w pełni zrozumiały przez klienta. Wady opisu wymagań w języku naturalnym: niejednoznaczność utrudniająca precyzyjny zapis wymagań może prowadzić to do różnej interpretacji tego samego tekstu przez różne osoby, ta sama treść wyrażona może być na różne sposoby utrudnia to wykrycie wymagań powiązanych z sobą oraz wymagań sprzecznych. K. Bartecki, Inżynieria oprogramowania, IV/11

12 Przykład formularza opisu wymagania dla programu podatkowego Nazwa funkcji Edycja dochodów podatnika Opis Dane wejściowe Źródło danych wejściowych Wynik Warunek wstępny Warunek końcowy Funkcja pozwala edytować łączne dochody podatnika uzyskane w danym roku Informacje o dochodach podatnika uzyskanych z różnych źródeł, o zaliczkach na poczet podatku, o dokumentach opisujących dochody Dokumenty oraz informacje dostarczane przez podatnika. Dane wpisywane są przez pracownika firmy Łączne dochody uzyskane przez podatnika w danym roku kalendarzowym Kwota dochodu = kwota przychodu kwota kosztów. Łączne kwoty przychodów, kosztów uzyskania, dochodów oraz zaliczek są sumami tych kwot dla dochodów z poszczególnych źródeł. Kwota dochodu = kwota przychodu kwota kosztów. Łączne kwoty przychodów, kosztów uzyskania, dochodów oraz zaliczek są sumami tych kwot dla dochodów z poszczególnych źródeł. K. Bartecki, Inżynieria oprogramowania, IV/12

13 Porządkowanie wymagań hierarchia wymagań funkcjonalnych funkcja 1 funkcja 1 funkcja 1.1 funkcja 1.1 funkcja 1.2 funkcja 1.3 funkcja 1.2 funkcja funkcja funkcja funkcja funkcja funkcja funkcja 1.3 K. Bartecki, Inżynieria oprogramowania, IV/13

14 Przykład hierarchii funkcji dla systemu firmy rachunkowej 1. Ewidencja podatników : 4. Ewidencja Urzędów Skarbowych : 6. Ewidencja zeznań podatkowych 6.1. Dodawanie zeznania 6.2. Usuwanie zeznania 6.3. Zabezpieczenie zeznania 6.4. Edycja zeznania Edycja informacji o przychodach Edycja informacji o ulgach : Wyświetlanie rozliczenia K. Bartecki, Inżynieria oprogramowania, IV/14

15 Przykład hierarchii funkcji dla systemu harmonogramowania zleceń System harmonogramowania zleceń 2. Przygotowanie zamówień na półprodukty 4. Przygotowanie kart zadań 1. Ewidencja zleceń 3. Edycja technologicznego opisu wydziału 5. Harmonogramowanie zleceń 1.1. Edycja opisu maszyn 1.2. Edycja opisu operacji 1.3. Edycja opisu wyrobów 1.4. Sprawdzanie kompletności opisu 1.5. Wydruk informacji technologicznych 3.1. Ustalanie harmonogramu 3.2. Edycja harmonogramu 3.3. Graficzna prezentacja harmonogramu 3.4. Wydruk harmonogramu 5.1. Wczytywanie informacji o zleceniach 5.2. Wyświetlanie informacji o zleceniach 5.3. Wydruk informacji o zleceniach K. Bartecki, Inżynieria oprogramowania, IV/15

16 Przypadki użycia są jedną z metod specyfikacji wymagań i dotyczą opisu funkcji systemu z punktu widzenia jego użytkowników. Przypadek użycia (ang. use case) to opis sekwencji działań, mającej określony cel biznesowy, w trakcie którego realizacji zachodzi interakcja pomiędzy programem i jego użytkownikami. Przypadki użycia, w przeciwieństwie do wcześniej wymienionych metod, skupiają się na interakcji pomiędzy użytkownikiem a systemem. Metoda przypadków użycia nie jest sprzeczna z hierarchiczną dekompozycją funkcji mogą być one stosowane równolegle. K. Bartecki, Inżynieria oprogramowania, IV/16

17 Zasady stosowania przypadków użycia: istotność nie koncentrujemy opisów przypadków użycia na działaniach mniej istotnych, nie mających ważnego celu biznesowego, kompletność opisane przypadki użycia powinny pokrywać wszystkie działania użytkownika, skala nie mnożymy nadmiernie ilości przypadków użycia, opisując oddzielnie jednostkowe czynności które powinny być krokami w przypadkach użycia, niezależność jeżeli jeden przypadek użycia zawiera przypadki podrzędne lub jest z nich zbudowany, to należy je wydzielić dla uproszczenia opisu. K. Bartecki, Inżynieria oprogramowania, IV/17

18 Opis (scenariusz) przykładowego przypadku użycia UC1: Wystawianie faktury Aktor: Sprzedawca Główny scenariusz: 1. Sprzedawca chce wystawić fakturę 2. Sprzedawca wpisuje pozycję faktury 3. System podlicza fakturę, nadaje jej nowy numer i zapisuje w rejestrze 4. Sprzedawca drukuje fakturę Rozszerzenia: 3.A Sprzedawca nie dodał żadnej pozycji 3.A.1 System prosi o ponowne wprowadzenie pozycji K. Bartecki, Inżynieria oprogramowania, IV/18

19 Inny przykład scenariusza przypadku użycia (źródło: owymaganiach.pl) K. Bartecki, Inżynieria oprogramowania, IV/19

20 Graficzna notacja przypadku użycia wystawianie faktury sprzedawca aktor (rodzaj użytkownika) asocjacja przypadek użycia K. Bartecki, Inżynieria oprogramowania, IV/20

21 Przykładowy diagram przypadków użycia restauracja K. Bartecki, Inżynieria oprogramowania, IV/21

22 Przykładowy diagram przypadków użycia biblioteka K. Bartecki, Inżynieria oprogramowania, IV/22

23 Uwaga: Sam diagram przypadków użycia nie umożliwia pełnej specyfikacji wymagań funkcjonalnych. Do każdego przypadku użycia na znajdującego się na diagramie potrzebny jest opis w postaci odpowiedniego scenariusza. Dopiero diagram przypadków użycia wraz ze zbiorem scenariuszy może być traktowany jako pełna specyfikacja funkcjonalności systemu. K. Bartecki, Inżynieria oprogramowania, IV/23

24 Wymagania niefunkcjonalne opisują ograniczenia, przy których system musi realizować swoje funkcje. Wymagania niefunkcjonalne można podzielić na: dotyczące produktu, np. w przypadku braku myszy musi istnieć możliwość przeglądania danych wyłącznie za pomocą klawiatury, dotyczące procesu, np. proces realizacji systemu harmonogramowania zleceń musi być zgodny ze standardem opisanym w określonym dokumencie. zewnętrzne, np. projektowany system informatyczny musi współpracować z bazą danych systemu komputerowego opisanego w określonym dokumencie. K. Bartecki, Inżynieria oprogramowania, IV/24

25 Typowe wymagania niefunkcjonalne związane są z m.in. bezpieczeństwem, wydajnością, awaryjnością systemu. UWAGA: Wymagania stwierdzające na przykład że system powinien być: łatwy w obsłudze, niezawodny, wydajny, nie są poprawnie określone, gdyż nie mogą być obiektywnie zweryfikowane. Dla wyrażania tego typu wymagań konieczne jest posługiwanie się wielkościami mierzalnymi. K. Bartecki, Inżynieria oprogramowania, IV/25

26 Przykłady miar służących do określenia wymagań niefunkcjonalnych cecha miary wydajność rozmiar łatwość użytkowania niezawodność odporność przenośność liczba transakcji obsłużonych w ciągu sekundy, czas odpowiedzi, szybkość odświeżania ekranu wymagana pamięć RAM, wymagana pamięć dyskowa czas niezbędny dla przeszkolenia użytkowników, liczba stron dokumentacji częstotliwość występowania błędnych wykonań, dostępność (procent czasu, w którym system jest dostępny) czas restartu po awarii systemu, prawdopodobieństwo zniszczenia danych podczas awarii liczba platform docelowych, Koszt przeniesienia na nową platformę K. Bartecki, Inżynieria oprogramowania, IV/26

27 Słownik Opis wymagań może zawierać terminy niezrozumiałe dla jednej ze stron. Mogą to być: terminy informatyczne (niezrozumiałe dla klienta), terminy dotyczące dziedziny zastosowań (niezrozumiałe dla projektantów systemu). Wszystkie specyficzne terminy niezrozumiałe dla jednej ze stron powinny być umieszczone w słowniku, wraz z ich wyjaśnieniem. Słownik powinien precyzować terminy niejednoznaczne i określać ich znaczenie w kontekście tego dokumentu. K. Bartecki, Inżynieria oprogramowania, IV/27

28 Przykład notacji elementów słownika termin objaśnienie synonim (nie zalecany) konto Nazwana ograniczona przestrzeń dyskowa, gdzie użytkownik może przechowywać swoje dane. Konta są powiązane z określonymi usługami, np. z pocztą komputerową oraz z prawami dostępu. katalog użytkownika konto bankowe Sekwencja cyfr oddzielona myślnikami, identyfikująca stan zasobów finansowych oraz operacji dla pojedynczego klienta banku. konto klient Jednostka sprzętowa instalowana w biurach urzędu, poprzez którą następuje interakcja użytkownika końco wego z systemem. stacja robocza użytkownik Osoba używająca systemu dla własnych celów biznesowych niezwiązanych z obsługą lub administracją systemu. klient K. Bartecki, Inżynieria oprogramowania, IV/28

29 Rezultaty fazy określenia wymagań Dokument opisujący wymagania, złożony z następujących elementów: wprowadzenia opisującego cele, zakres i kontekst systemu, opisu wymagań funkcjonalnych, opisu wymagań niefunkcjonalnych, opisu ewolucji systemu, tzn. przewidywanych zmian wymagań, wstępnego modelu systemu, słownika danych. Plan testów systemu. K. Bartecki, Inżynieria oprogramowania, IV/29