Zaawansowana inżynieria oprogramowania Pozyskiwanie i dokumentowanie wymagań Koncepcja wykładu: Slajdy/ Lektor/Montaż: Jerzy Nawrocki/Łukasz Olek Łukasz Olek
Jan 23, 2016
Zaawansowana inżynieria oprogramowania
Pozyskiwanie i dokumentowanie wymagań
Koncepcja wykładu:Slajdy/Lektor/Montaż:
Jerzy Nawrocki/Łukasz OlekŁukasz Olek
Zaawansowana inżynieria oprogramowania
Pozyskiwanie i dokumentowanie wymagań (2)
Plan wykładów
Standardy serii ISO 9000Model dojrzałości CMMIZarządzanie przedsięwzięciami i PRINCE2, cz. IZarządzanie przedsięwzięciami i PRINCE2, cz. IIPersonal Software Process, cz. I Personal Software Process, cz. IIMetodyki programowania: TSP i RUPPozyskiwanie i dokumentowanie wymagań (IEEE 830)Wymagania pozafunkcyjne i ISO 9126Zarządzanie ryzykiemSystemy krytyczne i HAZOPSzacowanie rozmiaru oprogramowaniaSzacowanie pracochłonności
Zaawansowana inżynieria oprogramowania
Pozyskiwanie i dokumentowanie wymagań (3)
Przypadki użycia - przypomnienie
Zaawansowana inżynieria oprogramowania
Pozyskiwanie i dokumentowanie wymagań (4)
Wprowadzenie
• Jakie pytania zadać klientowi?
• Komu zadawać pytania?
• Jak stworzyć całą specyfikację wymagań?
Zaawansowana inżynieria oprogramowania
Pozyskiwanie i dokumentowanie wymagań (5)
Plan wykładu
• Wprowadzenie
• IEEE 830– Kryteria dobrej specyfikacji– Struktura dokumentu
• Dobre praktyki dotyczące dokumentu wymagań
Zaawansowana inżynieria oprogramowania
Pozyskiwanie i dokumentowanie wymagań (6)
Dobre praktyki inżynierii wymagań
• Yan Sommerville & Pete Sawyer ‘97
• Zbiór dobrych praktyk
Zaawansowana inżynieria oprogramowania
Pozyskiwanie i dokumentowanie wymagań (7)
Kryteria dobrej specyfikacji
• Poprawna
• Jednoznaczna
• Kompletna
• Spójna
• Uporządkowana wg ważności/stabilności
• Weryfikowalna
• Modyfikowalna
• Umożliwiająca śledzenie powiązań
IEEE Std 830-1998
Zaawansowana inżynieria oprogramowania
Pozyskiwanie i dokumentowanie wymagań (8)
Kryteria dobrej specyfikacji
• Poprawna
• Jednoznaczna
• Kompletna
• Spójna
• Uporządkowana wg ważności/stabilności
• Weryfikowalna
• Modyfikowalna
• Umożliwiająca śledzenie powiązań
IEEE Std 830-1998
Zaawansowana inżynieria oprogramowania
Pozyskiwanie i dokumentowanie wymagań (9)
Kryteria dobrej specyfikacji
• Poprawna
• Jednoznaczna
• Kompletna
• Spójna
• Uporządkowana wg ważności/stabilności
• Weryfikowalna
• Modyfikowalna
• Umożliwiająca śledzenie powiązań
IEEE Std 830-1998
Zaawansowana inżynieria oprogramowania
Pozyskiwanie i dokumentowanie wymagań (10)
Kryteria dobrej specyfikacji
• Poprawna
• Jednoznaczna
• Kompletna
• Spójna
• Uporządkowana wg ważności/stabilności
• Weryfikowalna
• Modyfikowalna
• Umożliwiająca śledzenie powiązań
IEEE Std 830-1998
Zaawansowana inżynieria oprogramowania
Pozyskiwanie i dokumentowanie wymagań (11)
Kryteria dobrej specyfikacji
• Poprawna• Jednoznaczna• Kompletna• Spójna• Uporządkowana wg ważności/stabilności• Weryfikowalna• Modyfikowalna• Umożliwiająca śledzenie powiązań
IEEE Std 830-1998
Zaawansowana inżynieria oprogramowania
Pozyskiwanie i dokumentowanie wymagań (12)
Kryteria dobrej specyfikacji
• Poprawna
• Jednoznaczna
• Kompletna
• Spójna
• Uporządkowana wg ważności/stabilności
• Weryfikowalna
• Modyfikowalna
• Umożliwiająca śledzenie powiązań
IEEE Std 830-1998
Zaawansowana inżynieria oprogramowania
Pozyskiwanie i dokumentowanie wymagań (13)
Kryteria dobrej specyfikacji
• Poprawna
• Jednoznaczna
• Kompletna
• Spójna
• Uporządkowana wg ważności/stabilności
• Weryfikowalna
• Modyfikowalna
• Umożliwiająca śledzenie powiązań
IEEE Std 830-1998
Zaawansowana inżynieria oprogramowania
Pozyskiwanie i dokumentowanie wymagań (14)
Kryteria dobrej specyfikacji
• Poprawna
• Jednoznaczna
• Kompletna
• Spójna
• Uporządkowana wg ważności/stabilności
• Weryfikowalna
• Modyfikowalna
• Umożliwiająca śledzenie powiązań
IEEE Std 830-1998
Zaawansowana inżynieria oprogramowania
Pozyskiwanie i dokumentowanie wymagań (15)
Plan wykładu
• Wprowadzenie
• IEEE 830– Kryteria dobrej specyfikacji
–Struktura dokumentu• Dobre praktyki dotyczące
dokumentu wymagań
Zaawansowana inżynieria oprogramowania
Pozyskiwanie i dokumentowanie wymagań (16)
Struktura SRS
1. Wprowadzenie2. Ogólny opis produktu3. Wymagania funkcjonalne4. Wymagania pozafunkcjonalneDodatkiIndeks
IEEE Std 830-1998
Określ standardową strukturę dokumentu
Określ standardową strukturę dokumentu
Zaawansowana inżynieria oprogramowania
Pozyskiwanie i dokumentowanie wymagań (17)
Zdefiniuj terminyspecjalistyczne
Zdefiniuj terminyspecjalistyczne
Dołącz streszczeniewymagań
Dołącz streszczeniewymagań
Wyjaśnij, jak korzystać z dokumentu
Wyjaśnij, jak korzystać z dokumentu
Struktura SRS
1. Wprowadzenie1.1 Cel dokumentu1.2 Zakres produktu1.3 Definicje, akronimy i skróty1.4 Odwołania do literatury1.5 Omówienie dokumentu
2. Ogólny opis produktu3. Wymagania funkcjonalne4. Wymagania pozafunkcjonalneDodatkiIndeks
IEEE Std 830-1998
Zaawansowana inżynieria oprogramowania
Pozyskiwanie i dokumentowanie wymagań (18)
1.1 Cel dokumentu
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.
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.
Rola dokumentu specyfikacji wymagań + czytelnicy
Zaawansowana inżynieria oprogramowania
Pozyskiwanie i dokumentowanie wymagań (19)
1.2 Zakres produktu
• Wizja produktu:– Na czym polega problem?– Kogo dotyczy?– Jakie są jego implikacje?– Jaki jest pomysł na jego
rozwiązanie?
•Identyfikacja produktu programistycznego poprzez nazwę.•Co produkt będzie, a czego nie będzie robił.•Zastosowanie specyfikowanego oprogramowania.
•Identyfikacja produktu programistycznego poprzez nazwę.•Co produkt będzie, a czego nie będzie robił.•Zastosowanie specyfikowanego oprogramowania.
Zaawansowana inżynieria oprogramowania
Pozyskiwanie i dokumentowanie wymagań (20)
1.2 Zakres produktu
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.
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.
•Identyfikacja produktu programistycznego poprzez nazwę.•Co produkt będzie, a czego nie będzie robił.•Zastosowanie specyfikowanego oprogramowania.
•Identyfikacja produktu programistycznego poprzez nazwę.•Co produkt będzie, a czego nie będzie robił.•Zastosowanie specyfikowanego oprogramowania.
Zaawansowana inżynieria oprogramowania
Pozyskiwanie i dokumentowanie wymagań (21)
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
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ądkuj alfabetycznieUporządkuj alfabetycznie
Zaawansowana inżynieria oprogramowania
Pozyskiwanie i dokumentowanie wymagań (22)
1.4 Odwołania do literatury
System powinien podawać wartość średnią i odchylenie standardowe [Montgomery97]. 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.
[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.
Zaawansowana inżynieria oprogramowania
Pozyskiwanie i dokumentowanie wymagań (23)
1.5 Omówienie 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.
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.
Omówić organizację pozostałej części dokumentu
Omówić organizację pozostałej części dokumentu
Zaawansowana inżynieria oprogramowania
Pozyskiwanie i dokumentowanie wymagań (24)
Struktura SRS
1. Wprowadzenie2. Ogólny opis produktu
2.1 Kontekst funkcjonowania2.2 Charakterystyka użytkowników2.3 Główne funkcje produktu2.4 Ograniczenia2.5 Założenia i zależności
3. Wymagania funkcjonalne4. Wymagania pozafunkcjonalneDodatkiIndeks
IEEE Std 830-1998
Zaawansowana inżynieria oprogramowania
Pozyskiwanie i dokumentowanie wymagań (25)
2.1 Kontekst funkcjonowania
Omawiany system ma współpracować z systemem PolCard w zakresie płatności elektronicznych. Diagram kontekstu przedstawiono na rys. 1.
Omawiany system ma współpracować z systemem PolCard w zakresie płatności elektronicznych. Diagram kontekstu przedstawiono na rys. 1.
Wzbogacaj język naturalny innymi formami opisu
Wzbogacaj język naturalny innymi formami opisu
Odpowiednio korzystaj z diagramów
Odpowiednio korzystaj z diagramów
Zaawansowana inżynieria oprogramowania
Pozyskiwanie i dokumentowanie wymagań (26)
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.
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.
Zaawansowana inżynieria oprogramowania
Pozyskiwanie i dokumentowanie wymagań (27)
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ą
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ą
Zaawansowana inżynieria oprogramowania
Pozyskiwanie i dokumentowanie wymagań (28)
2.4 Ograniczenia
System musi spełniać wymagania stawiane przez ustawę o ochronie danych osobowych [UstawaOsob]. System musi spełniać wymagania stawiane przez ustawę o ochronie danych osobowych [UstawaOsob].
Zaawansowana inżynieria oprogramowania
Pozyskiwanie i dokumentowanie wymagań (29)
2.5 Założenia i zależności
Prezentowane wymagania dotyczą stanu prawnego na dzień 1 września 2005 roku. Prezentowane wymagania dotyczą stanu prawnego na dzień 1 września 2005 roku.
Zaawansowana inżynieria oprogramowania
Pozyskiwanie i dokumentowanie wymagań (30)
Struktura SRS
1. Wprowadzenie2. Ogólny opis produktu3. Wymagania funkcjonalne 3.1 Interfejsy zewnętrzne 3.2 Funkcje 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 korespondencji4. Wymagania pozafunkcjonalneDodatkiIndeks
IEEE Std 830-1998
Zaawansowana inżynieria oprogramowania
Pozyskiwanie i dokumentowanie wymagań (31)
Struktura SRS
IEEE Std 830-1998
1. Wprowadzenie2. Ogólny opis produktu3. Wymagania funkcjonalne
3.1 Interfejsy zewnętrzne 3.2 Funkcje 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 korespondencji4. Wymagania pozafunkcjonalneDodatkiIndeks
Zaawansowana inżynieria oprogramowania
Pozyskiwanie i dokumentowanie wymagań (32)
Interfejsy zewnętrzne
Zaawansowana inżynieria oprogramowania
Pozyskiwanie i dokumentowanie wymagań (33)
Struktura SRS
1. Wprowadzenie2. Ogólny opis produktu3. Wymagania funkcjonalne 3.1 Opis otoczenia 3.2. Funkcje
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 korespondencji4. Wymagania pozafunkcjonalneDodatkiIndeks
IEEE Std 830-1998
Przypadki użycia!
Przypadki użycia!
Zaawansowana inżynieria oprogramowania
Pozyskiwanie i dokumentowanie wymagań (34)
Struktura SRS
1. Wprowadzenie2. Ogólny opis produktu3. Wymagania funkcjonalne
4. Wymagania pozafunkcjonalne4.1 Użyteczność4.2 Niezawodność4.3 Wydajność4.4 Bezpieczeństwo
DodatkiIndeks
IEEE Std 830-1998
Zaawansowana inżynieria oprogramowania
Pozyskiwanie i dokumentowanie wymagań (35)
Klasyfikacja dobrych praktyk
ObszarPodst.
36Pośred.
21Zaaw.
9
Dokument wymagań 8 - -
Zbieranie wymagań 6 6 1
Analiza i negocjacja wym. 5 2 1
Opisywanie wymagań 4 1 -
Modelowanie systemu 3 3 -
Walidacja wymagań 4 3 1
Zarządzanie wymaganiami 4 3 2
IW dla systemów krytycznych 2 3 4
Zaawansowana inżynieria oprogramowania
Pozyskiwanie i dokumentowanie wymagań (36)
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
Zaawansowana inżynieria oprogramowania
Pozyskiwanie i dokumentowanie wymagań (37)
Klasyfikacja dobrych praktyk
ObszarPodst.
36Pośred.
21Zaaw.
9
Dokument wymagań 8 - -
Zbieranie wymagań 6 6 1
Analiza i negocjacja wym. 5 2 1
Opisywanie wymagań 4 1 -
Modelowanie systemu 3 3 -
Walidacja wymagań 4 3 1
Zarządzanie wymaganiami 4 3 2
IW dla systemów krytycznych 2 3 4
Zaawansowana inżynieria oprogramowania
Pozyskiwanie i dokumentowanie wymagań (38)
Opisywanie wymagań
• Zdefiniuj standardowe szablony dla opisu wymagań
• Pisz prosto i krótko
• Odpowiednio korzystaj z diagramów
• Wzbogacaj język naturalny innymi formami opisu
• Specyfikuj wymagania ilościowo
Zaawansowana inżynieria oprogramowania
Pozyskiwanie i dokumentowanie wymagań (39)
Podsumowanie
• Standard IEEE 830-1998– kryteria dobrej specyfikacji
wymagań– dotyczy dokumentu
specyfikacji wymagań
• Struktura dokumentu
• Dobre praktyki inżynierii wymagań
Zaawansowana inżynieria oprogramowania
Pozyskiwanie i dokumentowanie wymagań (40)
Literatura
• IEEE 830-1998
• Adolph, Bramble, Cockburn, Pols: Patterns for Effective Use Cases
• Sommerville, Sawyer: Requirements Engineering. A Good Practice Guide.