Inżynieria wymagań Plan wykładu Inżynieria wymagań i IEEE 80 Jerzy.Nawrocki@put.poznan.pl Adam.Wojciechowski@put.poznan.pl 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 Wymagania Model Sommerville asawyera Praktyki dotyczące dokumentu Przypadki użycia Rational Requisite Pro Copyright Jerzy R. Nawrocki Literatura Wymaganie.. IEEE Recommended Practice for Software Requirements Specifications, IEEE Std 80 998, June 998. I.Sommerville, P. Sawyer, Requirements Engineering. A Good Practice Guide. John Wiley & Sons, Chichester, 997... jest to zdolność (capability) lub warunek, który system musi spełnić. Wymagania.. SRS Sommerville & Sawyer 97.. są definiowane na wczesnych etapach rozwoju systemu jako specyfikacja tego, co ma być implementowane. 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. Wprowadzenie do przedmiotu
Główne problemy Główne problemy 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.) Funkcjonalność + Zewnętrzne interfejsy Ograniczenia projektowe + Wydajność Atrybuty Specyfikacja wymagań Środowisko operacyjne Wymagania funkcjonalne Wymagania pozafunkcjonalne Interfejs użytkownika Scenariusze testów akceptacyjnych ENV Użytkownik System ENV Urządzenie Użytkownik System zewnętrzny Środowisko operacyjne Funkcje systemu Użytkownik System Nie do nas! Dokładność? Funkcja (Operacja) Wej. Wyj. 0. Efekty uboczne Wprowadzenie do przedmiotu
Funkcje systemu Klasyfikacja dobrych praktyk FUN: Pobranie faktury WEJŚCIE: WARUNEK: Segregator faktur jest niepusty. WYJŚCIE: Faktura (wzorzec WF/00.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. Dokument SRS Zbieranie wymagań Analiza i negocjacja wymag. Opisywanie wymagań Modelowanie systemu Walidacja wymagań Zarządzanie wymaganiami IW dla systemów krytycznych Podst. 8 5 Pośred. Zaaw. 9 Punktacja Poziomy dojrzałości 0 standaryzacja: udokumentowany standard stosowany i sprawdzany jako część procesu zarządzania jakością; normalne użycie: szeroko stosowane ale nie obowiązkowe; od czasu do czasu: stosowane wg upodobań kierownika proj.; 0 nigdy: nigdy lub prawie nigdy; Zdefiniowany > 85 Podst & > 0 Pośr. & Zaaw. Powtarzalny > 55 Podst. & < 0 Pośr. & Zaaw. Początkowy < 55 Podst. Klasyfikacja dobrych praktyk Dokument wymagań Dokument SRS Zbieranie wymagań Analiza i negocjacja wymag. Opisywanie wymagań Modelowanie systemu Walidacja wymagań Zarządzanie wymaganiami IW dla systemów krytycznych Podst. 8 5 Pośred. Zaaw. 9 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 Wprowadzenie do przedmiotu
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). Struktura SRS. Introduction. Purpose. Scope. Definitions, acronyms, and abbreviations. References.5 Overview. Overall description. Product perspective. Product functions. User characteristics. Constraints.5 Assumptions and dependencies. Specific requirements Appendixes Index. Specific requirements. Specific requirements. External interface requirements.. User interfaces.. Hardware interfaces.. Software interfaces.. Communications interfaces. Functional requirements.. User class... Functional requirement....n Functional requirement.n..m User class m..m. Functional requirement m...m.n Functional requirement m.n. Performance requirements. Design constraints.5 Software system attributes. Other requirements Przykładowy przypadek użycia Zalety przypadków 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. 5. Rejestrator: Wprowadza dane dotyczące jednostek IO. 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. Wprowadzenie do przedmiotu
Źle napisany przypadek użycia. 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. Zapisz się na przedmiot (Główny scen.) 5. 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. Ź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. 0. End do when the Student clicks on Save Schedule.. Save the schedule and return to the main selection screen. Źle napisany przypadek użycia Inne często popełniane błędy. 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. 5. 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. Za dużo szczegółów dot. GUI Za dużo niskopoziomowych przypadków użycia ( Authorize user ). Stosowanie przypadków użycia do prezentacji informacji niebehawioralnej (np. opis formularzy do dodatków). Za długie (powinny być krótkie, zazwyczaj 9 kroków). Fragmenty zdań (np. pomijanie nazwy aktora w opisie kroków). Poziomy przypadków użycia Krótki format Book trip Poziom celu Actor Description Book trip Book flight Book hotel Poziom użytkown. Administrator Use Case Person monitoring and controlling job control system Description Set Monitor Parameters Allow administrator to specify boundaries and Book trip Book flight Book hotel Reserve Find flight seat Find hotel Reserve room Poziom podfunkcji Select Monitor Precision of items being monitored Choose something to monitor (e.g. a process or wait queue) Wprowadzenie do przedmiotu 5
Pełen format 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 nonelectronic, 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 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 a. Requestor does not know vendor or price: leave those parts blank and continue. Pełen format Użytkownicy RequisitePro 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? Autor RequisitePro Obserwator Admin Wymaganie Składniki RequisitePro Paleta Rational RequisitePro W RequisitePro: Nazwa, tekst, atrybuty Widoki RequisiteWeb MS Word Baza danych Wprowadzenie do przedmiotu
Macierz atrybutów Rational Suite Znacznik Krótki tekst Atrybut Atrybut Pełny tekst AnalystStudio Rational RequisitePro Zarządzanie wymaganiami Rational ClearCase LT Zarządzanie wersjami Rational ClearQuest Zarządzanie zmianami Rational Rose SoDA Generowanie raportów Wprowadzenie do przedmiotu 7