Dokument specyfikacji wymagań J.Nawrocki Wykł. 2 Analiza systemów informatycznych Wykład 2 Dokument specyfikacji wymagań Jerzy.Nawrocki@put.poznan.pl www.cs.put.poznan.pl/jnawrocki/wsb-asi Analiza systemów inf.

Struktura SRS 1. Wprowadzenie 2. Ogólny opis produktu IEEE Std 830-1998 1. Wprowadzenie 2. Ogólny opis produktu 3. Wymagania funkcjonalne 4. Wymagania pozafunkcjonalne Dodatki Indeks J.Nawrocki, Dokument specyfikacji wymagań

SRS – Ogólny opis produktu SRS – Wymagania funkcjonalne J.Nawrocki Plan wykładu Wykł. 2 SRS – Wprowadzenie SRS – Ogólny opis produktu SRS – Wymagania funkcjonalne Przypadki użycia Wymagania pozafunkcjonalne Dobre praktyki dotyczące dokumentu SRS Kontrola jakości Szacowanie rozmiaru i Standardy serii ISO 9000 Modele CMM/CMMI Inżynieria wymagań Zarządzanie projektami Personal Software Process Team Software Process Zwinne metodyki Rational Unified Process Projekty dyplomowe J.Nawrocki, Dokument specyfikacji wymagań Analiza systemów inf.

SRS – Ogólny opis produktu SRS – Wymagania funkcjonalne J.Nawrocki Plan wykładu Wykł. 2 SRS – Wprowadzenie SRS – Ogólny opis produktu SRS – Wymagania funkcjonalne Przypadki użycia Wymagania pozafunkcjonalne Dobre praktyki dotyczące dokumentu SRS Kontrola jakości Szacowanie rozmiaru i Standardy serii ISO 9000 Modele CMM/CMMI Inżynieria wymagań Zarządzanie projektami Personal Software Process Team Software Process Zwinne metodyki Rational Unified Process Projekty dyplomowe J.Nawrocki, Dokument specyfikacji wymagań Analiza systemów inf.

Struktura SRS 1. Wprowadzenie 1.1 Cel dokumentu 1.2 Zakres produktu IEEE Std 830-1998 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 J.Nawrocki, Dokument specyfikacji wymagań

Rola dokumentu specyfikacji wymagań + czytelnicy 1.1 Cel dokumentu 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. J.Nawrocki, Dokument specyfikacji wymagań

Identyfikacja produktu programistycznego poprzez nazwę. 1.2 Zakres produktu Identyfikacja produktu programistycznego poprzez nazwę. Co produkt będzie, a czego nie będzie robił. Zastosowanie specyfikowanego oprogramowania. Wizja produktu: Na czym polega problem? Kogo dotyczy? Jakie są jego implikacje? Jaki jest pomysł na jego rozwiązanie? J.Nawrocki, Dokument specyfikacji wymagań

Identyfikacja produktu programistycznego poprzez nazwę. 1.2 Zakres produktu 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ą. Konsekwencją tego stanu rzeczy są zaległości składkowe rzędu 15 tys. zł. Rozwiązaniem ma być system internetowy e-Member umożliwiający aktualizację danych adresowych poprzez Internet. J.Nawrocki, Dokument specyfikacji wymagań

1.3 Definicje, akronimy i skróty 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! J.Nawrocki, Dokument specyfikacji wymagań

1.4 Odwołania do literatury System powinien podawać wartość średnią i odchylenie standardowe [Montgomery97]. [Montgomery97] D.Montgomery, Introduction to Statistical Quality Control, John Wiley & Sons, Boston, 1997. [ustawa2000] Ustawa z dnia 16.11.2000 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 2000. J.Nawrocki, Dokument specyfikacji wymagań

Omówić organizację pozostałej części dokumentu. 1.5 Omówienie dokumentu 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. J.Nawrocki, Dokument specyfikacji wymagań

