1 [email protected] www.cs.put.poznan.pl/jnawrocki/ioInżynieria oprogramowania II Wykład 7 Inżynieria wymagań

2 11.03 Zasady skutecznego działania Plan wykładów 11.03 Zasady skutecznego działania 18.03 Kontrola jakości oprogramowania 1.04 Szacowanie rozmiaru i pracochłonności 15.04 Standardy serii ISO 9000 29.04 Modele CMMI 29.04 Inżynieria wymagań 6.05 Zarządzanie projektami i PRINCE2 13.05 Personal Software Process 20.05 Team Software Process 3.06 Rational Unified Process 10.06 Zwinne metodyki programowania 17.06 Projekty dyplomowe i XPrince J.Nawrocki, Inżynieria wymagań

3 Model Sommerville’a-Sawyera Praktyki dotyczące dokumentu 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ń

4 Wymagania Plan wykładu Model Sommerville’a-SawyeraPraktyki 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ń

5 Wymaganie .. .. jest to zdolność (capability) lub warunek, który system musi spełnić. J.Nawrocki, Inżynieria wymagań

6 Wymagania .. .. są definiowane na wczesnych etapach rozwoju systemu jako specyfikacja tego, co ma być implementowane. Sommerville & Sawyer’97 J.Nawrocki, Inżynieria wymagań

7 SRS = Software Requirements Specification IEEE Std SRS = Software Requirements Specification SRS jest specyfikacją szczególnego (particular) produktu programistycznego, programu, lub zbioru programów realizującego pewne funkcje w konkretnym (specific) środowisku. J.Nawrocki, Inżynieria wymagań

8 Funkcjonalność (co oprogramowanie ma robić?) Główne problemy IEEE Std Funkcjonalność (co oprogramowanie ma robić?) Zewnętrzne interfejsy (ludzie, sprzęt, inne oprogramowanie) Wydajność (prędkość, dostępność, czas odpowiedzi itp.) Atrybuty (przenośność, pielęgnowalność, bezpiecz. itp. ) Ograniczenia projektowe (standardy, język implementacji, ograniczenia zasobowe, środowisko funkcjonowania itp.) J.Nawrocki, Inżynieria wymagań

9  IEEE Std. 830 Wymagania funkcjonalne Wymagania pozafunkcjonalneSpecyfikacja wymagań Wymagania funkcjonalne Wymagania pozafunkcjonalne Interfejs użytkownika Scenariusze testów akceptacyjnych  IEEE Std. 830 J.Nawrocki, Inżynieria wymagań

10 Środowisko operacyjneUżytkownik ENV1 Urządzenie System zewnętrzny ENV2 System J.Nawrocki, Inżynieria wymagań

11 Środowisko operacyjneUżytkownik System J.Nawrocki, Inżynieria wymagań

12 Nie do nas! Dokładność? Funkcja (Operacja) Wej. Wyj. Efekty uboczneFunkcje systemu Nie do nas! Dokładność? Funkcja (Operacja) STOP Wej. Wyj. 0.1234 Efekty uboczne J.Nawrocki, Inżynieria wymagań

13 WARUNEK: Segregator faktur jest niepusty. Funkcje systemu FUN1: Pobranie faktury WEJŚCIE: - WARUNEK: Segregator faktur jest niepusty. WYJŚCIE: Faktura (wzorzec WF-1/ ) 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ń

14 Model Sommerville’a-SawyeraPlan 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ń

15 Klasyfikacja dobrych praktykPodst. 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, Inżynieria wymagań

16 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 J.Nawrocki, Inżynieria wymagań

17 > 85 Podst & > 40 Pośr. & Zaaw.Poziomy dojrzałości Zdefiniowany > 85 Podst & > 40 Pośr. & Zaaw. Powtarzalny > 55 Podst. & < 40 Pośr. & Zaaw. Początkowy < 55 Podst. J.Nawrocki, Inżynieria wymagań

18 Praktyki dotyczące dokumentuPlan 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ń

19 Klasyfikacja dobrych praktykPodst. 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, Inżynieria wymagań

20  Dokument wymagań Zdefiniuj standardową strukturę dokumentuWyjaś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, Inżynieria wymagań

21 Kryteria jakości dokumentu SRSIEEE Std 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, Inżynieria wymagań

22 Struktura SRS 1. Introduction 1.1 Purpose 1.2 ScopeIEEE Std 1. Introduction 1.1 Purpose 1.2 Scope 1.3 Definitions, acronyms, and abbreviations 1.4 References 1.5 Overview 2. Overall description 2.1 Product perspective 2.2 Product functions 2.3 User characteristics 2.4 Constraints 2.5 Assumptions and dependencies 3. Specific requirements Appendixes Index J.Nawrocki, Inżynieria wymagań

23 3. Specific requirements3.1 External interface requirements 3.1.1 User interfaces 3.1.2 Hardware interfaces 3.1.3 Software interfaces 3.1.4 Communications interfaces 3.2 Functional requirements 3.2.1 User class 1 Functional requirement 1.1 . . . 3.2.1.n Functional requirement 1.n 3.2.m User class m 3.2.m.1 Functional requirement m.1 3.2.m.n Functional requirement m.n IEEE Std J.Nawrocki, Inżynieria wymagań

24 3. Specific requirementsIEEE Std 3.3 Performance requirements 3.4 Design constraints 3.5 Software system attributes 3.6 Other requirements J.Nawrocki, Inżynieria wymagań

25 Przypadki użycia Plan wykładu Wymagania Model Sommerville’a-SawyeraPraktyki 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ń

