Download - Inżynieria wymagań
Copyright © Jerzy R. Nawrocki
Inżynieria wymagańInżynieria wymagań
[email protected]/jnawrocki/io
Inżynieria oprogramowania IIWykład 6
J.Nawrocki, Inżynieria wymagań
Plan wykładu
•Wymagania•Model Sommerville’a-Sawyera•Praktyki dotyczące dokumentu•Przypadki użycia•Rational Requisite Pro
•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, Inżynieria wymagań
Plan wykładu
•Wymagania•Model Sommerville’a-Sawyera•Praktyki dotyczące dokumentu•Przypadki użycia•Rational Requisite Pro
•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, Inżynieria wymagań
Wymaganie ..
.. jest to zdolność (capability) lub warunek, który system musi spełnić.
J.Nawrocki, Inżynieria wymagań
Wymagania ..
.. są definiowane na wczesnych etapach rozwoju systemu jako specyfikacja tego, co ma być implementowane.
Sommerville & Sawyer’97
J.Nawrocki, Inżynieria wymagań
SRS
SRSSRS = SSoftware RRequirements SSpecification
SRS jest specyfikacją szczególnego (particular)• produktu programistycznego,• programu,• lub zbioru programówrealizującego pewne funkcje w konkretnym (specific)
środowisku.
IEEE Std 830-1998
J.Nawrocki, Inżynieria wymagań
Główne problemy
FunkcjonalnośćFunkcjonalność (co oprogramowanie ma robić?)
Zewnętrzne interfejsyZewnętrzne interfejsy (ludzie, sprzęt, inne oprogramowanie)
WydajnośćWydajność (prędkość, dostępność, czas odpowiedzi itp.)
AtrybutyAtrybuty (przenośność, pielęgnowalność, bezpiecz. itp. )
Ograniczenia projektoweOgraniczenia projektowe (standardy, język implementacji, ograniczenia zasobowe, środowisko funkcjonowania itp.)
IEEE Std 830-1998
J.Nawrocki, Inżynieria wymagań
Specyfikacja wymagań
Wymagania funkcjonalneWymagania pozafunkcjonalneInterfejs użytkownikaScenariusze testów
akceptacyjnych
J.Nawrocki, Inżynieria wymagań
Środowisko operacyjne
SystemSystemUżytkownik
Użytkownik
ENV1
Urządzenie
Systemzewnętrzny
ENV2
J.Nawrocki, Inżynieria wymagań
Środowisko operacyjne
Użytkownik
SystemSystem
J.Nawrocki, Inżynieria wymagań
Funkcje systemu
STOP
0.1234
Funkcja (Operacja)
Nie do nas! Dokładność?
Efekty uboczne
Wej. Wyj.
J.Nawrocki, Inżynieria wymagań
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, Inżynieria wymagań
Plan wykładu
•Wymagania•Model Sommerville’a-Sawyera•Praktyki dotyczące dokumentu•Przypadki użycia•Rational Requisite Pro
•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, Inżynieria wymagań
Klasyfikacja dobrych praktyk
Dokument SRS
Zbieranie wymagań
Analiza i negocjacja wymag.
Opisywanie wymagań
Modelowanie systemu
Walidacja wymagań
Zarządzanie wymaganiami
IW dla systemów krytycznych
Podst. Pośred. Zaaw.
8
6
54
3
4
4
2
36
-
6
21
3
3
3
3
21
-
1
1-
-
1
2
4
9
J.Nawrocki, Inżynieria wymagań
Punktacja
3 – standaryzacja: udokumentowany standard stosowany i sprawdzany jako część procesu zarządzania jakością;
2 – normalne użycie: szeroko stosowane ale nie obowiązkowe;
1 – od czasu do czasu: stosowane wg upodobań kierownika proj.;
0 – nigdy: nigdy lub prawie nigdy;
3
0
J.Nawrocki, Inżynieria wymagań
Poziomy dojrzałości
Zdefiniowany
> 85 Podst & > 40 Pośr. & Zaaw.
Zdefiniowany
> 85 Podst & > 40 Pośr. & Zaaw.Powtarzalny
> 55 Podst. & < 40 Pośr. & Zaaw.
Powtarzalny
> 55 Podst. & < 40 Pośr. & Zaaw.Początkowy
< 55 Podst.
Początkowy
< 55 Podst.
J.Nawrocki, Inżynieria wymagań
Plan wykładu
•Wymagania•Model Sommerville’a-Sawyera•Praktyki dotyczące dokumentu•Przypadki użycia•Rational Requisite Pro
•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, Inżynieria wymagań
Klasyfikacja dobrych praktyk
Dokument SRS
Zbieranie wymagań
Analiza i negocjacja wymag.
Opisywanie wymagań
Modelowanie systemu
Walidacja wymagań
Zarządzanie wymaganiami
IW dla systemów krytycznych
Podst. Pośred. Zaaw.
8
6
54
3
4
4
2
36
-
6
21
3
3
3
3
21
-
1
1-
-
1
2
4
9
J.Nawrocki, Inżynieria wymagań
Dokument wymagań
Zdefiniuj standardową strukturę dokumentuWyjaśnij, jak korzystać z dokumentuDołącz streszczenie wymagańOpracuj uzasadnienie biznesowe dla systemuZdefiniuj terminy specjalistyczneWybierz czytelny szablon dokumentuPomóż czytelnikom znaleźć informacjęUczyń dokument łatwym do zmiany
J.Nawrocki, Inżynieria wymagań
Kryteria jakości dokumentu SRS
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).
IEEE Std 830-1998
J.Nawrocki, Inżynieria wymagań
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
J.Nawrocki, Inżynieria wymagań
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
J.Nawrocki, Inżynieria wymagań
Struktura SRS
1. Wprowadzenie2. Ogólny opis produktu3. 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 korespondencji4. Wymagania pozafunkcjonalneDodatkiIndeks
IEEE Std 830-1998
J.Nawrocki, Inżynieria wymagań
Plan wykładu
•Wymagania•Model Sommerville’a-Sawyera•Praktyki dotyczące dokumentu•Przypadki użycia•Rational Requisite Pro
•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, Inżynieria wymagań
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.htmlhttp://www.jaczone.com/
J.Nawrocki, Inżynieria wymagań
Ivar Jacobson
Addison-Wesley, 1992
J.Nawrocki, Inżynieria wymagań
Przykładowy przypadek użycia
Zarejestruj IOZarejestruj IOAktorAktor: Rejestrator IOCelCel: Zarejestrować w systemie nową IO.ZdarzenieZdarzenie: Rejestrator otrzymał wniosek papierowy. Główny scenariuszGłówny scenariusz1.1. Rejestrator IORejestrator IO: Wprowadza NIP lub REGON IO.2.2. SystemSystem: Sprawdza poprawność wprowadzonego NIP/REGON.3.3. RejestratorRejestrator: Wprowadza pozostałe dane identyfikacyjne IO.4.4. SystemSystem: Weryfikuje poprawność składniową wprowadzonych
danych.5.5. RejestratorRejestrator: Wprowadza dane dotyczące jednostek IO.RozszerzeniaRozszerzenia2a.2a. NIP/REGON jest niepoprawny 2a1.2a1. System wyświetla komunikat i wracamy do kroku 1
J.Nawrocki, Inżynieria wymagań
Przykładowy przypadek użycia
Zarejestruj IOZarejestruj IOAktorAktor: Rejestrator IOCelCel: Zarejestrować w systemie nową IO.ZdarzenieZdarzenie: Rejestrator otrzymał wniosek papierowy. Główny scenariuszGłówny scenariusz1.1. Rejestrator IORejestrator IO: Wprowadza NIP lub REGON IO.2.2. SystemSystem: Sprawdza poprawność wprowadzonego NIP/REGON.3.3. RejestratorRejestrator: Wprowadza pozostałe dane identyfikacyjne IO.4.4. SystemSystem: Weryfikuje poprawność składniową wprowadzonych
danych.5.5. RejestratorRejestrator: Wprowadza dane dotyczące jednostek IO.RozszerzeniaRozszerzenia2a.2a. NIP/REGON jest niepoprawny 2a1.2a1. System wyświetla komunikat i wracamy do kroku 1
J.Nawrocki, Inżynieria wymagań
Przykładowy przypadek użycia
Zarejestruj IOZarejestruj IOAktorAktor: Rejestrator IOCelCel: Zarejestrować w systemie nową IO.ZdarzenieZdarzenie: Rejestrator otrzymał wniosek papierowy. Główny scenariuszGłówny scenariusz1.1. Rejestrator IORejestrator IO: Wprowadza NIP lub REGON IO.2.2. SystemSystem: Sprawdza poprawność wprowadzonego NIP/REGON.3.3. RejestratorRejestrator: Wprowadza pozostałe dane identyfikacyjne IO.4.4. SystemSystem: Weryfikuje poprawność składniową wprowadzonych
danych.5.5. RejestratorRejestrator: Wprowadza dane dotyczące jednostek IO.RozszerzeniaRozszerzenia2a.2a. NIP/REGON jest niepoprawny 2a1.2a1. System wyświetla komunikat i wracamy do kroku 1
J.Nawrocki, Inżynieria wymagań
Przykładowy przypadek użycia
Zarejestruj IOZarejestruj IOAktorAktor: Rejestrator IOCelCel: Zarejestrować w systemie nową IO.ZdarzenieZdarzenie: Rejestrator otrzymał wniosek papierowy. Główny scenariuszGłówny scenariusz1.1. Rejestrator IORejestrator IO: Wprowadza NIP lub REGON IO.2.2. SystemSystem: Sprawdza poprawność wprowadzonego NIP/REGON.3.3. RejestratorRejestrator: Wprowadza pozostałe dane identyfikacyjne IO.4.4. SystemSystem: Weryfikuje poprawność składniową wprowadzonych
danych.5.5. RejestratorRejestrator: Wprowadza dane dotyczące jednostek IO.RozszerzeniaRozszerzenia2a.2a. NIP/REGON jest niepoprawny 2a1.2a1. System wyświetla komunikat i wracamy do kroku 1
J.Nawrocki, Inżynieria wymagań
Przykładowy przypadek użycia
Zarejestruj IOZarejestruj IOAktorAktor: Rejestrator IOCelCel: Zarejestrować w systemie nową IO.ZdarzenieZdarzenie: Rejestrator otrzymał wniosek papierowy. Główny scenariuszGłówny scenariusz1.1. Rejestrator IORejestrator IO: Wprowadza NIP lub REGON IO.2.2. SystemSystem: Sprawdza poprawność wprowadzonego NIP/REGON.3.3. RejestratorRejestrator: Wprowadza pozostałe dane identyfikacyjne IO.4.4. SystemSystem: Weryfikuje poprawność składniową wprowadzonych
danych.5.5. RejestratorRejestrator: Wprowadza dane dotyczące jednostek IO.RozszerzeniaRozszerzenia2a.2a. NIP/REGON jest niepoprawny 2a1.2a1. System wyświetla komunikat i wracamy do kroku 1
J.Nawrocki, Inżynieria wymagań
Przykładowy przypadek użycia
Zarejestruj IOZarejestruj IOAktorAktor: Rejestrator IOCelCel: Zarejestrować w systemie nową IO.ZdarzenieZdarzenie: Rejestrator otrzymał wniosek papierowy. Główny scenariuszGłówny scenariusz1.1. Rejestrator IORejestrator IO: Wprowadza NIP lub REGON IO.2.2. SystemSystem: Sprawdza poprawność wprowadzonego NIP/REGON.3.3. RejestratorRejestrator: Wprowadza pozostałe dane identyfikacyjne IO.4.4. SystemSystem: Weryfikuje poprawność składniową wprowadzonych
danych.5.5. RejestratorRejestrator: Wprowadza dane dotyczące jednostek IO.RozszerzeniaRozszerzenia2a.2a. NIP/REGON jest niepoprawny 2a1.2a1. System wyświetla komunikat i wracamy do kroku 1
J.Nawrocki, Inżynieria wymagań
Przykładowy przypadek użycia
Zarejestruj IOZarejestruj IOAktorAktor: Rejestrator IOCelCel: Zarejestrować w systemie nową IO.ZdarzenieZdarzenie: Rejestrator otrzymał wniosek papierowy. Główny scenariuszGłówny scenariusz1.1. Rejestrator IORejestrator IO: Wprowadza NIP lub REGON IO.2.2. SystemSystem: Sprawdza poprawność wprowadzonego NIP/REGON.3.3. RejestratorRejestrator: Wprowadza pozostałe dane identyfikacyjne IO.4.4. SystemSystem: Weryfikuje poprawność składniową wprowadzonych
danych.5.5. RejestratorRejestrator: Wprowadza dane dotyczące jednostek IO.RozszerzeniaRozszerzenia2a.2a. NIP/REGON jest niepoprawny 2a1.2a1. System wyświetla komunikat i wracamy do kroku 1
J.Nawrocki, Inżynieria wymagań
Ten sam cel
Przypadki użycia a scenariusze
Scenario #1
Scenario #2
Scenario #3
Przypadek użycia
J.Nawrocki, Inżynieria wymagań
Przykładowy przypadek użycia
Zarejestruj IOZarejestruj IOAktorAktor: Rejestrator IOCelCel: Zarejestrować w systemie nową IO.ZdarzenieZdarzenie: Rejestrator otrzymał wniosek papierowy. Główny scenariuszGłówny scenariusz1.1. Rejestrator IORejestrator IO: Wprowadza NIP lub REGON IO.2.2. SystemSystem: Sprawdza poprawność wprowadzonego NIP/REGON.3.3. RejestratorRejestrator: Wprowadza pozostałe dane identyfikacyjne IO.4.4. SystemSystem: Weryfikuje poprawność składniową wprowadzonych
danych.5.5. RejestratorRejestrator: Wprowadza dane dotyczące jednostek IO.RozszerzeniaRozszerzenia2a.2a. NIP/REGON jest niepoprawny 2a1.2a1. System wyświetla komunikat i wracamy do kroku 1
J.Nawrocki, Inżynieria 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, Inżynieria wymagań
Źle napisany przypadek użycia
Zapisz się na przedmiot (Główny scen.)
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 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ęć.
3. Wykonaj.4. Student klika na przedmiot.5. Aktualizuj dolne okno aby pokazać godziny, w których przedmiot jest
dostępny.6. Student klika na godziny a potem na przycisk „Dodaj przedmiot” .
J.Nawrocki, Inżynieria wymagań
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 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ęć.
3. Wykonaj.4. Student klika na przedmiot.5. Aktualizuj dolne okno aby pokazać godziny, w których przedmiot jest
dostępny.6. Student klika na godziny a potem na przycisk „Dodaj przedmiot” .
Źle napisany przypadek użycia
Za dużo szczegółów dot. GUI
J.Nawrocki, Inżynieria 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, Inżynieria wymagań
Plan wykładu
•Wymagania•Model Sommerville’a-Sawyera•Praktyki dotyczące dokumentu•Przypadki użycia•Rational Requisite Pro
•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, Inżynieria wymagań
Użytkownicy RequisitePro
RequisitePro
Autor
Obserwator Admin
J.Nawrocki, Inżynieria wymagań
Wymaganie
W RequisitePro:Nazwa, tekst, atrybuty
Rational RequisitePro
J.Nawrocki, Inżynieria wymagań
Składniki RequisitePro
Baza danychBaza danych
PaletaPaleta
WidokiWidoki MS MS WordWord
RequisiteWebRequisiteWeb
J.Nawrocki, Inżynieria wymagań
Macierz atrybutów
Znacznik
Pełny tekst
Krótki tekst Atrybut Atrybut
J.Nawrocki, Inżynieria wymagań
Rational Suite
Rational RequisitePro Zarządzanie wymaganiamiRational ClearCase LT Zarządzanie wersjamiRational ClearQuest Zarządzanie zmianamiRational RoseSoDA Generowanie raportów
AnalystStudio
J.Nawrocki, Inżynieria wymagań
Literatura
IEEE Recommended Practice for Software Requirements Specifications, IEEE Std 830-1998, June 1998.
I.Sommerville, P. Sawyer, Requirements Engineering. A Good Practice Guide. John Wiley & Sons, Chichester, 1997.
J.Nawrocki, Inżynieria wymagań
Podsumowanie
•Wymagania•Model Sommerville’a-Sawyera•Praktyki dotyczące dokumentu•Przypadki użycia•Rational Requisite Pro
J.Nawrocki, Inżynieria wymagań
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ć?