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


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


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


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

ENV1

Urządzenie

Systemzewnętrzny

ENV2


Środowisko operacyjne

Użytkownik

SystemSystem


Funkcje systemu

STOP

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.

8

6

54

3

4

4

2

36

-

6

21

3

3

3

3

21

-

1

1-

-

1

2

4

9


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


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.

8

6

54

3

4

4

2

36

-

6

21

3

3

3

3

21

-

1

1-

-

1

2

4

9


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


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


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

Autor

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