Pobierz prezentację
Pobieranie prezentacji. Proszę czekać
1
Określanie wymagań Inżynieria wymagań
Dr inż. Marek Miłosz Wykład 3
2
Plan Istota fazy określania wymagań Problemy inżynierii wymagań
Metody rozpoznania wymagań Wymagania funkcjonalne i nie- Dokument: Specyfikacja wymagań Formalne metody definiowania wymagań © M.Miłosz
3
Istota fazy określania wymagań
Cel: ustalenie wymagań klienta wobec tworzonego SI Zamiana celów klienta na konkretne wymagania zapewniające osiągnięcie tych celów Proces wspólnej pracy: analityk systemowy + klient + eksperci dziedzinowi Konieczność dużego zaangażowania klienta Weryfikacja wymagań © M.Miłosz
4
Czynniki uwzględniane przy definiowaniu wymagań (1)
Możliwości systemu (zestaw funkcji systemu z pozycji użytkownika) Wielkość systemu (liczba użytkowników, objętość baz danych) Szybkość działania (czas realizacji operacji, natężenie operacji) Dokładność (liczba miejsc znaczących) Ograniczenia (zakres zmienności) © M.Miłosz Wg Software Engineering Guides
5
Czynniki uwzględniane przy definiowaniu wymagań (2)
Interfejsy komunikacyjne (sieć, protokoły) Interfejsy sprzętowe (sprzęt, wymagania środowiska pracy) Interfejsy oprogramowania (kompatybilność) Interakcja człowiek-maszyna (interfejs użytkownika, sprzęt, język, komunikaty) © M.Miłosz
6
Czynniki uwzględniane przy definiowaniu wymagań (3)
Adaptowalność (zmiana) Bezpieczeństwo (poufność, prywatność, odporność) Odporność na awarie Standardy Zasoby (finansowe, ludzkie) Skala czasowa (ograniczenia czasu wykonania) © M.Miłosz
7
Problemy inżynierii wymagań
Klient nie potrafi zdefiniować celów i wymagań Cele klienta mogą być osiągnięte na wiele sposobów Wielu użytkowników - wiele celów, sprzeczność, różnorodność terminologii Zleceniodawcy a użytkownicy - przewidywalność potrzeb, sprzeczność interesów Niejednoznaczność języka © M.Miłosz
8
Poziomy opisu wymagań Definicja wymagań - opis ogólny w języku naturalnym Specyfikacja wymagań - częściowo ustrukturalizowany zapis wykorzystujący zarówno język naturalny, jak i proste, sformalizowane notacje (tablice, diagramy) Specyfikacja oprogramowania - w pełni formalny opis wymagań © M.Miłosz
9
Formalizacja Formalny <> matematyczny
Formalny = dokładny, jednoznaczny, nie stwarzający okazji do różnej interpretacji Notacje: schematy, formularze Podstawa do testowania akceptacyjnego SI © M.Miłosz
10
Jakość opisu wymagań Kompletność i niesprzeczność (spójność)
Jednoznaczność, dokładność Realistyczność, osiągalność Wyraźna specyfikacja ograniczeń Opis zewnętrznych zachowań SI Możliwość modyfikacji i zmian Opis zachowania się SI i rozwiązywania problemów w sytuacjach wyjątkowych © M.Miłosz
11
Metody rozpoznania wymagań
Wywiady i przeglądy procesów oraz zdarzeń (MBP - jeśli było przeprowadzone) Analiza istniejącego oprogramowania Analiza wymagań innych SI Studium wykonalności Prototypowanie © M.Miłosz
12
Typy wymagań Funkcjonalne - czynności/operacje które SI musi wykonywać w reakcji na zdarzenia zewnętrzne (obiekty oddziaływujące na SI lub wykorzystujące rezultaty jego pracy) Niefunkcjonalne - ograniczenia i dodatkowe uwarunkowania - inne struktury SI (np. struktura techniczna, typ interfejsu, współpraca z BD, wydajność, odporność na awarię, przenośność, łatwość użytkowania) © M.Miłosz
13
Dokument: Specyfikacja wymagań
Wprowadzenie (cel, zakres i kontekst systemu, częściowe wyniki fazy strategicznej) Opis ewolucji systemu (zakres wprowadzanych zmian) Opis wymagań funkcjonalnych Opis wymagań niefunkcjonalnych Model funkcjonalny SI Wymagania przedsięwzięcia (czas, zasoby) Słownik terminów (informatycznych i specyficznych) © M.Miłosz
14
Model funkcjonalny - idea
Klient SI Zapytanie Faktura Klient Rachunek Funkcje Bank OBIEKTY ZEWNĘTRZNE ZDARZENIA - WE Żądanie zapłaty REZULTATY - ZDARZENIA WY Wykaz Kierownik Zestawienie Dyrektywy Kierownik © M.Miłosz
15
Model funkcjonalny SI - struktura
Identyfikacja zdarzeń, na które ma reagować SI Identyfikacja obiektów zewnętrznych generujących zdarzenia (osoby, systemy,...) Diagram kontekstowy SI (Context diagram) Hierarchiczny model funkcji SI © M.Miłosz
16
Wykaz zdarzeń Event list
Zdarzenie - pojawienie się danych na granicy systemu (do i z systemu) Typy zdarzeń: wymuszone z zewnątrz (obiekty) lub wewnętrzne (związane z upływem czasu) sterowanie (w tym systemowe) Identyfikacja zdarzeń z punktu widzenia otoczenia systemu Identyfikacja wyjątków i zdarzeń niepożądanych © M.Miłosz
17
Obiekty zewnętrzne Obiekty (lub ich grupy), które dostarczają informacji do SI lub też wykorzystują informację tworzoną w rezultacie pracy SI - generują zdarzenia zewnętrzne Problem: obiekt vs. użytkownik końcowy vs. użytkownik bezpośredni SI Definiowanie granic system-otoczenie © M.Miłosz
18
Diagram kontekstowy Context diagram
© M.Miłosz wg. metodyki SSADM - Structured System Analysis and Design Method
19
Hierarchiczny model funkcji - techniki przedstawienia (1)
Lista hierarchii 1. Funkcja 1 1.1. Funkcja 1.1 1.2. Funkcja 1.2 1.3. Funkcja 1.3 2. Funkcja 2 3. Funkcja 3 3.1. Funkcja 3.1 3.2. Funkcja 3.2 Układ pionowy © M.Miłosz
20
Hierarchiczny model funkcji - techniki przedstawienia (2)
Układ poziomy Wyróżnienia graficzne: - kluczowa funkcja - inne (pominięte) - nierozwinięte poziomy - elementarne Układ hybrydowy (zalecany) © M.Miłosz
21
Model funkcji - zasady Funkcja = działanie (czasownik)
Zwięzłość, jednoznaczność opisu, numerowanie funkcji Na każdym poziomie ten sam poziom szczegółowości Kompletność dekompozycji Kolejność funkcji nie ma znaczenia Funkcje z pozycji użytkownika Podejście top-down © M.Miłosz
22
Dekompozycja Top-down
funkcja f1 funkcja f1.4.3 funkcja f1.4.2 funkcja f1.4.1 funkcja f1.4 funkcja f1.3.2 funkcja f1.3.3 funkcja f1.3 funkcja f1.1 funkcja f1.2 funkcja f1.3.1 funkcja f1 funkcja f1.1 funkcja f1 funkcja f1.2 funkcja f1.3 funkcja f1.4 © M.Miłosz
23
Formularz opisu funkcji
© M.Miłosz
24
Wymagania niefunkcjonalne
Dodatkowe uwarunkowania i ograniczenia Wynikają z wymagań użytkownika Weryfikowalność wymagań: liczebniki a nie przymiotniki uzasadnienie (koszt) © M.Miłosz
25
Podsumowanie Określanie wymagań jest początkiem budowy SI a jednocześnie przygotowaniem do testowania Należy zadbać o dokładność i jednoznaczność określeń Formalizacja i podejście metodyczne jest gwarancją sukcesu Błąd w specyfikacji popełnia się łatwo a jego usunięcie kosztuje bardzo dużo © M.Miłosz
26
Wypożyczalnia rowerów „Szybki Bill”
Przykład Wypożyczalnia rowerów „Szybki Bill”
27
SI SzyB („Szybki Bill”) Wywiad z właścicielem
Właściciel wypożyczalni rowerów „Szybki Bill” potrzebuje system informatyczny, który zautomatyzuje mu obszar ewidencji wypożyczeń rowerów z przygotowaniem danych do posiadanego programu F-K oraz gospodarkę rowerami. Każde wypożyczenie powinno być odnotowywane w systemie w sposób umożliwiające naliczenie opłat, jak też i dokładną identyfikację osoby wypożyczającej. Wypożyczalnia ma sporo stałych klientów. Prowadzi dla nich system rezerwacji rowerów. Rowery niekiedy się psują i wymagają napraw w warsztacie remontowym. © M.Miłosz
28
SI SzyB Specyfikacja - Wprowadzenie
Cel: automatyzacja obsługi procesów ewidencji rowerów, rezerwacji, wypożyczeń, naliczania opłat Zakres: gospodarka rowerami (ewidencja, remonty, złomowanie) ewidencja klientów i wypożyczeń rozliczanie wypożyczeń rezerwowanie rowerów (przyjęcie rezerwacji, rezygnacja) cennik zestawienia wynikowe Kontekst systemu: SI SzyB ma współpracować z istniejącym systemem F-K na istniejącym sprzęcie © M.Miłosz
29
SI SzyB Wymagania niefunkcjonalne
SI SzyB ma być zaimplementowany przy pomocy MS Access 2000 na komputerze z MS Windows 2000 Do szybkiej identyfikacji rowerów mają być użyte naklejki i czytniki kodu kreskowego Musi istnieć możliwość obsługi przy pomocy: myszy, klawiatury i/lub ekranu dotykowego Wymiana z F-K ma się odbywać przy pomocy pliku tekstowego w formacie opisanym w dokumentacji systemu F-K System ma mieć możliwość obsługi w języku polskim i angielskim z przełączaniem „w locie” © M.Miłosz
30
SI SzyB Identyfikacja zdarzeń i obiektów
© M.Miłosz
31
SI SzyB Diagram kontekstowy
Policja Warsztat Dostawca Zgłoszenie kradzieży Rezygnacja Zlecenie naprawy Dane roweru Rezerwacja SzyB F-K Klient Dane klienta Dane o opłacie Oferta Raporty Cennik Dane o zwrocie (braku) Typ roweru Dane o wypożyczeniu Status roweru Właściciel Pracownik © M.Miłosz
32
SI SzyB Model funkcji © M.Miłosz
33
Opis funkcji 2.1 © M.Miłosz
34
SI SzyB Model funkcji (alternatywny)
© M.Miłosz
Podobne prezentacje
© 2024 SlidePlayer.pl Inc.
All rights reserved.