Jerzy Nawrocki, Inżynieria oprogramowania II

Transkrypt

1 Jerzy Nawrocki, Wymagania funkcjonalne Cel wykładu Jerzy Nawrocki Jak specyfikować wymagania funkcjonalne za pomocą przypadków użycia? Wymagania funkcjonalne (2) Wymaganie w RequisitePro Rational RequisitePro Nazwa (tag), Tekst, Atrybuty Wymagania funkcjonalne (3) Wymagania funkcjonalne (4) Macierz atrybutów w RequisitePro Stracone uzasadnienie Tag Krótki tekst Atrybut Atrybut Potrzebujemy daną funkcjonalność? Pełen tekst Wymagania funkcjonalne (5) Wymagania funkcjonalne (6) Wymagania funkcjonalne 1

2 Jerzy Nawrocki, Ivar Jacobson 1967: Ericsson, systemy telekomunikacyjne 1985: Ph.D., The Royal Institute of Tech., Stockholm 1987: Założyciel Objectory AB 1995: Objectory AB łączy się z Rationalem 2003: IBM kupuje Rationala Wymagania funkcjonalne (7) Wymagania funkcjonalne (8) Diagram przypadków użycia w UML-u Znajdź lot Agent biura podróży Zrób plan podróży Rezerwuj lot Wydaj bilet Rezerwacja lotów Bank Opowiadanie opisujące jak aktor (użytkownik lub urządzenie) współpracuje z systemem aby osiągnąć dany cel. Wymagania funkcjonalne (9) Wymagania funkcjonalne (10) Aktualizacja danych osobowych Aktor: Członek stowarzyszenia Główny scenariusz: 1. Członek stowarzyszenia wprowadza swoje konto i hasło. 2. System pokazuje stronę z danymi członka stowarzyszenia. 3. Członek stowarzyszenia wybiera opcję aktualizacji danych. 4. System prezentuje dane gotowe do aktualizacji. 5. Członek stowarzyszenia zmienia niektóre dane. 6. System prosi o zatwierdzenie zmian. 7. Członek stowarzyszenia zatwierdza wprowadzone zmiany. 1a. Konto lub hasło jest niepoprawne. 1a1. System pokazuje komunikat o błędzie i wraca do 1. Aktor: Nazwa Scenariusz główny: 1. Akcja 2. Akcja 3. Akcja 4. Krok.a. Zdarzenie Krok.a1. Akcja Krok.a2. Akcja Krok.b. Zdarzenie Krok.b1. Akcja Nazwa przypadku użycia Wymagania funkcjonalne (11) Wymagania funkcjonalne (12) Wymagania funkcjonalne 2

3 Jerzy Nawrocki, Najkrótsza forma przypadków użycia Ten sam cel Scenariusz #1 Scenariusz #2 Scenariusz #3 Głowny scenariusz: 1. Krok 2. Krok 1a. Zdarzenie 1a1. Krok alternatywny Dziekan: Ustala liczbę miejsc na specjalnościach magisterskich. Otrzymuje listę studentów przypisanych do specjalności. Student: Wprowadza swoje preferencje szeregując specjalności od najbardziej do najmniej interesującej. Dowiaduje się do jakiej specjalności magisterskiej został przypisany. Wymagania funkcjonalne (13) Wymagania funkcjonalne (14) Opis interakcji człowiek komputer Opis procesu biznesowego Definicja przypadku użycia Opowiadanie opisujące jak aktor (użytkownik osoba lub urządzenie) współpracuje z systemem innymi aktorami (ludźmi lub urządzeniami), aby osiągnąć dany cel. Definicja przypadku użycia Opowiadanie opisujące jak aktor (użytkownik osoba lub urządzenie) współpracuje z systemem innymi aktorami (ludźmi lub urządzeniami), aby osiągnąć dany cel. Wymagania funkcjonalne (15) Wymagania funkcjonalne (16) Opis procesu biznesowego Wypłata ubezpieczenia za wypadek samochodowy Aktorzy: Ubezpieczony -- Ofiara wypadku Ubezpieczyciel -- Firma ubezpieczeniowa Agent -- Reprezentant firmy ubezpieczeniowej Scenariusz główny: 1. Ubezpieczony przedstawia żądanie wypłaty wraz z odpowiednimi danymi. 2. Ubezpieczyciel sprawdza, że Ubezpieczony ma ważną polisę. 3. Ubezpieczyciel wyznacza Agenta do zbadania sprawy. 4. Agent upewnia się, że szczegóły wypadku są zgodne z warunkami polisy. 5. Ubezpieczyciel wypłaca pieniądze Ubezpieczonemu. 1a. Przedstawione dane są niekompletne: 1a1. Ubezpieczyciel żąda podania brakujących danych. 1a2. Ubezpieczony dostarcza brakujące dane. 2a. Ubezpieczony nie posiada ważnej polisy: Wymagania funkcjonalne (17) Wymagania funkcjonalne (18) Wymagania funkcjonalne 3