26 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 J.Nawrocki, Inżynieria wymagań

27 Ivar Jacobson Addison-Wesley, 1992 J.Nawrocki, Inżynieria wymagań

28 Przykładowy przypadek użyciaZarejestruj 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, Inżynieria wymagań

29 Przypadki użycia a scenariuszeTen sam cel Scenario #1 Przypadek użycia Scenario #2 Scenario #3 J.Nawrocki, Inżynieria wymagań

30 Przykładowy przypadek użyciaZarejestruj 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, Inżynieria wymagań

31 Zalety przypadków użyciaSą 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ń

32 Źle napisany przypadek użyciaZapisz się na przedmiot (Główny scen.) Display a blank schedule. Display a list of all classes in the following way: The left window lists all the courses in the system in alphabetical order. The lower window displays the times the highlighted course is available. The third window shows all the courses currently in the schedule. Do. Student clicks on a course. Update the lower window to show the times the course is available. Student clicks on a course time and then clicks on the „Add Course” button. J.Nawrocki, Inżynieria wymagań

33 Źle napisany przypadek użyciaZa dużo szczegółów dot. GUI Display a blank schedule. Display a list of all classes in the following way: The left window lists all the courses in the system in alphabetical order. The lower window displays the times the highlighted course is available. The third window shows all the courses currently in the schedule. Do. Student clicks on a course. Update the lower window to show the times the course is available. Student clicks on a course time and then clicks on the „Add Course” button. J.Nawrocki, Inżynieria wymagań

34 Inne często popełniane błędyZa 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ń

35 Poziomy opisu systemu informatycznegoModelowanie biznesowe UML, BPMN, przypadki użycia, ... Specyfikacja wymagań Język polski, przypadki użycia, ... Projektowanie Pseudokod, schematy blokowe, UML, ... Kodowanie i testowanie Asembler, C, Java, ... J.Nawrocki, Inżynieria wymagań

36 Poziomy przypadków użyciaBook trip Poziom celu Why? Book trip Poziom użytkown. Book flight Book hotel Book trip Book hotel Book flight Find flight Reserve seat Find hotel Reserve room Poziom podfunkcji How? J.Nawrocki, Inżynieria wymagań

37 Krótki format Actor Administrator Use Case Set Monitor ParametersSelect Monitor Description Person monitoring and controlling job control system Allow administrator to specify boundaries and Precision of items being monitored Choose something to monitor (e.g. a process or wait queue) J.Nawrocki, Inżynieria wymagań

38 Pełen format Buy Something Primary Actor: RequestorGoal in Context: Requestor buys something through the system, gets it. Does not include paying for it. Scope: Business – The overall purchasing mechanism, electronic adn non-electronic, as seen by the people in the company. Level: Summary Stakeholders and Interests Requestor: Wants what he/she ordered. Company: Wants to control spending but allow needed purchases. Vendor: Wants to get paid for any goods delivered. Precondition: None J.Nawrocki, Inżynieria wymagań

39 Pełen format Success Guarantees: Requestor has goods, correct budet ready do be debited. Trigger: Requestor decides to buy something. Main Success Scenario Requestor: Initiate a request. Approver: Check money in the budget, check price of goods, complete request for submission. Buyer: Check contents of storage, find best vendor for goods. Authorizer: Validate Approver’s signature. . . . Extensions 1a. Requestor does not know vendor or price: leave those parts blank and continue. J.Nawrocki, Inżynieria wymagań

40 Pełen format Priority: Various Response Time: VariousFrequency: Three times a day Channel to Primary Actor: Internet browser, mail system, or equivalent Channels to Secondary Actors: Fax, phone, car Open Issues: When is a canceled request deleted from the system? What authorization is needed to cancel a request? J.Nawrocki, Inżynieria wymagań

41 Rational Requisite ProPlan 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ń

42 Użytkownicy RequisiteProAutor Admin Obserwator J.Nawrocki, Inżynieria wymagań

43 Rational RequisiteProWymaganie Rational RequisitePro W RequisitePro: Nazwa, tekst, atrybuty J.Nawrocki, Inżynieria wymagań

44 Składniki RequisiteProPaleta Widoki MS Word RequisiteWeb Baza danych J.Nawrocki, Inżynieria wymagań

45 Znacznik Krótki tekst Atrybut Atrybut Pełny tekstMacierz atrybutów Znacznik Krótki tekst Atrybut Atrybut Pełny tekst J.Nawrocki, Inżynieria wymagań

46 Rational RequisitePro Zarządzanie wymaganiami Rational ClearCase LT Rational Suite AnalystStudio Rational RequisitePro Zarządzanie wymaganiami Rational ClearCase LT Zarządzanie wersjami Rational ClearQuest Zarządzanie zmianami Rational Rose SoDA Generowanie raportów J.Nawrocki, Inżynieria wymagań

47 Literatura IEEE Recommended Practice for Software Requirements Specifications, IEEE Std , June 1998. I.Sommerville, P. Sawyer, Requirements Engineering. A Good Practice Guide. John Wiley & Sons, Chichester, 1997.  J.Nawrocki, Inżynieria wymagań

48 Wreszcie! Podsumowanie Wymagania Model Sommerville’a-SawyeraPraktyki dotyczące dokumentu Przypadki użycia Rational Requisite Pro J.Nawrocki, Inżynieria wymagań

49 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, Inżynieria wymagań

50 Modelowanie biznesowePlan wykładu 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 Rola analityka Modelowanie biznesowe J.Nawrocki, Inżynieria wymagań