SRS – Ogólny opis produktu SRS – Wymagania funkcjonalne J.Nawrocki Plan wykładu Wykł. 2 SRS – Wprowadzenie SRS – Ogólny opis produktu SRS – Wymagania funkcjonalne Przypadki użycia Wymagania pozafunkcjonalne Dobre praktyki dotyczące dokumentu SRS Kontrola jakości Szacowanie rozmiaru i Standardy serii ISO 9000 Modele CMM/CMMI Inżynieria wymagań Zarządzanie projektami Personal Software Process Team Software Process Zwinne metodyki Rational Unified Process Projekty dyplomowe J.Nawrocki, Dokument specyfikacji wymagań Analiza systemów inf.

Struktura SRS 1. Wprowadzenie 2. Ogólny opis produktu IEEE Std 830-1998 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 J.Nawrocki, Dokument specyfikacji wymagań

2.1 Kontekst funkcjonowania Omawiany system ma współpracować z systemem PolCard w zakresie płatności elektronicznych. Diagram kontekstu przedstawiono na rys. 1. E-Member Członek Zarząd PolCard J.Nawrocki, Dokument specyfikacji wymagań

2.2 Charakterystyka użytkowników 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. J.Nawrocki, Dokument specyfikacji wymagań

2.3 Główne funkcje produktu 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ą J.Nawrocki, Dokument specyfikacji wymagań

2.4 Ograniczenia System musi spełniać wymagania stawiane przez ustawę o ochronie danych osobowych [ustawa-osob]. J.Nawrocki, Dokument specyfikacji wymagań

2.5 Założenia i zależności Prezentowane wymagania dotyczą stanu prawnego na dzień 1 września 2005 roku. J.Nawrocki, Dokument specyfikacji wymagań

SRS – Ogólny opis produktu SRS – Wymagania funkcjonalne J.Nawrocki Plan wykładu Wykł. 2 SRS – Wprowadzenie SRS – Ogólny opis produktu SRS – Wymagania funkcjonalne Przypadki użycia Wymagania pozafunkcjonalne Dobre praktyki dotyczące dokumentu SRS Kontrola jakości Szacowanie rozmiaru i Standardy serii ISO 9000 Modele CMM/CMMI Inżynieria wymagań Zarządzanie projektami Personal Software Process Team Software Process Zwinne metodyki Rational Unified Process Projekty dyplomowe J.Nawrocki, Dokument specyfikacji wymagań Analiza systemów inf.

Struktura SRS 1. Wprowadzenie 2. Ogólny opis produktu IEEE Std 830-1998 1. Wprowadzenie 2. Ogólny opis produktu 3. Wymagania funkcjonalne 3.1 Opis otoczenia 3.2.1 Członek PTL 3.2.1.1 Czytanie danych 3.2.1.2 Aktualizacja danych 3.2.2 Zarząd PTL 3.2.2.1 Wysyłanie korespondencji 4. Wymagania pozafunkcjonalne Dodatki Indeks J.Nawrocki, Dokument specyfikacji wymagań

Struktura SRS 1. Wprowadzenie 2. Ogólny opis produktu IEEE Std 830-1998 1. Wprowadzenie 2. Ogólny opis produktu 3. Wymagania funkcjonalne 3.1 Opis otoczenia 3.2.1 Członek PTL 3.2.1.1 Czytanie danych 3.2.1.2 Aktualizacja danych 3.2.2 Zarząd PTL 3.2.2.1 Wysyłanie korespondencji 4. Wymagania pozafunkcjonalne Dodatki Indeks J.Nawrocki, Dokument specyfikacji wymagań

Środowisko operacyjne Użytkownik ENV1 Urządzenie System zewnętrzny ENV2 System J.Nawrocki, Dokument specyfikacji wymagań

Środowisko operacyjne Wszyscy użytkownicy ENV1: Użytkownicy System będzie wykorzystywany przez następujących użytkowników: Główna księgowa Prezes Dyrektor handlowy J.Nawrocki, Dokument specyfikacji wymagań

Środowisko operacyjne Wszystkie urządzenia i systemy zewn. ENV2: Urządzenia i systemy zewn. System będzie się komunikował z następującymi urządzeniami i systemami zewnętrznymi: SAP R/3 J.Nawrocki, Dokument specyfikacji wymagań

Środowisko operacyjne Użytkownik System J.Nawrocki, Dokument specyfikacji wymagań