4 Jerzy Nawrocki, Przepływ sterowania w programach komputerowych Instrukcje skoku uważa się za szkodliwe Corrado Böhm INAC-CNR, Rzym Dla każdego programu istnieje równoważny program korzystający jedynie z sekwencji i iteracji (while) jako struktur przepływu sterowania. C. Böhm, G. Jacopini, Flow diagrams, Turing Machines and Languages with only Two Formation Rules, Comm. of the ACM, 9(5): ,1966. Wymagania funkcjonalne (19) Edsger W. Dijkstra Eindhoven Univ. of Technology Programowanie strukturalne: sekwencja selekcja (if-then-else) iteracja (while-do) E.W. Dijkstra, Go To Statement Considered Harmful, Comm. of the ACM, Volume 11 (3): , Wymagania funkcjonalne (20) Boolean Primary (int n){ int i, result; if (n < 1) {result= False; ERROR "Wrong input" } else if (n==1 or n==2) result= True; else if (n % 2 == 0) result= False; else { result= True; for (i=3; i < n/2; i+=2) if (n%i==0) result= False; } return result; } If-then-else może być szkodliwe Sprawdzanie, że N jest liczbą pierwszą Główny: 1. Użytkownik wprowadza N. 2. System ustawia zmienną pomoc. RESULT na TRUE i K na W przypadku podzielności N przez K system ustawia RESULT na FALSE. 4. System powiększa K o 2 i wraca do kroku 3. 2a. N < 1 2a1. System informuje o błędzie. 2b. N=1 or N=2 2b1. System ust. RESULT na TRUE. 2c. N jest podzielne... Wymagania funkcjonalne (21) Zdarzenie 2a Krok 2-1 Akcja 2-1 Krok 2-2 Akcja 2-2 Paradygmat przypadków użycia Start Akcja 1 Akcja 2 Akcja 3 Stop Krok 1 Krok 2 Krok 3 Wymagania funkcjonalne (22) Nazwy przypadków użycia Wymagania funkcjonalne (23) Tworzenie rekordu pracownika Usuwanie rekordu pracownika Transakcje wartościowe dla użytkownika Zidentyfikuj wartościowe usługi, jakie system dostarcza aktorom, aby osiągnęli swoje cele biznesowe. Wymagania funkcjonalne (24) Wymagania funkcjonalne 4

