Specyfikacja wymagań

1. Specyfikacja wymagań Autor: Łukasz Olek

2. Plan wykładów Plan wykładów Zasady skutecznego działania Specyfikacja wymagań Kontrola jakości artefaktów Język UML, cz. I Język UML, cz. II Metody formalne Wzorce projektowe Zarządzanie konfiguracją Wprowadzenie do testowania Automatyzacja wykonywania testów Programowanie Ekstremalne Ewolucja oprogramowania i refaktoryzacja

3. Wprowadzenie

4. Wprowadzenie

5. Wprowadzenie

6. Wprowadzenie

7. Wprowadzenie

8. Wprowadzenie

9. Wprowadzenie ? =

10. Wprowadzenie Kontrakt =

11. Wprowadzenie Kontrakt Specyfikacja wymagań =

12. Wprowadzenie • Wymaganie = opis co system powinien robićźródło: www.wikipedia.org • Specyfikacja = zbiór wymagań • W momencie kiedy spiszemy wymagania, klient dostanie dokładnie to, czego potrzebuje

13. Wprowadzenie • W momencie kiedy spiszemy wymagania, klient dostanie dokładnie to, czego potrzebuje • 1. Słowa nie mają znaczenia!

14. Wprowadzenie • W momencie kiedy spiszemy wymagania, klient dostanie dokładnie to, czego potrzebuje • 1. Słowa nie mają znaczenia! • Załadunek kompletny? • Raport miesięczny? • SAD?

15. Wprowadzenie • W momencie kiedy spiszemy wymagania, klient dostanie dokładnie to, czego potrzebuje • 2. Wiedza: • świadoma • nieświadoma

16. Wprowadzenie • Wymagania telefonu Nokia N80: • duży wyświetlacz • duże, wygodne klawisze • aparat o wysokiej rozdzielczości

17. Wprowadzenie Co oznacza określenie „duże”? • Wymagania telefonu Nokia N80: • duży wyświetlacz • duże, wygodne klawisze • aparat o wysokiej rozdzielczości • WiFi Co oznacza określenie „wysoka”? Czy klawiatura nie może się znaleźć po drugiej stronie?

18. Jak sobie z tym poradzić? • Spisywanie wymagań to sztuka- nie ma uniwersalnego sposobu • Korzystaj z porad innych: • dobre praktyki • metody, które się sprawdziły

19. Plan wykładu • Wprowadzenie • Wymagania pozafunkcjonalne • Wymagania funkcjonalne: • Przypadki użycia • Jak pisać przypadki użycia? • Dobre praktyki Sommerville i Sawyer’a

20. Podział wymagań • Funkcjonalne: • Wprowadzanie nowej faktury • Generowanie raportu miesięcznego • Pozafunkcjonalne • minimum 20 faktur na godzinę • 200000h MTBF • maksimum 2 godziny potrzebne na przeszkolenie 1 pracownika

21. Wymagania pozafunkcjonalne • Functionality - funkcjonalność • Usability - użyteczność • Reliability - niezawodność • Performance - wydajność • Security - bezpieczeństwo

22. Sprawdzenie wiadomości ze specyfikacji wymagań

23. Plan wykładu • Wprowadzenie • Wymagania pozafunkcjonalne • Wymagania funkcjonalne: • Przypadki użycia • Jak pisać przypadki użycia? • Dobre praktyki Sommerville i Sawyer’a

24. Wymagania funkcjonalne • „System powinien…” • Funkcje systemu • Przypadki użycia

25. „System powinien…” • Zalety: • łatwość spisywania • Wady: • słaba czytelność • trudne sprawdzanie kompletności, spójności • System powinien umożliwić wystawianie faktur • System powinien generować zestawienie miesięczne faktur • Faktura powinna zawierać co najmniej jedną pozycję • … • (tak przez kolejnych 200 stron)

26. Funkcje systemu • Wady: • słaba czytelność • trudne do zrozumienia Funkcja (operacja) Wyjście Wejście Efekty uboczne

27. Przypadki użycia • Zalety: • łatwość spisywania • czytelność • łatwość zrozumienia i wyobrażenia sobie przyszłego systemu UC1: Wystawianie faktury Główny scenariusz: 1. Sprzedawca pragnie wystawić fakturę. 2. Sprzedawca wpisuje pozycje faktury. 3. System podlicza fakturę, nadaje jej nowy numer i zapisuje w rejestrze 4. Sprzedawca drukuje fakturę.

28. Plan wykładu • Wprowadzenie • Wymagania pozafunkcjonalne • Wymagania funkcjonalne: • Przypadki użycia • Jak pisać przypadki użycia? • Dobre praktyki Sommerville i Sawyer’a

