Inżynieria wymagań i IEEE 830

Prezentacja na temat: "Inżynieria wymagań i IEEE 830"— Zapis prezentacji:

1 Inżynieria wymagań i IEEE 830
Inżynieria oprogramowania II Inżynieria wymagań i IEEE 830

2 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ń i IEEE 830

3 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ń i IEEE 830

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

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

6 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ń i IEEE 830

7 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ń i IEEE 830

8 Funkcjonalność + Zewnętrzne interfejsy
Główne problemy IEEE Std Funkcjonalność + Zewnętrzne interfejsy Ograniczenia projektowe + Wydajność Atrybuty J.Nawrocki, Inżynieria wymagań i IEEE 830

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

10 Środowisko operacyjne
Użytkownik ENV1 Urządzenie System zewnętrzny ENV2 System J.Nawrocki, Inżynieria wymagań i IEEE 830

11 Środowisko operacyjne
Użytkownik System J.Nawrocki, Inżynieria wymagań i IEEE 830

12 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, Inżynieria wymagań i IEEE 830

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ń i IEEE 830

14 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, Inżynieria wymagań i IEEE 830

15 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ń i IEEE 830

16 > 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ń i IEEE 830

17 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, Inżynieria wymagań i IEEE 830

18  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, Inżynieria wymagań i IEEE 830

19 Kryteria jakości dokumentu SRS
IEEE 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ń i IEEE 830

20 Struktura SRS 1. Introduction 1.1 Purpose 1.2 Scope
IEEE 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ń i IEEE 830

21 3. Specific requirements
3.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ń i IEEE 830

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

23 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. . . . J.Nawrocki, Inżynieria wymagań i IEEE 830

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

25 Źle napisany przypadek użycia
Zapisz 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ń i IEEE 830

26 Źle napisany przypadek użycia
Zapisz się na przedmiot (Główny scen. – kont.) 7. Check if the Student has the necessary prerequisites and that the course offering is open. 8. If the course is open and the Student has the necessary prerequisites, add the Student to the course. Display the updated schedule showing the new course. If no, put up a message „You are missing the prerequisites. Choose another course.” 9. Mark the course offering as „enrolled” in the schedule. 10. End do when the Student clicks on „Save Schedule.” 11. Save the schedule and return to the main selection screen. J.Nawrocki, Inżynieria wymagań i IEEE 830

27 Źle napisany przypadek użycia
Za 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ń i IEEE 830

28 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ń i IEEE 830

29 Poziomy przypadków użycia
Book 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ń i IEEE 830

30 Krótki format Actor Administrator Use Case Set Monitor Parameters
Select 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ń i IEEE 830

31 Pełen format Buy Something Primary Actor: Requestor
Goal 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ń i IEEE 830

32 Pełen format Success Guarantees: Requestor has goods, correct budget 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ń i IEEE 830

33 Pełen format Priority: Various Response Time: Various
Frequency: 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ń i IEEE 830

34 Użytkownicy RequisitePro
Autor Admin Obserwator J.Nawrocki, Inżynieria wymagań i IEEE 830

35 Rational RequisitePro
Wymaganie Rational RequisitePro W RequisitePro: Nazwa, tekst, atrybuty J.Nawrocki, Inżynieria wymagań i IEEE 830

36 Składniki RequisitePro
Paleta Widoki MS Word RequisiteWeb Baza danych J.Nawrocki, Inżynieria wymagań i IEEE 830

37 Znacznik Krótki tekst Atrybut Atrybut Pełny tekst
Macierz atrybutów Znacznik Krótki tekst Atrybut Atrybut Pełny tekst J.Nawrocki, Inżynieria wymagań i IEEE 830

38 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ń i IEEE 830