Środowisko operacyjne Wszystkie operacje. Użytkownik, urządzenie. lub system zewn. ENV3: Operacje głównej księgowej: Główna księgowa może zainicjować wykonanie następujących operacji: Pobranie faktury . . . J.Nawrocki, Dokument specyfikacji wymagań

Jak opisać pobranie faktury? System Metafora systemu Jak opisać pobranie faktury? System Producent Konsument J.Nawrocki, Dokument specyfikacji wymagań

Segregator z fakturami Metafora systemu Co muszę wiedzieć o systemie, aby opisać jego operacje? System Segregator z fakturami J.Nawrocki, Dokument specyfikacji wymagań

Wszystkie elementy i ich stany. Metafora systemu Wszystkie elementy i ich stany. MET1: Architektura wewnętrzna System będzie składał się z następujących elementów: Segregator z fakturami (pusty lub niepusty) . . . J.Nawrocki, Dokument specyfikacji wymagań

Struktura SRS 1. Wprowadzenie 2. Ogólny opis produktu IEEE Std 830-1998 1. Wprowadzenie 2. Ogólny opis produktu 3. Wymagania funkcjonalne 3.1 Opis otoczenia 3.2.1 Członek PTL 3.2.1.1 Czytanie danych 3.2.1.2 Aktualizacja danych 3.2.2 Zarząd PTL 3.2.2.1 Wysyłanie korespondencji 4. Wymagania pozafunkcjonalne Dodatki Indeks J.Nawrocki, Dokument specyfikacji wymagań

Nie do nas! Dokładność? Funkcja (Operacja) Wej. Wyj. Efekty uboczne Funkcje systemu Nie do nas! Dokładność? Funkcja (Operacja) STOP Wej. Wyj. 0.1234 Efekty uboczne J.Nawrocki, Dokument specyfikacji wymagań

WARUNEK: Segregator faktur jest niepusty. Funkcje systemu FUN1: Pobranie faktury WEJŚCIE: - WARUNEK: Segregator faktur jest niepusty. WYJŚCIE: Faktura (wzorzec WF-1/2001.09) EFEKT UBOCZNY: Pobrana faktura jest usuwana z segregatora. Jeśli jest to jedyna faktura w segregatorze, segregator staje się pusty. PRZETWARZANIE: - DOKŁADNOŚĆ: Cześć ułamkowa każdej kwoty ma dwie cyfry po przecinku. J.Nawrocki, Dokument specyfikacji wymagań

SRS – Ogólny opis produktu SRS – Wymagania funkcjonalne J.Nawrocki Plan wykładu Wykł. 2 SRS – Wprowadzenie SRS – Ogólny opis produktu SRS – Wymagania funkcjonalne Przypadki użycia Wymagania pozafunkcjonalne Dobre praktyki dotyczące dokumentu SRS Kontrola jakości Szacowanie rozmiaru i Standardy serii ISO 9000 Modele CMM/CMMI Inżynieria wymagań Zarządzanie projektami Personal Software Process Team Software Process Zwinne metodyki Rational Unified Process Projekty dyplomowe J.Nawrocki, Dokument specyfikacji wymagań Analiza systemów inf.

1967: Ericsson, systemy telekomunikacyjne Ivar Jacobson 1967: Ericsson, systemy telekomunikacyjne 1985: Ph.D., Dep. of Computer Systems, The Royal Institute of Tech., Stockholm 1987: Założyciel Objectory AB 1995: Objectory AB łączy się z Rationalem 2003: IBM kupuje Rationala http://www.analisi-disegno.com/uml/JacobsonInterview.html http://www.jaczone.com/ J.Nawrocki, Dokument specyfikacji wymagań

Ivar Jacobson Addison-Wesley, 1992 J.Nawrocki, Dokument specyfikacji wymagań