29. Przypadek użycia • Forma ustrukturalizowana • Nazwa Wystawianie faktury

30. Przypadek użycia • Forma ustrukturalizowana • Nazwa • Identyfikator UC1: Wystawianie faktury

31. Przypadek użycia • Forma ustrukturalizowana • Nazwa • Identyfikator • Główny scenariusz UC1: Wystawianie faktury Główny scenariusz: 1. Sprzedawca pragnie wystawić fakturę. 2. Sprzedawca wpisuje pozycje faktury. 3. System podlicza fakturę, nadaje jej nowy numer i zapisuje w rejestrze 4. Sprzedawca drukuje fakturę.

32. Przypadek użycia • Forma ustrukturalizowana • Nazwa • Identyfikator • Główny scenariusz • Rozszerzenia UC1: Wystawianie faktury Główny scenariusz: 1. Sprzedawca pragnie wystawić fakturę. 2. Sprzedawca wpisuje pozycje 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 (powrót do 2.)

33. Przypadek użycia • Forma ustrukturalizowana • Nazwa • Identyfikator • Główny scenariusz • Rozszerzenia • Atrybuty • UC1: Wystawianie faktury Atrybuty: Główny aktor: Użytkownik Priorytet: Wysoki Źródło: Łukasz Olek Główny scenariusz: 1. Sprzedawca pragnie wystawić fakturę. 2. Sprzedawca wpisuje pozycje faktury. 3. System podlicza fakturę, nadaje jej nowy numer i zapisuje w rejestrze. 4. Sprzedawca drukuje fakturę. Rozszerzenia: …

34. Przypadki użycia, a UML • Diagram przypadków użycia: • Nazwy przypadków użycia • Powiązania z aktorami • Dobre jako „mapa”

35. Plan wykładu • Wprowadzenie • Wymagania pozafunkcjonalne • Wymagania funkcjonalne: • Przypadki użycia • Jak pisać przypadki użycia? • Dobre praktyki Sommerville i Sawyer’a

36. Jak pisać przypadki użycia? • Steve Adolph, Paul Bramble:„Patterns for Effective Use Cases”

37. Jak pisać przypadki użycia? • Przypadek użycia • Zbiór przypadków użycia • Proces • Zespół

38. Jak pisać przypadki użycia? • Przypadek użycia • Zbiór przypadków użycia • Proces • Zespół

39. Przypadek użycia • „Fraza czasownikowa w nazwie”: • Wystawianie faktury • Generowanie raportu miesięcznego • Główny przypadek użycia • Przypadek użycia 2 • Zarządzanie

40. Przypadek użycia • „Scenariusz i rozszerzenia”: • Nadrzędny cel: czytelność! • Scenariusz główny - najbardziej prawdopodobna ścieżka • 3-9 kroków • Rozszerzenia - alternatywne scenariusze • kiedy coś pójdzie nie tak • numer rozszerzenia: numer kroku + kolejna litera UC1: Dodawanie nowej faktury Główny scenariusz: 1. Użytkownik pragnie dodać nową fakturę. 2. Użytkownik wpisuje pozycje faktury. 3. System podlicza fakturę, nadaje jej nowy numer i zapisuje w rejestrze. 4. Użytkownik drukuje fakturę. Rozszerzenia: 3.A. Użytkownik nie dodał żadnej pozycji 3.A.1. System prosi o ponowne wprowadzenie pozycji (powrót do 2.)

41. Przypadek użycia • „Obojętność technologiczna”: • technologia jest zmienna • niepotrzebne ograniczenia • szczegóły GUI zaciemniają obraz • klient nie rozumie terminy technicznych • Przykłady: • Pracownik klika na link kalendarium • System zapisuje dane użytkownika w bazie danych • System za pomocą protokołu SOAP pobiera aktualną temperaturę

42. Jak pisać przypadki użycia? • Przypadek użycia • Zbiór przypadków użycia • Proces • Zespół

43. Zbiór przypadków użycia • „Rozwijalna historia”: • Hierarchiczne scenariusze • Można rozwijać lub zwijać w celu pokazania lub ukrycia szczegółów

44. Rozwijalna historia • Poziom celu użytkownika: • główny aktor osiąga zamierzony cel w ciągu jednej sesji przy komputerze

45. Rozwijalna historia • Poziom podfunkcji: • przecyzuje wykonanie funkcji

46. Rozwijalna historia • Poziom streszczenia (biznesowy): • kontekst dla wymagań użytkownika

47. Rozwijalna historia

48. Rozwijalna historia

49. Rozwijalna historia

50. Rozwijalna historia