Określanie wymagań. Cele przedsięwzięcia. Kontekst przedsięwzięcia. Rodzaje wymagań. Diagramy przypadków użycia use case diagrams



Podobne dokumenty
Cele przedsięwzięcia

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

Specyfikacja klas. Opis Lista pól Lista metod Ograniczenia. Szacowana lub dokładna liczba obiektów tej klasy Trwałość

Modelowanie przypadków użycia. Jarosław Kuchta Projektowanie Aplikacji Internetowych

Faza Określania Wymagań

Modelowanie i analiza systemów informatycznych Spis treści

IO - inżynieria oprogramowania. dr inż. M. Żabińska, zabinska@agh.edu.pl

Instrukcja 3 Laboratoria 3, 4 Specyfikacja wymagań funkcjonalnych za pomocą diagramu przypadków użycia

Instrukcja 3 Laboratoria 3, 4 Specyfikacja wymagań funkcjonalnych za pomocą diagramu przypadków użycia

KATEDRA INFORMATYKI STOSOWANEJ PŁ INŻYNIERIA OPROGRAMOWANIA

CRM VISION FUNKCJE SYSTEMU

Analiza/Inżynieria wymagań

FAZA STRATEGICZNA. Podstawowe hasło: Nie skupiać się na szczegółach! (na razie) Czynności w fazie strategicznej: Decyzje strategiczne:

Instrukcja 3 Laboratoria 3, 4 Specyfikacja wymagań funkcjonalnych za pomocą diagramu przypadków użycia

Projektowanie systemów informatycznych. Diagramy przypadków użycia

RFP. Wymagania dla projektu. sklepu internetowego B2C dla firmy Oplot

Opis programu:

Analiza i projektowanie oprogramowania. Analiza i projektowanie oprogramowania 1/32

SPECYFIKACJA WYMAGAŃ

Inżynieria oprogramowania. Wykład 7 Inżynieria wymagań: punkty widzenia, scenariusze, przypadki użycia

Projekt dotyczy stworzenia zintegrowanego, modularnego systemu informatycznego wspomagającego zarządzanie pracownikami i projektami w firmie

System Obsługi Gości InteliPASS. Prezentacja systemu i korzyści z wdrożenia

Dobór systemów klasy ERP

Zintegrowany system zarządzania produkcją ZKZ-ERP

Ćwiczenia 3: Specyfikacja wymagań Pytania:

System wspomagania obsługi pracy gabinetu stomatologicznego

Faza strategiczna. Synteza. Analiza. Instalacja. Faza strategiczna. Dokumentacja. kodowanie implementacja. produkt konserwacja

Diagramy przypadków użycia

Projekt z przedmiotu Projektowanie systemów teleinformatycznych

CRM. moduł zarządzania relacjami z klientami. Poradnik dla użytkowników systemu FIRMA 1/1

REQB POZIOM PODSTAWOWY PRZYKŁADOWY EGZAMIN

Wymagania klienta mogą być opisane na różnych poziomach abstrakcji: Podział wymagań: Wymagania funkcjonalne Wymagania niefunkcjonalne

SPECYFIKACJE WYMAGAŃ PRZYPADKI UŻYCIA (USE CASE)

Inżynieria oprogramowania II

Specyfikacja wymagań systemowych (może podlegać edytowaniu na kolejnych etapach)

System automatycznego wysyłania SMSów SaldoSMS

SPECYFIKACJA WYMAGAŃ. Technologie Obiektowe

Język UML w modelowaniu systemów informatycznych

Zarządzanie i realizacja projektów systemu Microsoft SharePoint 2010

mpensjonat Oprogramowanie dla : hoteli pensjonatów domów wczasowych hosteli

Inżynieria wymagań. Inżynieria wymagań 1/1

FORMULARZ OCENY PARAMETRÓW TECHNICZNYCH

SM-EX System Multipłatności - EX

Zmiany w programie VinCent 1.29

Nowości w logistyce Elementy SCM w wersji 9.0

Katalog handlowy e-quality

System wspomagający zarządzanie zbiórką surowców wtórnych

ARCHITEKCI SUKCESU W LOGISTYCE DLA Politechniki Lubelskiej

SKRÓCONY OPIS systemu lojalnościowego

Projektowanie systemów informatycznych. Roman Simiński siminskionline.pl. Diagramy przypadków użycia

Projekt zespołowy Osoby wykonujące projekt:

Inżynieria wymagań. Wykład 2 Proces pisania przypadków użycia. Część 6 Wskazówki i sugestie

Instrukcja obsługi: Moduł Reklamacje