Przykładowy przypadek użycia Zarejestruj IO Aktor: Rejestrator IO Cel: Zarejestrować w systemie nową IO. Zdarzenie: Rejestrator otrzymał wniosek papierowy. Główny scenariusz Rejestrator IO: Wprowadza NIP lub REGON IO. System: Sprawdza poprawność wprowadzonego NIP/REGON. Rejestrator: Wprowadza pozostałe dane identyfikacyjne IO. System: Weryfikuje poprawność składniową wprowadzonych danych. Rejestrator: Wprowadza dane dotyczące jednostek IO. Rozszerzenia 2a. NIP/REGON jest niepoprawny 2a1. System wyświetla komunikat i wracamy do kroku 1. J.Nawrocki, Dokument specyfikacji wymagań

Przypadki użycia a scenariusze Ten sam cel Scenario #1 Przypadek użycia Scenario #2 Scenario #3 J.Nawrocki, Dokument specyfikacji wymagań

Przykładowy przypadek użycia Zarejestruj IO Aktor: Rejestrator IO Cel: Zarejestrować w systemie nową IO. Zdarzenie: Rejestrator otrzymał wniosek papierowy. Główny scenariusz Rejestrator IO: Wprowadza NIP lub REGON IO. System: Sprawdza poprawność wprowadzonego NIP/REGON. Rejestrator: Wprowadza pozostałe dane identyfikacyjne IO. System: Weryfikuje poprawność składniową wprowadzonych danych. Rejestrator: Wprowadza dane dotyczące jednostek IO. Rozszerzenia 2a. NIP/REGON jest niepoprawny 2a1. System wyświetla komunikat i wracamy do kroku 1. J.Nawrocki, Dokument specyfikacji wymagań

Zalety przypadków użycia Są półformalne. Wprowadzają strukturę do opowieści. Opisują także sytuacje błędne. Są podstawą do szacowania pracochłonności, specyfikacji szczegółowych wymagań, projektowania interfejsów i scenariuszy testowych. J.Nawrocki, Dokument specyfikacji wymagań

Źle napisany przypadek użycia Zapisz się na przedmiot (Główny scen.) Wyświetl pusty plan zajęć. Wyświetl listę wszystkich zajęć w następujący sposób: Lewe okno pokazuje wszystkie przedmioty w systemie uporządkowane alfabetycznie. Dolne okno pokazuje godziny, w których podświetlony przedmiot jest dostępny. Trzecie okno pokazuje wszystkie przedmioty znajdujące się obecnie w planie zajęć. Wykonaj. Student klika na przedmiot. Aktualizuj dolne okno aby pokazać godziny, w których przedmiot jest dostępny. Student klika na godziny a potem na przycisk „Dodaj przedmiot” . J.Nawrocki, Dokument specyfikacji wymagań

Źle napisany przypadek użycia Za dużo szczegółów dot. GUI Wyświetl pusty plan zajęć. Wyświetl listę wszystkich zajęć w następujący sposób: Lewe okno pokazuje wszystkie przedmioty w systemie uporządkowane alfabetycznie. Dolne okno pokazuje godziny, w których podświetlony przedmiot jest dostępny. Trzecie okno pokazuje wszystkie przedmioty znajdujące się obecnie w planie zajęć. Wykonaj. Student klika na przedmiot. Aktualizuj dolne okno aby pokazać godziny, w których przedmiot jest dostępny. Student klika na godziny a potem na przycisk „Dodaj przedmiot” . J.Nawrocki, Dokument specyfikacji wymagań

Inne często popełniane błędy Za dużo niskopoziomowych przypadków użycia („Authorize user”). Stosowanie przypadków użycia do prezentacji informacji nie-behawioralnej (np. opis formularzy – do dodatków). Za długie (powinny być krótkie, zazwyczaj 3-9 kroków). Fragmenty zdań (np. pomijanie nazwy aktora w opisie kroków). J.Nawrocki, Dokument specyfikacji wymagań

Krótki format Aktor Administrator Przypadek użycia UstawParametryMonito WybierzMonitor Opis Osoba monitorująca i kontrolująca system sterowania zadaniami. Umożliwia administratorowi podanie zakresu i dokładności monitorowanych elementów Wybierz przedmiot monitorowania (np. proces albo kolejkę oczekujących procesów) J.Nawrocki, Dokument specyfikacji wymagań