5 Jerzy Nawrocki, Podoba się? Zapisanie się na przedmiot Główny: 1. Wyświetl pusty plan zajęć. 2. Wyświetl listę wszystkich zajęć w następujący sposób: Lewe okno pokazuje wszystkie przedmioty w systemie w porządku alfabetycznym. Dolne okno pokazuje godziny, w których podświetlony przedmiot jest dostępny.. 3. Zrób. 4. Student klika na przedmiot. 5. Zaktualizuj dolne okno, by pokazać godziny w jakich przedmiot jest dostępny. 6. Student klika na godziny przedmiotu, a potem klika na przycisk Dodaj przedmiot. Wymagania funkcjonalne (25) Opis zachowania Przypadki użycia służą do opisu zachowania. Interfejs użytkownika powinien być opisany gdzie indziej. Wymagania funkcjonalne (26) Podoba się? Zapisanie się na przedmiot Główny: 1. Wyświetl pusty plan zajęć. 2. Wyświetl listę wszystkich zajęć w następujący sposób: Lewe okno pokazuje wszystkie przedmioty w systemie w porządku alfabetycznym. Dolne okno pokazuje godziny, w których podświetlony przedmiot jest dostępny.. 3. Zrób. 4. Student klika na przedmiot. 5. Zaktualizuj dolne okno, by pokazać godziny w jakich przedmiot jest dostępny. 6. Student klika na godziny przedmiotu, a potem klika na przycisk Dodaj przedmiot. Wymagania funkcjonalne (27) Osiągnięty zamiar aktora Opisuj każdy krok tak, by jasno pokazać, jaki aktor wykonuje akcję i co przez to osiąga. Wymagania funkcjonalne (28) Poprawiony przypadek użycia Zapisanie się na przedmiot Główny: 1. System pokazuje pusty plan zajęć. 2. Student wskazuje przedmiot, którym jest zainteresowany. 3. System pokazuje godziny, w jakich przedmiot jest dostępny. 4. Student wybiera ten przedmiot. Długość przypadku użycia powinien mieć od 3 do 9 kroków. Wymagania funkcjonalne (29) Wymagania funkcjonalne (30) Wymagania funkcjonalne 5

6 Jerzy Nawrocki, Rejestracja nowego klienta Czy tak jest dobrze? Scenariusz główny: 1. Akwizytor wprowadza dane dot. nowego klienta. 2. System, po wydaniu zapytania w języku SQL do bazy danych Oracle celem sprawdzenia, że klient o takiej nazwie jeszcze nie istnieje, tworzy w bazie danych nową krotkę z danymi tego klienta. Neutralność technologiczna Zapisuj każdy przypadek użycia w sposób neutralny technologicznie. Wymagania funkcjonalne (31) Wymagania funkcjonalne (32) Poprawiony przypadek użycia Rejestracja nowego klienta Scenariusz główny: 1. Akwizytor wprowadza dane dot. nowego klienta. 2. System, po sprawdzeniu, że klient o takiej nazwie jeszcze nie istnieje, zapamiętuje jego dane. Wymagania funkcjonalne (33) Wymagania funkcjonalne (34) Struktura SRS 1.1 Cel dokumentu 1. Wprowadzenie 1.1 Cel dokumentu 1.2 Zakres produktu 1.3 Definicje, akronimy i skróty 1.4 Odwołania do literatury 1.5 Omówienie dokumentu 2. Ogólny opis produktu 3. Wymagania funkcjonalne 4. Wymagania pozafunkcjonalne Dodatki Indeks IEEE Std Rola dokumentu specyfikacji wymagań + czytelnicy Niniejszy dokument prezentuje wymagania dotyczące oprogramowania, czyli opisuje funkcjonalność budowanego oprogramowania i warunki, jakie ono musi spełniać. Dokument ten został napisany z myślą o potencjalnych użytkownikach, projektantach, programistach, osobach zajmujących się testowaniem i autorach dokumentacji użytkowej. Wymagania funkcjonalne (35) Wymagania funkcjonalne (36) Wymagania funkcjonalne 6