Piaseczno, r. Załącznik nr 1 do Zapytania ofertowego nr 07/2015 Wymagania dla systemu ERP w Creotech Instrument S.A.

TEMAT1 DZIENNIK OCEN STUDENTÓW

Agenda. Cele projektu Wizja projektu Modelowanie biznesowe Wymagania użytkownika Przypadki użycia

slajd 1 Model przypadków użycia Anna Bobkowska

Specyfikacja funkcjonalna

Zarządzanie sprzedażą w programie bs4

Inżynieria Programowania Inżynieria wymagań. Plan wykładu. Motto. Wstęp. Notatki. Notatki. Notatki. Notatki. Arkadiusz Chrobot

Kompletacja (picking) prof. PŁ dr hab. inż. Andrzej Szymonik Łódź 2014/2015

Inżynieria oprogramowania

OPIS PRZEDMIOTU ZAMÓWIENIA

Praca klienta biura rachunkowego na wspólnej bazie

Testowanie oprogramowania. Testowanie oprogramowania 1/34

Analiza i projektowanie obiektowe 2015/2016. Wykład 2: Przypadki użycia

NETWORK Monitorowanie serwerów, urządzeń i aplikacji INVENTORY Inwentaryzacja sprzętu i oprogramowania, audyty legalności USERS Monitorowanie

Specyfikowanie wymagań przypadki użycia

W trakcie projektowania aplikacji jako najważniejsze cele przyjęto:

Uchwała Nr 16/V/2010

Opis Architektury Systemu Galileo

LK1: Wprowadzenie do MS Access Zakładanie bazy danych i tworzenie interfejsu użytkownika

Regulamin korzystania z kiosku Szybka faktura w sklepach IKEA

Diagramy przypadków uŝycia. związków między nimi

NETWORK Monitorowanie serwerów, urządzeń i aplikacji INVENTORY Inwentaryzacja sprzętu i oprogramowania, audyty legalności USERS Monitorowanie

Kilometrówki24.pl to system służący do ewidencjonowania przejazdów pojazdów wykorzystywanych w przedsiębiorstwach.

POLITYKA PRYWATNOŚCI HOTELU Dwór Dwikozy Ochrona Danych Osobowych

Wstęp. Inżynieria wymagań. Plan wykładu. Wstęp. Wstęp. Wstęp. Schemat procesu pozyskiwania wymagań

Platforma elektronicznego obiegu dokumentów dla klientów KBA. Copyright by Korycka, Budziak & Audytorzy Sp. z o.o.

Reguły plików cookies witryny i usług internetowych tsop.pl

TEMAT1 DZIENNIK OCEN STUDENTÓW. Projekt aplikacji bazodanowej w środowisku INTERNET

Inżynieria Programowania Inżynieria wymagań

Katarzyna Twardoch CMMS Dept. R&D Manager Help Desk w Utrzymaniu Ruchu Zarządzanie dokumentacją Magazyny i zakupy pod kontrolą

Efektywne zarządzanie infrastrukturą IT, inwentaryzacja sprzętu i oprogramowania oraz ochrona danych przed wyciekiem dzięki wdrożeniu Axence nvesion

B2BCloud simple way to Scale Sale

Wymagania pozafunkcjonalne - projektowanie interfejsu użytkownika

Instrukcja obsługi platformy B2B Polcolorit S.A.

Zarządzanie reklamacjami i serwisem w programie bs4

Automatyczne decyzje kredytowe, siła szybkiego reagowania i optymalizacji kosztów. Roman Tyszkowski ING Bank Śląski S.A. roman.tyszkowski@ingbank.

ZAPYTANIE OFERTOWE OPC/2/000052/19

Tom 6 Opis oprogramowania Część 8 Narzędzie do kontroli danych elementarnych, danych wynikowych oraz kontroli obmiaru do celów fakturowania

Doskonalenie procesów - TO BE (tak będzie) Ujęcie statyczne

Axence nvision Nowe możliwości w zarządzaniu sieciami

Zasady Wykorzystywania Plików Cookies

Struktura i funkcjonowanie komputera pamięć komputerowa, hierarchia pamięci pamięć podręczna. System operacyjny. Zarządzanie procesami

Projektowanie oprogramowania. Wykład Weryfikacja i Zatwierdzanie Inżynieria Oprogramowania Kazimierz Michalik

Systemy rozproszone. na użytkownikach systemu rozproszonego wrażenie pojedynczego i zintegrowanego systemu.

PREZENTACJA MODUŁU WIZUALIZACJI

Istotne zmiany w wersji 356 ToyDMS

Od producenta do konsumenta!