SRS – Ogólny opis produktu SRS – Wymagania funkcjonalne J.Nawrocki Plan wykładu Wykł. 2 SRS – Wprowadzenie SRS – Ogólny opis produktu SRS – Wymagania funkcjonalne Przypadki użycia Wymagania pozafunkcjonalne Dobre praktyki dotyczące dokumentu SRS Kontrola jakości Szacowanie rozmiaru i Standardy serii ISO 9000 Modele CMM/CMMI Inżynieria wymagań Zarządzanie projektami Personal Software Process Team Software Process Zwinne metodyki Rational Unified Process Projekty dyplomowe J.Nawrocki, Dokument specyfikacji wymagań Analiza systemów inf.

Wymagania poza funkcjonalne R P S unctionality - fukcjonalność sability - użyteczność eliability - niezawodność performance - wydajność ecurity - bezpieczeństwo 4.1 Użyteczność 4.2 Niezawodność 4.3 Wydajność 4.4 Bezpieczeństwo J.Nawrocki, Dokument specyfikacji wymagań

SRS – Ogólny opis produktu SRS – Wymagania funkcjonalne J.Nawrocki Plan wykładu Wykł. 2 SRS – Wprowadzenie SRS – Ogólny opis produktu SRS – Wymagania funkcjonalne Przypadki użycia Wymagania pozafunkcjonalne Dobre praktyki dotyczące dokumentu SRS Kontrola jakości Szacowanie rozmiaru i Standardy serii ISO 9000 Modele CMM/CMMI Inżynieria wymagań Zarządzanie projektami Personal Software Process Team Software Process Zwinne metodyki Rational Unified Process Projekty dyplomowe J.Nawrocki, Dokument specyfikacji wymagań Analiza systemów inf.

Klasyfikacja dobrych praktyk Podst. Pośred. Zaaw. 8 6 5 4 3 2 36 - 6 2 1 3 21 - 1 2 4 9 Dokument SRS Zbieranie wymagań Analiza i negocjacja wymag. Opisywanie wymagań Modelowanie systemu Walidacja wymagań Zarządzanie wymaganiami IW dla systemów krytycznych J.Nawrocki, Dokument specyfikacji wymagań

 Dokument wymagań Zdefiniuj standardową strukturę dokumentu Wyjaśnij, jak korzystać z dokumentu Dołącz streszczenie wymagań Opracuj uzasadnienie biznesowe dla systemu Zdefiniuj terminy specjalistyczne Wybierz czytelny szablon dokumentu Pomóż czytelnikom znaleźć informację Uczyń dokument łatwym do zmiany  J.Nawrocki, Dokument specyfikacji wymagań

Klasyfikacja dobrych praktyk Podst. Pośred. Zaaw. 8 6 5 4 3 2 36 - 6 2 1 3 21 - 1 2 4 9 Dokument SRS Zbieranie wymagań Analiza i negocjacja wymag. Opisywanie wymagań Modelowanie systemu Walidacja wymagań Zarządzanie wymaganiami IW dla systemów krytycznych J.Nawrocki, Dokument specyfikacji wymagań

 Opisywanie wymagań Zdefiniuj standardowe szablony dla opisu wymag. Pisz prosto i krótko Odpowiednio korzystaj z diagramów Wzbogacaj język naturalny innymi formami opisu Specyfikuj wymagania ilościowo  J.Nawrocki, Dokument specyfikacji wymagań

Kryteria jakości dokumentu SRS IEEE Std 830-1998 a) Poprawność; b) Jednoznaczność; c) Kompletność; d) Spójność; e) Informacja o ważności i stabilności; f) Weryfikowalność; g) Modyfikowalność; h) Możliwość śledzenia powiązań (traceability). J.Nawrocki, Dokument specyfikacji wymagań

Wreszcie! Podsumowanie Struktura dokumentu SRS Przypadki użycia Dobre praktyki Sommerville’a J.Nawrocki, Dokument specyfikacji wymagań

3. Czy dowiedziałeś się czegoś ważnego? 4. Co i jak poprawić? Ocena wykładu 1. Wrażenie ogólne (1 - 6) 2. Za szybko czy za wolno? 3. Czy dowiedziałeś się czegoś ważnego? 4. Co i jak poprawić? J.Nawrocki, Dokument specyfikacji wymagań