7 Jerzy Nawrocki, 1.2 Zakres produktu 1.3 Definicje, akronimy i skróty Identyfikacja produktu programistycznego poprzez nazwę. Co produkt będzie, a czego nie będzie robił. Zastosowanie specyfikowanego oprogramowania. Polskie Towarzystwo Literackie ma ponad 10 tys. członków. Członkowie często zmieniają swoje dane adresowe i są kłopoty z ich szybką aktualizacją. Problem dotyczy zarówno członków towarzystwa (ok. 500 osób rocznie zmienia swoje dane), jak też zarządu, który ma kłopoty z komunikacją. Rozwiązaniem ma być system internetowy e-member umożliwiający aktualizację danych adresowych poprzez Internet. Wymagania funkcjonalne (37) ASAP Tak szybko, jak to możliwe (od ang. As Soon As Possible) Explorer patrz MS Explorer... MS Explorer Oprogramowanie firmy Microsoft umożliwiające czytanie stron internetowych NIP Numer identyfikacji podatkowej PTL Polskie Towarzystwo Literackie Uporządkować alfabetycznie! Wymagania funkcjonalne (38) 1.4 Odwołania do literatury 1.5 Omówienie dokumentu System powinien podawać wartość średnią i odchylenie standardowe [Montgomery97]. [Montgomery97] D.Montgomery, Introduction to Statistical Quality Control, John Wiley & Sons, Boston, [ustawa2000] Ustawa z dnia o przeciwdziałaniu wprowadzaniu do obrotu finansowego wartości majątkowych pochodzących z nielegalnych lub nieujawnionych źródeł oraz o przeciwdziałaniu finansowaniu terroryzmu, Dz.U. z dnia 22 grudnia Omówić organizację pozostałej części dokumentu. W rozdziale 2. omówiono ogólnie produkt wraz z krótką charakterystyką użytkowników i funkcjonalności, jaką będzie im udostępniał budowany system. Rozdział 3. jest poświęcony szczegółowemu opisowi wymagań funkcjonalnych, które zostały podzielone na grupy wg klas użytkowników (ról). Wymagania te są punktem wyjścia do opisu wymagań pozafunkcjonalnych, które przedstawiono w rozdziale 4. Wymagania funkcjonalne (39) Wymagania funkcjonalne (40) Struktura SRS 2.1 Kontekst funkcjonowania 1. Wprowadzenie 2. Ogólny opis produktu 2.1 Kontekst funkcjonowania 2.2 Charakterystyka użytkowników 2.3 Główne funkcje produktu 2.4 Ograniczenia 2.5 Założenia i zależności 3. Wymagania funkcjonalne 4. Wymagania pozafunkcjonalne Dodatki Indeks IEEE Std Wymagania funkcjonalne (41) Omawiany system ma współpracować z systemem PolCard w zakresie płatności elektronicznych. Diagram kontekstu przedstawiono na rys. 1. Członek Zarząd E-Member PolCard Wymagania funkcjonalne (42) Wymagania funkcjonalne 7

8 Jerzy Nawrocki, 2.2 Charakterystyka użytkowników 2.3 Główne funkcje produktu Można wyróżnić następujące role: Członek towarzystwa Gros członków PTL (ponad 80%) jest w przedziale od 30 do 55 lat. Część z nich ma problemy ze wzrokiem. Z przeprowadzonej ostatnio ankiety wynika, że 80% członków ma w domu komputer i umie lub chce się nauczyć korzystać z Internetu. Zarząd Wszyscy członkowie zarządu mają komputery i potrafią korzystać z Internetu. Produkt udostępnia funkcje opisane poniżej. Członek PTL może za pomocą e-member: Czytać swoje dane przechowywane w systemie Aktualizować swoje dane Zarząd PTL może: Wysyłać do członków PTL korespondencję zbiorową Wymagania funkcjonalne (43) Wymagania funkcjonalne (44) 2.4 Ograniczenia 2.5 Założenia i zależności System musi spełniać wymagania stawiane przez ustawę o ochronie danych osobowych [ustawa-osob]. Prezentowane wymagania dotyczą stanu prawnego na dzień 1 września 2005 roku. Wymagania funkcjonalne (45) Wymagania funkcjonalne (46) 1. Wprowadzenie 2. Ogólny opis produktu 3. Wymagania funkcjonalne 3.1 Członek PTL Czytanie danych Aktualizacja danych osobowych 3.2 Zarząd PTL Wysyłanie korespondencji 4. Wymagania pozafunkcjonalne Dodatki Indeks Struktura SRS IEEE Std Aktualizacja danych osobowych Aktor: Członek stowarzyszenia Główny scenariusz: 1. Członek stowarzyszenia wprowadza swoje konto i hasło. 2. System pokazuje stronę z danymi członka stowarzyszenia. 3. Członek stowarzyszenia wybiera opcję aktualizacji danych. 4. System prezentuje dane gotowe do aktualizacji. 5. Członek stowarzyszenia zmienia niektóre dane. 6. System prosi o zatwierdzenie zmian. 7. Członek stowarzyszenia zatwierdza wprowadzone zmiany. 1a. Konto lub hasło jest niepoprawne. 1a1. System pokazuje komunikat o błędzie i wraca do 1. Wymagania funkcjonalne (47) Wymagania funkcjonalne (48) Wymagania funkcjonalne 8