Transkrypt:

Cele przedsięwzięcia Określanie wymagań Klienta, np. Wzrost efektywności, spadek kosztów, rozszerzenie rynku, unikanie błędów Wykonawcy Biznesowe Techniczne Priorytety! Kontekst przedsięwzięcia Użytkownicy role Istniejące oprogramowanie Specyficzny sprzęt Określanie wymagań Współpraca klienta i wykonawcy! Źródła: Wywiady z przedstawicielami klienta Analiza materiałów dostarczonych przez klienta, przepisów prawnych Porównanie z innymi systemami Rodzaje wymagań Wymagania funkcjonalne funkcje wspomagane przez oprogramowania - przypadki użycia (use cases) Wymagania niefunkcjonalne ograniczenia Diagramy przypadków użycia use case diagrams Użytkownik Użytkownik, klasa użytkowników, system zewnętrzny (ang. actor) Grupa użytkowników wykorzystujących system w podobny sposób Przypadek użycia, wymaganie Przypadek użycia funkcjonalne, funckja (ang. use case) 1

Diagramy przypadków użycia use case diagrams Związki używania (use) i rozszerzania (extend) Przypadek użycia Dodawanie kategorii pojazdow Uzywane sporadycznie, podczas dodawania pojazdu, jezeli nie ma jeszcze danej kategorii Użytkownik «extend» Korzystanie z funkcji (ang. actor flow) Edycja pojazdów «use» «use» Dodawanie pojazdu Przewoznik «use» Usuwanie pojazdow Edycja pojazdu Przykład i związek generalizacji (generalization) Hierarchia wymagań funkcjonalnych Przykład: Uzytkownik Ewidencja klientów Przewoznik Wydawanie opinii Zleceniodawca Dodawanie klienta Edycja danych klienta Zarzadzanie pojazdami Optymalizacja Zarzadzanie uzytkownikami Zarzadzanie ladunkami Usuwanie klienta Wyszukiwanie klientów Wyszukiwanie proste Wyszukiwanie złożone 2003 Andrzej Jaszkiewicz. Wyłącznie dla użytku studentów Politechniki Poznańskiej, Administrator kierunek Informatyka Sposoby poszukiwania wymagań funkcjonalnych Wykorzystanie hierarchii wymagań Z góry na dół Z góry na dół Z dołu do góry Podejście mieszane Wykorzystanie informacji o rolach użytkowników Śledzenie procesów biznesowych Analiza scenariuszy 2

Z dołu do góry Metoda mieszana Wykorzystanie informacji o rolach użytkowników Kierownik f4 f1 f9 f6 f7 f3 f2 f5 f8 Ksiegowy Śledzenie procesów biznesowych Proces zbiór czynności wykonywanych przez różne osoby i działy organizacji scharakteryzowany przez: Wejście Wyjście (wynik) Cele Zadania Proces biznesowy proces, którego wynik ma wartość biznesową Kasjer Magazynier Śledzenie procesów biznesowych f1 f4 f6 U1 U2 f2 f7 U3 f3 f5 f8 Proces obsługi klienta półhurtowego 1. Dział sprzedaży wybór produktów, sformułowanie zamówienia połączone z weryfikacją dostępności produktów 2. Magazyn ponowna weryfikacja, skompletowanie zamówienia 3. Księgowość wystawienie faktury, rozliczenie finansowe 4. Magazyn wydanie towarów 3

Analiza scenariuszy Scenariusz słowny opis przykładowego sposobu () korzystania z systemu Z reguły obejmuje wiele funkcji Analiza scenariuszy - przykład Użytkownik podaje podstawowe informacje o planowanym wyjeździe. Chce odwiedzić Polskę, spędzić tam tydzień, wjedzie i wyjedzie od strony Czech. Interesują go ciekawe miasta, wykopaliska archeologiczne i wydarzenia muzyczne (muzyka klasyczna). Określa ograniczenia finansowe. System generuje proponowany plan podróży biorąc pod uwagę podane preferencje i ograniczenia. Analiza scenariuszy przykład c. d. Użytkownik może szczegółowo przeglądać proponowaną trasę korzystając m. in. z prezentacji multimedialnych System proponuje użytkownikowi potencjalne modyfikacje trasy, biorąc pod uwagę położenie geograficzne poszczególnych atrakcji oraz wybory innych użytkowników o podobnych preferencjach Analiza scenariuszy przykład c. d. Użytkownik modyfikuje trasę dodając do niej wizytę w Biskupinie i rezygnując z wizyty w Gnieźnie Użytkownik akceptuje trasę i otrzymuje jej szczegółowy opis (wydruk, plik) Użytkownik wybiera funkcję rezerwacji hoteli. Po dokonaniu niewielkiej opłaty system współpracując z zewnętrznym systemem rezerwacji hotelowej dokonuje odpowiednich rezerwacji Definiowanie ograniczeń i preferencji Generowanie planu podróży Przeglądanie trasy Wizualizacja geograficzna Prezentacja harmonogramu trasy Multimedialne prezentacje atrakcji Generowanie i prezentacja proponowanych zmian Modyfikowanie trasy Akceptowanie trasy Przygotowanie szczegółowego opisu trasy Rezerwacja hoteli Pobieranie opłaty Rezerwacja hotelu 4

