Inżynieria wymagań

Inżynieria wymagańInżynieria wymagań

Jerzy.Nawrocki@put.poznan.plwww.cs.put.poznan.pl/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

Plan wykładu

Wymaganie ..

.. jest to zdolność (capability) lub warunek, który system musi spełnić.

Wymagania ..

.. są definiowane na wczesnych etapach rozwoju systemu jako specyfikacja tego, co ma być implementowane.

Sommerville & Sawyer’97

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

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

Specyfikacja wymagań

Wymagania funkcjonalneWymagania pozafunkcjonalneInterfejs użytkownikaScenariusze testów

akceptacyjnych

Środowisko operacyjne

SystemSystemUżytkownik

Użytkownik

Urządzenie

Systemzewnętrzny

Środowisko operacyjne

Użytkownik

SystemSystem

Funkcje systemu

0.1234

Funkcja (Operacja)

Nie do nas! Dokładność?

Efekty uboczne

Wej. Wyj.

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.

Plan wykładu

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.

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;

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.

Plan wykładu

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.

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

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

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

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

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

Plan wykładu

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/

Ivar Jacobson

Addison-Wesley, 1992

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

Ten sam cel

Przypadki użycia a scenariusze

Scenario #1

Scenario #2

Scenario #3

Przypadek użycia

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.

Ź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” .

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

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).

Plan wykładu

Użytkownicy RequisitePro

RequisitePro

Obserwator Admin

Wymaganie

W RequisitePro:Nazwa, tekst, atrybuty

Rational RequisitePro

Składniki RequisitePro

Baza danychBaza danych

PaletaPaleta

WidokiWidoki MS MS WordWord

RequisiteWebRequisiteWeb

Macierz atrybutów

Znacznik

Pełny tekst

Krótki tekst Atrybut Atrybut

Rational Suite

Rational RequisitePro Zarządzanie wymaganiamiRational ClearCase LT Zarządzanie wersjamiRational ClearQuest Zarządzanie zmianamiRational RoseSoDA Generowanie raportów

AnalystStudio

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.

Podsumowanie

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ć?

Inżynieria wymagań

Documents

Transcript of Inżynieria wymagań

Inżynieria procesowa - J.Ciborowski

Inżynieria oprogramowania (IO) - DMCSneo.dmcs.p.lodz.pl/io5z/io5z_wykl.pdf · Inżynieria systemów komputerowych Inżynieria oprogramowania Inżynieria systemów ... Wymóg działania

INŻYNIERIA OPROGRAMOWANIA [ 1968 ]

Inżynieria Obliczeniowa

Inżynieria oprogramowania - artemis.wszib.edu.plartemis.wszib.edu.pl/~jackolo/pdf/inz_opr_w01.pdf · Semestr IV Inżynieria Oprogramowania WSZiB Inżynieria oprogramowania Grzegorz

GameMakers Inżynieria Oprogramowania

Teoria i inżynieria ruchu teleinformatycznego - ii.pwr.edu.plswiatek/TIRT-W1.pdf · Inżynieria Inżynieria ... sieci i systemów teleinformatycznych, niezbędnych do prawidłowego

Inżynieria Finansowa

Procesy Inżynierii Wymagań

Inżynieria umysłu

Inżynieria wymagań. Wymagania stawiane oprogramowaniu · „Inżynieria wymagań jest relatywnie nowym terminem, ... systemów nie da się osiągnąć ... efektywnościowe dotyczące

Studia I stopnia kierunek INŻYNIERIA ŚRODOWISKA specjalność INŻYNIERIA SANITARNA

inżynieria języka

Inżynieria Polska

STANDARD WYMAGAŃ EGZAMINACYJNYCH

Inżynieria oprogramowaniaartemis.wszib.edu.pl/~jackolo/doc/wyklad/Inzynieria... · 2004-10-31 · Semestr IV Inżynieria Oprogramowania WSZiB Inżynieria oprogramowania ... Semestr

Inżynieria wymagań. Proces inżynierii wymagań · Analiza istniejącego procesu w firmie –gdzie jest problem? ... specyfikacja gry komputerowej może być z kolei scenariuszem

„INŻYNIERIA DROGOWA"

Specjalizacja Inżynieria Medyczna

Inżynieria lingwistyczna