Analiza scenariuszy Użytkownik wchodzi na naszą stronę i ponieważ korzystał z niej już wcześniej wybiera od razu opcję wyszukiwania. Najpierw określa kraj, który go interesuje Szwajcaria, a następnie miasto Zurich. Użytkownik wybiera rodzaj oferty turystycznej narty. Ponieważ uprawianie narciarstwa w samym Zurichu nie jest możliwe otrzymuje listę kilku pobliskich stacji narciarskich. Użytkownik zapoznaje się z informacjami o kilku stacjach narciarskich trasy, wyciągi, ceny, możliwość wypożyczenia sprzętu oraz aktualne warunki śniegowe. Użytkownik sprawdza możliwość dojazdu z Zurichu do stacji narciarskiej Flumsberg. Sprawdza też możliwości zakwaterowania w (pobliżu) Flumsbergu. Ostatecznie dokonuje rezerwacji biletu rail&ski i pokoju w pensjonacie we Flumsbergu. Wybór obszaru zainteresowania Wybór kraju Wybór miasta Wybór rodzaju oferty turystycznej Przeglądanie ofert stacji narciarskich Wyszukiwanie możliwości dojazdu Wyszukiwanie możliwości zakwaterowania Rezerwacja Rezerwacja biletów Rezerwacja miejsc noclegowych Analiza scenariuszy Do magazynu zgłasza się klient, który złożył zamówienie w dziale sprzedaży. Klient podaje numer zamówienia, lub inną informację identyfikującą klienta. Magazynier odszukuje zamówienie w systemie i weryfikuje czy zamówiony towar został już zablokowany dla potrzeb klienta. Jeżeli tak, to potwierdza przyjęcie zamówienia do realizacji i prosi klienta o przejście do księgowości. Magazynier otrzymuje listę towarów do wydania wraz z ich lokalizacjami. Po skompletowaniu zamówienia potwierdza ten fakt w systemie. Po wydaniu towaru klientowi potwierdza ten fakt w systemie. Realizacja zamówienia Identyfikacja zamówienia Weryfikacja zablokowania towaru Potwierdzenie przyjęcia zamówienia do realizacji Potwierdzenie skompletowania zamówienia Potwierdzenie wydania towaru Specyfikacja wymagań Język naturalny Metody formalne Formularze Elementy specyfikacji wymagań Nazwa Opis Dane wejściowe i ich źródła Wynik Warunki początkowe i końcowe Efekty uboczne Wyjątki Priorytet Źródło wymagania Wymagania powiązane Uzasadnienie 5

Wymagania niefunkcjonalne Ograniczenia dotyczące Produktu Procesu Współpracy z systemami zewnętrznymi Problem specyfikacji wymagań niefunkcjonalnych w sposób weryfikowalny Specyfikacja wymagań niefunkcjonalnych w sposób weryfikowalny Wydajność Liczba transakcji obsłużonych w ciągu sekundy Czas odpowiedzi Szybkość odświeżania ekranu Rozmiar Wymagana pamięć RAM Wymagana pamięć dyskowa Łatwość użytkowania Czas niezbędny dla przeszkolenia użytkowników Liczba stron dokumentacji Zgodność ze standardami Specyfikacja wymagań niefunkcjonalnych w sposób weryfikowalny Ostrzezenie Wykonanie tej operacji spowoduje utrate wszystkich wyników obliczen. Czy chcesz kontynuowac? Nie Tak Niezawodność Prawdopodobieństwo błędnego wykonania podczas realizacji transakcji Częstotliwość występowania błędnych wykonań Średni czas pomiędzy błędnymi wykonaniami Dostępność (procent czasu, w którym system jest dostępny) Odporność (ang. robustness) Czas restartu po awarii systemu Prawdopodobieństwo zniszczenia danych w przypadku awarii Przenośność Procent kodu zależnego od platformy docelowej Liczba platform docelowych Koszt przeniesienia na nową platformę 6