Inżynieria oprogramowania, wykład 2, slajd 1

Inżynieria wymagań

dr inż. Grzegorz
Bliźniuk

Inżynieria oprogramowania

wykład 2

Inżynieria oprogramowania, wykład 2, slajd 2

Plan wykładu

1. Wymagania na system informacyjny i informatyczny

2. Rodzaje wymagań

3. Czynności w specyfikacji wymagań

4. Dokumentowanie wymagań

5. Podsumowanie

Bonus: materiały do samodzielnego studiowania

Przygotowane głównie na podstawie wykładu BYT K.Subiety,
matyeriałów D.Pierzchały,materiałów IBM Rational i materiałów
własnych prowadzącego

Inżynieria oprogramowania, wykład 2, slajd 3

1. Określenie wymagań

Określenie wymagań

Projektowanie Implementacja Testowanie Konserwacja

Faza strategiczna

Analiza

Instalacja

Dokumentacja

Celem fazy określenia wymagań jest ustalenie wymagań klienta
wobec tworzonego systemu. Dokonywana jest zamiana celów
klienta na konkretne wymagania zapewniające osiągnięcie tych
celów.

Klient rzadko wie, jakie wymagania zapewnią osiągniecie
jego celów.

Ta faza nie jest więc prostym zbieraniem wymagań, lecz
procesem, w którym klient wspólnie z przedstawicielem
producenta konstruuje zbiór wymagań zgodnie z postawionymi
celami.

W przypadku systemu na zamówienie analitycy mają
bezpośredni kontakt z przedstawicielami klienta. Faza ta
wymaga dużego zaangażowania ze strony klienta, ze strony
przyszłych użytkowników systemu i ekspertów w dziedzinie.

Inżynieria oprogramowania, wykład 2, slajd 4

1. Trudność określenia wymagań

Klient z reguły nie wie dokładnie w jaki sposób osiągnąć
założone cele.
Cele klienta mogą być osiągnięte na wiele sposobów.

Duże systemy są wykorzystywane przez wielu użytkowników.
Ich cele są często sprzeczne. Różni użytkownicy mogą
posługiwać się inną terminologią mówiąc o tych samych
problemach.

Zleceniodawcy i użytkownicy to często inne osoby. Głos
zleceniodawców może być w tej fazie decydujący, chociaż nie
zawsze potrafią oni właściwie przewidzieć potrzeby
przyszłych użytkowników.

Inżynieria oprogramowania, wykład 2, slajd 5

1. Poziomy ogólności opisu wymagań

Definicja wymagań, to ogólny opis w języku naturalnym.
Opis taki jest rezultatem wstępnych rozmów z klientem.

Specyfikacja wymagań, to częściowo ustrukturalizowany
zapis wykorzystujący zarówno język naturalny, jak i proste,
częściowo przynajmniej sformalizowane notacje.

Specyfikacja oprogramowania, to formalny opis wymagań.

Formalna specyfikacja oznacza bardzo dokładne
zdekomponowanie wymagań (najlepiej w pewnym formularzu) na
krótkie punkty, których interpretacja nie powinna nastręczać
trudności lub prowadzić do niejednoznaczności. Formalna
specyfikacja powinna stanowić podstawę dla fazy testowania.

Inżynieria oprogramowania, wykład 2, slajd 6

1. Jakość opisu wymagań

Dobry opis wymagań powinien:

Być kompletny oraz niesprzeczny.

Opisywać zewnętrzne zachowanie się systemu a nie sposób
jego realizacji.

Obejmować ograniczenia przy jakich musi pracować
system.

Być łatwy w modyfikacji.

Brać pod uwagę przyszłe możliwe zmiany wymagań wobec
systemu.

Opisywać zachowanie systemu w niepożądanych lub
skrajnych sytuacjach.

Najbardziej typowy błąd w tej fazie: koncentrowanie się na
sytuacjach typowych i pomijanie wyjątków oraz przypadków
granicznych. Zarówno użytkownicy jak i analitycy mają tendencję
do nie zauważania sytuacji nietypowych lub skrajnych.

Inżynieria oprogramowania, wykład 2, slajd 7

1. Zalecenia dla fazy definicji wymagań

Wymagania użytkowników powinny być wyjaśniane
poprzez

krytykę

porównania

istniejącym

oprogramowaniem i prototypami.

Powinien być uzyskany stan porozumienia pomiędzy
projektantami i użytkownikami dotyczący projektowanego
systemu.

Wiedza i doświadczenia potencjalnej organizacji podejmującej
się rozwoju systemu powinny wspomóc studia nad
osiągalnością systemu.

W wielu przypadkach dużym wspomaganiem jest budowa
prototypów.

Wymagania użytkowników powinny być: jasne, jednoznaczne,
weryfikowalne, kompletne, dokładne, realistyczne,
osiągalne.

Inżynieria oprogramowania, wykład 2, slajd 8

1. Metody rozpoznania wymagań

Wywiady i przeglądy. Wywiady powinny być przygotowane (w
postaci listy pytań) i podzielone na odrębne zagadnienia.
Podział powinien przykrywać całość tematu i powinny być
przeprowadzone na reprezentatywnej grupie użytkowników.
Wywiady powinny doprowadzić do szerokiej zgody i akceptacji
projektu.

Studia na istniejącym oprogramowaniem. Dość często nowe
oprogramowanie zastępuje stare. Studia powinny ustalić
wszystkie dobre i złe strony starego oprogramowania.

Studia wymagań systemowych. Dotyczy sytuacji, kiedy nowy
system ma być częścią większego systemu.

Studia osiągalności. Określenie realistycznych celów systemu
i metod ich osiągnięcia.

Prototypowanie. Zbudowanie prototypu systemu działającego
w zmniejszonej skali, z uproszczonymi interfejsami.

Inżynieria oprogramowania, wykład 2, slajd 9

1. Wymagania funkcjonalne

Opisują funkcje (czynności, operacje) wykonywane przez
system.
Funkcje te mogą być również wykonywane przy użyciu
systemów zewnętrznych.

Określenie wymagań funkcjonalnych obejmuje
następujące kwestie:
Określenie wszystkich rodzajów użytkowników, którzy będą
korzystać z systemu.
Określenie wszystkich rodzajów użytkowników, którzy są
niezbędni do działania systemu (obsługa, wprowadzanie
danych, administracja).
Dla każdego rodzaju użytkownika określenie funkcji systemu
oraz sposobów korzystania z planowanego systemu.
Określenie systemów zewnętrznych (obcych baz danych, sieci,
Internetu), które będą wykorzystywane podczas działania
systemu.
Ustalenie struktur organizacyjnych, przepisów prawnych,
statutów, zarządzeń, instrukcji, itd., które pośrednio lub
bezpośrednio określają funkcje wykonywane przez planowany
system.

Inżynieria oprogramowania, wykład 2, slajd 10

1. Metody specyfikacji wymagań

Język

naturalny

najczęściej

stosowany.

Wady:

niejednoznaczność powodująca różne rozumienie tego samego
tekstu; elastyczność, powodująca wyrazić te same treści na
wiele sposobów. Utrudnia to wykrycie powiązanych wymagań
i powoduje trudności w wykryciu sprzeczności.

Formalizm matematyczny. Stosuje się rzadko (dla
specyficznych celów).

Język

naturalny

strukturalny.

Język

naturalny

ograniczonym słownictwem i składnią. Tematy i zagadnienia
wyspecyfikowane w punktach i podpunktach.

Tablice, formularze. Wyspecyfikowanie wymagań w postaci
(zwykle dwuwymiarowych) tablic, kojarzących różne aspekty
(np. tablica ustalająca zależność pomiędzy typem użytkownika
i rodzajem usługi).

Diagramy blokowe: forma graficzna pokazująca cykl
przetwarzania.

Diagramy kontekstowe: ukazują system w postaci jednego
bloku oraz jego powiązania z otoczeniem, wejściem i
wyjściem.

Diagramy

przypadków

użycia:

poglądowy

sposób

przedstawienia aktorów i funkcji systemu.

Inżynieria oprogramowania, wykład 2, slajd 11

1. Formularz wymagań funkcjonalnych

W formularzach zapis jest podzielony na konkretne pola, co
pozwala na łatwe stwierdzenie kompletności opisu oraz na
jednoznaczną interpretację.

Nazwa funkcji

Opis
Dane
wejściowe

Źródło danych
wejściowych
Wynik
Warunek
wstępny

Warunek
końcowy
Efekty uboczne
Powód

Edycja dochodów pracownika

Funkcja pozwala edytować łączne dochody podatnika uzyskane w
danym roku.
Informacje o dochodach pracowników uzyskane uzyskanych z
różnych źródeł: kwoty przychodów, koszty uzyskania przychodów
oraz zapłaconych zaliczek na poczet podatku dochodowego.
Informacje o dokumentach opisujących dochody z poszczególnych
źródeł.
Dokumenty oraz informacje dostarczone przez podatnika.
Dane wpisywane przez pracownika firmy podatkowej.

Kwota dochodu = kwota przychodu - kwota kosztów (zarówno dla
konkretnych dochodów, jak i dla łącznych dochodów podatnika).
Łączne kwoty przychodów, kosztów uzyskania dochodów oraz
zapłaconych zaliczek są sumami tych kwot dla dochodów z
poszczególnych źródeł.
Jak wyżej.

Uaktualnienie podstawy opodatkowania.
Funkcja pomaga przyśpieszyć obsługę klientów oraz zmniejszyć
ryzyko popełnienia błędów.

Przykład jednej zapełnionej tabeli wg przyjętego formularza:

Inżynieria oprogramowania, wykład 2, slajd 12

1. Porządkowanie wymagań

Hierarchia wymagań funkcjonalnych:
Z reguły funkcje można rozbić na podfunkcje.

Format tekstowy:

Funkcja nadrzędna f1
funkcja f1.1
funkcja f1.2
funkcja f1.3
funkcja f1.3.1
funkcja f1.3.2
funkcja f1.3.3
funkcja f1.4
funkcja f1.4.1
funkcja f1.4.2
funkcja f1.4.3

Notacje graficzne:

funkcja f1

funkcja f1.4.3

funkcja f1.4.2

funkcja f1.4.1

funkcja f1.4

funkcja f1.3.2

funkcja f1.3.3

funkcja f1.3

funkcja f1.1

funkcja f1.2

funkcja f1.3.1

funkcja f1

funkcja f1.3

funkcja f1.1funkcja f1.2

funkcja f1.3.2

funkcja f1.3.3

funkcja f1.3.1

Na każdym poziomie ten sam
poziom szczegółowości.

Kolejność funkcji nie ma
znaczenia.

Niektóre funkcje mogą być
wykonywane wielokrotnie.
Wyszczególniać tylko funkcje
widoczne dla użytkowników.

Inżynieria oprogramowania, wykład 2, slajd 13

1. Zstępujące konstruowanie hierarchii

funkcji

funkcja f1

funkcja f1.4.3

funkcja f1.4.2

funkcja f1.4.1

funkcja f1.4

funkcja f1.3.2

funkcja f1.3.3

funkcja f1.3

funkcja f1.1

funkcja f1.2

funkcja f1.3.1

funkcja f1

funkcja f1.4

funkcja f1.3

funkcja f1.1

funkcja f1.2

funkcja f1

W ten sposób można dekomponować funkcje do
dowolnego poziomu (podejście top-down).

Możliwe jest również podejście odwrotne (bottom-
up), kiedy składamy kilka funkcji bardziej
elementarnych w jedną funkcje bardziej ogólną.
Możliwa jest również technika mieszana.

Inżynieria oprogramowania, wykład 2, slajd 14

1. Przykład: program podatkowy

Program ułatwia przygotowanie formularzy zeznań podatkowych (PIT-
ów) oraz przechowanie informacji o źródłach przychodów i ulg. Zeznanie
może być tworzone przez pojedynczego podatnika lub małżeństwa.
Zeznania mogą obejmować informacje o rocznych przychodach (w
przypadku małżeństwa z podziałem na przychody męża i żony) oraz o
ulgach podatkowych. Przychody podzielone są na klasy ze względu na
źródło uzyskania, np. poza-rolnicza działalność gospodarcza, wolny
zawód,... W ramach danej klasy przychodów podatnik mógł osiągnąć
szereg przychodów z różnych źródeł.

Wszystkie przychody opisane są przez kwotę przychodu, kwotę kosztów,
kwotę zapłaconych zaliczek oraz kwotę dochodu. Powyższe informacje
pozwalają obliczyć należny podatek oraz kwotę do zapłaty lub zwrotu.
Zeznanie zawiera także informację o podatniku oraz adres Urzędu
Skarbowego.

System pozwala wydrukować wzorzec zeznania zawierający wszystkie
informacje, jakie podatnik musi umieścić w formularzu. Zeznanie można
zabezpieczyć przed dalszymi zmianami (po złożeniu w Urzędzie
Skarbowym). System pozwala na tworzenie listy podatników oraz
urzędów skarbowych, które mogą być pomocne przy tworzeniu nowego
zeznania. Przechowuje także informację o wszystkich złożonych
zeznaniach.

„Surowy” wynik wywiadów z klientem:

Inżynieria oprogramowania, wykład 2, slajd 15

1. Program podatkowy: hierarchia

funkcji

Ewidencja podatników

Wydruk zeznania

Wyświetlanie rozliczenia

Edycja informacji o ulgach

Edycja informacji o przychodach

Usuwanie zeznania

Zabezpieczanie zeznania

Ewidencja Urzędów Skarbowych

Ewidencja zeznań podatkowych

Dodawanie zeznania

Edycja zeznania

Wyświetlenie rozliczenia (kopia)

Wydruk zeznania (kopia)

Przeglądanie zeznania (bez możliwości zmiany dla zeznań zabezpieczonych)

Inżynieria oprogramowania, wykład 2, slajd 16

1. Przykład: system

harmonogramowania zleceń

Zlecenia dla wydziału przygotowywane są przez dział marketingu.
Zlecenie oznacza konieczność wyprodukowania konkretnej ilości pewnego
wyrobu przed upływem konkretnego terminu. Czasami może być
określony najwcześniejszy pożądany termin realizacji. Dział marketingu
wykorzystuje własny system informatyczny, w którym między innymi
umieszczane są informacje o zleceniach, pożądane jest więc, aby system
harmonogramowania zleceń automatycznie odczytywał te informacje.

Wyprodukowanie danego wyrobu (realizacja zlecenia) wymaga wykonania
ciągu operacji. Pewne operacje mogą być wykonywane tylko na jednym
urządzeniu; w innych przypadkach możliwe jest wykorzystanie kilku
maszyn, które mogą różnić się efektywnością pracy. Po wykonaniu
pewnych operacji może być konieczna przerwa, zanim rozpocznie się
realizacja następnych; z drugiej strony taka przerwa może trwać przez
ograniczony czas. Przestawienie maszyn na inne operacje może wymagać
czasu. Co pewien czas (np. raz na miesiąc) ustalany jest harmonogram
niezrealizowanych zleceń.

System powinien opracować harmonogramy w formie łatwej do
wykorzystania przez kadrę kierowniczą wydziału oraz przygotowywać
zamówienia do magazynu na półprodukty. Zlecenia wykonane są usuwane
ze zbioru niezrealizowanych zleceń.

„Surowy” wynik wywiadów z klientem:

Inżynieria oprogramowania, wykład 2, slajd 17

1. System harmonogramowania zleceń:

funkcje

Zarządzanie zleceniami (ogólna funkcja systemu)

Ewidencja zleceń

Edycja technologicznego opisu wydziału

Harmonogramowanie zleceń

Wczytywanie
informacji o zleceniach

Wydruk
informacji o zleceniach

Wyświetlanie
informacji o zleceniach

Edycja opisu maszyn

Sprawdzanie
kompletności opisu

Wydruk informacji
technologicznych

Edycja opisu operacji

Edycja opisu wyrobów

Ustalanie harmonogramu

Edycja harmonogramu

Graficzna prezentacja
harmonogramu

Wydruk harmonogramu

Przygotowanie kart zadań

Przygotowanie zamówień na półprodukty

Inżynieria oprogramowania, wykład 2, slajd 18

1. UML - Diagramy przypadków użycia

Opis funkcji systemu z punktu widzenia jego użytkowników.
Opis wymagań poszczególnych użytkowników jest prostszy
niż opis wszystkich wymagań wobec systemu.

Klasy użytkowników:

• sekretarka

• projektant

• osoba przeglądająca mapę

Identyfikacja funkcji dla poszczególnych użytkowników.
Przeprowadzając wywiad z konkretna osobą należy koncentrować
się na funkcjach istotnych z punktu widzenia roli (ról)
odgrywanych przez tę osobę.

Metoda przypadków użycia nie jest sprzeczna z hierarchiczną
dekompozycją funkcji.

Metoda modeluje aktorów, a nie konkretne osoby. Jedna osoba
może pełnić rolę wielu aktorów; np. być jednocześnie
projektantem i osobą przeglądającą mapę.
I odwrotnie, jeden aktor może odpowiadać wielu osobom, np.
sekretarka.

Inżynieria oprogramowania, wykład 2, slajd 19

1. Przykład: system informacji

geograficznej - SIG

SIG jest rodzajem mapy
komputerowej, składającej się z
tła (np. mapy fizycznej) oraz
szeregu obiektów graficznych
umieszczonych na tym tle.

Obiekt może być punktem
(budynek, firma), linią (rzeka,
kolej) lub obszarem (park,
osiedle).

Każdy obiekt ma swoją nazwę i
ewentualny opis, który może być
wyświetlony na żądanie
użytkownika. Obiekt można
opisać szeregiem słów
kluczowych.

Użytkownik ma możliwość
wyświetlenia tylko tych
obiektów, które opisano słowami
kluczowymi.

Zarządzanie SIG (ogólna funkcja systemu)

Przeglądanie SIG

Projektowanie SIG

Edycja słów kluczowych)

Przeglądanie SIG (kopia)

Wyświetlenie opisu obiektu graficznego

Wybór/pomijanie słów kluczowych

Wyświetlanie mapy (różnych obszarów
w różnym powiększeniu)

Dodawanie obiektu

Edycja obiektów graficznych

Edycja tła

Edycja obiektu

Usuwanie obiektu

Dodawanie słowa kluczowego

Edycja słowa kluczowego

Usuwanie słowa kluczowego

Inżynieria oprogramowania, wykład 2, slajd 20

1. Diagram przypadków użycia dla SIG

użytkownik

Wyświetlenie

mapy

Wybór/pomijanie

słów kluczowych

Wyświetlenie opisu

obiektu graficznego

projektant

Edycja

tła

Edycja

obiektu

Dodawanie

obiektu

Edycja obiektów

graficznych

Usuwanie

obiektu

Edycja słów

kluczowych

Edycja

słowa kluczowego

Dodawanie

słowa kluczowego

Usuwanie

słowa kluczowego

uses

Inżynieria oprogramowania, wykład 2, slajd 21

1. Zarządzanie przypadkami użycia

Use Case

Dokument

Brief Description:
The description should briefl y convey the role and
purpose of the use case. A single paragraph should
suffi ce for this description.

Flow of Events:

This use case starts when the actor
does something. An actor always
initiates use Cases. The use case
should describe what the actor does
and what the system does in response.
It should be phrased in the form of a
dialog between the actor and the
system.

The use case should describe what
happens inside the system, but not
how or why. If information is
exchanged, be specific about what is
passed back and forth. For example, it
is not very illuminating to say that the
Actor enters customer information; it is
better to say the Actor enters the
customer’s name and address. A
Glossary of Terms is often useful to
keep the complexity of the use case
manageable; you may want to define
things like customer information there,
to keep the use case from drowning in
details.

Simple alternatives may be presented
within the text of the use case. If it
only takes a few

Zależności

This is use case 1.

This is test case 1.

This is test case 2.

This is test case 3.

This is test case 4.

This is test case 5.

Scenario 16

Aktywności

Start

Stop

Atrybuty

Traceability

History

Attributes

Status

Priority

Release

Assignment

Risk

Architecture

Sekwencje

Diagram

Class 123

Class 1003

Class Arnold

Inżynieria oprogramowania, wykład 2, slajd 22

Zarządzanie wymaganiami - narzędzie IBM Rational Rose

Use Case

Dokument

Brief Description:
The description should briefl y convey the role and
purpose of the use case. A single paragraph should
suffi ce for this description.

Flow of Events:

Simple alternatives may be presented
within the text of the use case. If it
only takes a few

Zależności

This is use case 1.

This is test case 1.

This is test case 2.

This is test case 3.

This is test case 4.

This is test case 5.

Scenario 16

Aktywności

Start

Stop

Atrybuty

Traceability

History

Attributes

Status

Priority

Release

Assignment

Risk

Architecture

Diagram

Class 123

Class 1003

Class Arnold

Sekwencje

Rational Rose

Inżynieria oprogramowania, wykład 2, slajd 23

Zarządzanie wymaganiami - narzędzie IBM Rational RequisitePro

Use Case

Dokument

Brief Description:
The description should briefl y convey the role and
purpose of the use case. A single paragraph should
suffi ce for this description.

Flow of Events:

Simple alternatives may be presented
within the text of the use case. If it
only takes a few

Zależności

This is use case 1.

This is test case 1.

This is test case 2.

This is test case 3.

This is test case 4.

This is test case 5.

Scenario 16

Sekwencje

Start

Stop

Atrybuty

Traceability

History

Attributes

Status

Priority

Release

Assignment

Risk

Architecture

Diagram

Class 123

Class 1003

Class Arnold

Aktywności

Rational RequisitePro

Inżynieria oprogramowania, wykład 2, slajd 24

1. Wymagania niefunkcjonalne

Opisują ograniczenia, przy których system ma realizować swoje funkcje.

Wymagania dotyczące produktu.

Np. musi istnieć możliwość operowania z systemem wyłącznie
za pomocą klawiatury.

Wymagania dotyczące procesu.

Np. proces realizacji harmonogramowania zleceń musi być
zgodny ze standardem opisanym w dokumencie XXXA/96.

Wymagania zewnętrzne.

Np. system harmonogramowania musi współpracować z bazą
danych systemu komputerowego działu marketingu opisaną w
dokumencie YYYB/95. Niedopuszczalne są jakiekolwiek
zmiany w strukturze tej bazy.

Inżynieria oprogramowania, wykład 2, slajd 25

1. Formularz zapisu wymagań

Wymaganie

System powinien
zwracać wynik
zapytania po max 5-ciu
sekundach przy 100
użytkownikach
pracujących
jednocześnie.

Każdy klient powinien
mieć przypisany krótki
numer identyfikacyjny

.....

Data
wprow
.

99/04/
14

00/02/
05

.....

Motywacja

Inaczej system
nie będzie
konkurencyjny
na rynku

Inne
identyfikatory
(nazwisko,
PESEL, numer
telefonu) są
niestabilne, nie
unikalne, lub za
długie

....

Rozmówca

A.Nowak
J.Pietrzak

K.Lubicz

.....

Uwagi

Może być
niestabilne

.....

Inżynieria oprogramowania, wykład 2, slajd 26

1. Weryfikowalność wymagań

niefunkcjonalnych

Cecha
Wydajność

Rozmiar

Łatwość
użytkowania
Niezawodność

Przenaszalnoś
ć

Weryfikowalne miary
Liczba transakcji obsłużonych w ciągu sekundy
Czas odpowiedzi
Liczba rekordów w bazie danych
Wymagana pamięć dyskowa
Czas niezbędny dla przeszkolenia użytkowników
Rozmiar dokumentacji
Prawdopodobieństwo błędu podczas realizacji
transakcji
Średni czas pomiędzy błędnymi wykonaniami
Dostępność (procent czasu w którym system jest
dostępny)
Czas restartu po awarii systemu
Prawdopodobieństwo zniszczenia danych w przypadku
awarii
Procent kodu zależnego od platformy docelowej
Liczba platform docelowych
Koszt przeniesienia na nową platformę

Wymagania niefunkcjonalne powinny być weryfikowalne - czyli
powinna istnieć możliwość sprawdzenia lub zmierzenia czy system
je rzeczywiście spełnia.
Np. wymagania “system ma być łatwy w obsłudze”, „system ma
być niezawodny”, „system ma być dostatecznie szybki”, itd. nie są
weryfikowalne.

Inżynieria oprogramowania, wykład 2, slajd 27

1. Czynniki uwzględniane przy konstruowaniu

wymagań niefunkcjonalnych (1)

Możliwości systemu: Zestaw funkcji, które ma wykonywać
system, uporządkowany hierarchicznie.

Objętość: Ilu użytkowników będzie pracować jednocześnie?
Ile terminali ma być podłączone do systemu? Ile czujników
będzie kontrolowanych jednocześnie? Ile danych będzie
przechowywane?

Szybkość: Jak długo może trwać operacja lub sekwencja
operacji? Liczba operacji na jednostkę czasu. Średni czas
niezbędny dla jednej operacji.

Dokładność: Określenie stopnia precyzji pomiarów lub
przetwarzania. Określenie wymaganej dokładności wyników.
Zastąpienie wyników ilościowych jakościowymi lub
odwrotnie.

Ograniczenia: ograniczenia na interfejsy, jakość, skalę
czasową, sprzęt, oprogramowanie, skalowalność, itd.

Inżynieria oprogramowania, wykład 2, slajd 28

1. Czynniki uwzględniane przy konstruowaniu

wymagań niefunkcjonalnych (2)

Interfejsy komunikacyjne: sieć, protokoły, wydajność sieci,
poziom abstrakcji protokołów komunikacyjnych, itd.

Interfejsy sprzętowe: specyfikacja wszystkich elementów
sprzętowych, które będą składały się na system, fizyczne
ograniczenia (rozmiar, waga), wydajność (szybkość, RAM, dysk,
inne pamięci), wymagania co do powierzchni lokalowych,
wilgotności, temperatury i ciśnienia, itd.

Interfejsy oprogramowania: Określenie zgodności z innym
oprogramowaniem, określenie systemów operacyjnych,
języków programowania, kompilatorów, edytorów, systemów
zarządzania bazą danych, itd.

Interakcja człowiek-maszyna: Wszystkie aspekty interfejsu
użytkownika, rodzaj języka interakcji, rodzaj sprzętu (monitor,
mysz, klawiatura), określenie formatów (układu raportów i ich
zawartości), określenie komunikatów dla użytkowników (język,
forma), pomocy, komunikatów o błędach, itd.

Inżynieria oprogramowania, wykład 2, slajd 29

1. Czynniki uwzględniane przy konstruowaniu

wymagań niefunkcjonalnych (3)

Adaptowalność: Określenie w jaki sposób będzie
organizowana reakcja na zmiany wymagań: dodanie nowej
komendy, dodanie nowego okna interakcji, itd.

Bezpieczeństwo: założenia co do poufności, prywatności,
integralności, odporności na hakerów, wirusy, wandalizm,
sabotaż, itd.

Odporność na awarie: konsekwencje błędów w
oprogramowaniu, przerwy w zasilaniu, kopie zabezpieczające,
częstotliwości składowania, dziennika zmian, itd.

Standardy: Określenie dokumentów standardyzacyjnych, które
mają zastosowanie do systemu: formaty plików, normy
czcionek, polonizacja, standardy procesów i produktów, itd.

Zasoby: Określenie ograniczeń finansowych, ludzkich i
materiałowych.

Skala czasowa: ograniczenia na czas wykonania systemu, czas
szkolenia, wdrażania, itd.

Interoperacyjność – reguły współpracy systemy z innymi
systemami, o ile występuje taka konieczność

Inżynieria oprogramowania, wykład 2, slajd 30

1. Dokument wymagań

Wymagania powinny być zebrane w dokumencie - opisie
wymagań.

Dokument ten powinien być podstawą szczegółowego
kontraktu między klientem a producentem oprogramowania.

Powinien także pozwalać na weryfikację stwierdzającą, czy
wykonany system rzeczywiście spełnia postawione wymagania.

Powinien to być dokument zrozumiały dla obydwu stron.

Często producenci nie są zainteresowaniu w precyzyjnym
formułowaniu wymagań, które pozwoliłoby na rzeczywistą
weryfikację powstałego systemu.
Tego rodzaju polityka lub niedbałość może prowadzić do
konfliktów.

Inżynieria oprogramowania, wykład 2, slajd 31

1. Zawartość dokumentu specyfikacji

wymagań (1)

Streszczenie (maksymalnie 200 słów)
Spis treści
Status dokumentu (autorzy, firmy, daty, podpisy,
itd.)
Zmiany w stosunku do wersji poprzedniej

Informacje

organizacyjne

1. Wstęp
1.1. Cel
1.2. Zakres
1.3. Definicje, akronimy i skróty
1.4. Referencje, odsyłacze do innych dokumentów
1.5. Krótki przegląd
2. Ogólny opis
2.1. Walory użytkowe i przydatność projektowanego systemu
2.2. Ogólne możliwości projektowanego systemu
2.3. Ogólne ograniczenia
2.4. Charakterystyka użytkowników
2.5. Środowisko operacyjne
2.6. Założenia i zależności
3. Specyficzne wymagania
3.1. Wymagania funkcjonalne (funkcje systemu)
3.2. Wymagania niefunkcjonalne (ograniczenia).
Dodatki

Zasadnicza

zawartość

dokumentu

Norma
ANSI/IEEE Std 830-
1993
„Recommended
Practice for Software
Requirements
Specifications”

Inżynieria oprogramowania, wykład 2, slajd 32

1. Zawartość dokumentu specyfikacji

wymagań(2)

Wymagania sprzętowe.
Wymagania dotyczące bazy danych.
Model (architektura) systemu.
Słownik terminów (użyte terminy, akronimy i skróty z
wyjaśnieniem)
Indeks pomocny w wyszukiwaniu w dokumencie konkretnych
informacji (dla dokumentów dłuższych niż 80 stron)

Kolejność i numeracja punktów w przedstawionym spisie treści
powinna być zachowana. W przypadku gdy pewien punkt nie
zawiera żadnej informacji należy wyraźnie to zasygnalizować
przez umieszczenie napisu „Nie dotyczy”.
Dla każdego wymagania powinien być podany powód jego
wprowadzenia: cele przedsięwzięcia, których osiągnięcie jest
uwarunkowane danym wymaganiem.
Wszelki materiał nie mieszczący się w podanych punktach
należy umieszczać w dodatkach.

Często spotykane dodatki

Inżynieria oprogramowania, wykład 2, slajd 33

1. Jakość dokumentu wymagań

Styl

Jasność: jednoznaczne sformułowania, zrozumiały dla
użytkowników i projektantów. Strukturalna organizacja
dokumentu.
Spójność: brak konfliktów w wymaganiach.
Modyfikowalność: wszystkie wymagania są sformułowane w
jasnych punktach, które mogą być wyizolowane z kontekstu i
zastąpione przez inne.

Ewolucja

Możliwość dodawania nowych wymagań, możliwość ich modyfikacji

Odpowiedzialność

Określenie kto jest odpowiedzialny za całość dokumentu
wymagań.
Określenie kto lub co jest przyczyną sformułowania danego
wymagania, istotne w przypadku modyfikacji, np. zmiany
zakresu lub kontekstu systemu.

Medium

Dokument papierowy lub elektroniczny.
Staranne kontrolowanie wersji dokumentu.

Inżynieria oprogramowania, wykład 2, slajd 34

1. Słownik w dokumentacji wymagań

Opis wymagań może zawierać terminy niezrozumiałe dla jednej ze
stron. Mogą to być terminy informatyczne (niezrozumiałe dla
klienta) lub terminy dotyczące dziedziny zastosowań
(niezrozumiałe dla przedstawicieli producenta).

Wszystkie specyficzne terminy powinny być umieszczone w
słowniku, wraz z wyjaśnieniem. Słownik powinien precyzować
terminy niejednoznaczne i określać ich znaczenie w kontekście
tego dokument (być może nieco węższe).

Termin

konto

konto
bankowe
klient

użytkowni
k

Objaśnienie

Nazwana ograniczona przestrzeń dyskowa, gdzie
użytkownik może przechowywać swoje dane. Konta są
powiązane z określonymi usługami, np. pocztą
komputerową oraz z prawami dostępu.
Sekwencja cyfr oddzielona myślnikami, identyfikująca
stan zasobów finansowych oraz operacji dla
pojedynczego klienta banku.
Jednostka sprzętowa instalowana w biurach urzędu,
poprzez którą następuje interakcja użytkownika
końcowego z systemem.
Osoba używająca systemu dla własnych celów
biznesowych nie związanych z obsługą lub administracją
systemu.

Synonimy
(nie
zalecane)
katalog
użytkownik
a

konto

stacja
robocza

klient

Inżynieria oprogramowania, wykład 2, slajd 35

5. Podsumowanie

dziękuję za uwagę

Jakość etapu definiowania i dokumentowania fazy
wymagań

jest

kluczowa

dla

skuteczności

późniejszych

etapów

wytwarzania

oprogramowania. Działa bowiem zjawisko opisane
„piramidą propagacji błędów”:

Pielęgnacja

Implementacja

Projekt

Analiza

Wymagan

t k

ię

bł

ęd

ów

Inżynieria oprogramowania, wykład 2, slajd 36

Do samodzielnego studiowania

Kolejne slajdy są przeznaczone do

samodzielnego studiowania. Stanowią one

uzupełnienie i powtórzenie niektórych

partii materiału z wykładu

Inżynieria oprogramowania, wykład 2, slajd 37

Proces tworzenia oprogramowania



Zasadnicze czynności wspólne dla wszystkich procesów:

–

Specyfikowanie oprogramowania

Funkcjonalność oprogramowania i ograniczenia jego
działania muszą być zdefiniowane;

– Projektowanie i implementowanie oprogramowania

» Oprogramowanie, które spełnia specyfikację, musi być

stworzone;

– Zatwierdzenie oprogramowania

» Wytworzone oprogramowanie musi spełniać oczekiwania

klienta;

– Ewolucja oprogramowania

» Oprogramowanie musi ewoluować, aby spełniać

zmieniające się potrzeby użytkowników;

Inżynieria oprogramowania, wykład 2, slajd 38

Inżynieria wymagań

Wymagania użytkownika

Wymagania systemowe

Wymagania funkcjonalne i niefunkcjonalne

Dokumentacja wymagań stawianych oprogramowaniu

Inżynieria oprogramowania, wykład 2, slajd 39

Inżynieria wymagań



Budowę systemu należy zacząć od wyraźnego

określenia:

– celu, jaki ma zostać osiągnięty,
– użytkowników z podziałem na role,
– zakresu wsparcia uzyskanego w wyniku wdrożenia

systemu;



Zakres systemu określa się poprzez wymagania;



Wymagania należy formułować z punktu widzenia

wszystkich zidentyfikowanych użytkowników;



Użytkownikami są

– fizyczne osoby,
– inne systemy informatyczne komunikujące się z

projektowanym systemem;

Inżynieria oprogramowania, wykład 2, slajd 40

Inżynieria wymagań



Pojęcie wymaganie nie jest jednoznaczne:

– Może być postrzegane jako:

abstrakcyjne określenie usług, które system powinien

oferować, albo ograniczenie działania systemu;

– Może być też:

szczegółową, matematycznie formalną definicją funkcji

systemu;



Proces inżynierii wymagań to:

– wynajdowanie,
– analizowanie,
– specyfikowanie i dokumentowanie,
– sprawdzania usług i ograniczeń.



Czynność ta powinna doprowadzić do stworzenia

dokumentu zwanego Specyfikacją Wymagań

Systemowych (SWS);

Inżynieria oprogramowania, wykład 2, slajd 41

Inżynieria wymagań



Podczas wytwarzania systemu niezbędne jest

duże zaangażowania ze strony:

– klienta,

– przyszłych użytkowników systemu,

– ekspertów w dziedzinie.



Celem fazy określenia wymagań jest

ustalenie wymagań klienta wobec

tworzonego systemu;



Klient wspólnie z przedstawicielem

producenta konstruuje zbiór wymagań

zgodnie z postawionymi celami;



Dokonywana jest zamiana celów klienta

na konkretne wymagania zapewniające

osiągnięcie tych celów;



System nie może być dla klienta

niespodzianką w rodzaju „króliczka z

kapelusza”;

Inżynieria oprogramowania, wykład 2, slajd 42

Pożądane cechy opisu wymagań



Kompletność,



Niesprzeczność,



Weryfikowalność,



Realizowalność,



Ponadto:

– Opisywanie zewnętrznego zachowania systemu z

pominięciem sposobu jego realizacji,

– Obejmowanie ograniczeń, przy jakich musi pracować system,
– Łatwość modyfikacji,
– Zapewnienie możliwości zmiany wymagań w kolejnych

etapach,

– Ujęcie zachowania systemu w niepożądanych lub skrajnych

sytuacjach (brzegowych);

Inżynieria oprogramowania, wykład 2, slajd 43

Typy wymagań – ewolucja wymagań



Wymagania użytkownika



Wymagania systemowe



Specyfikacja projektu oprogramowania

– abstrakcyjny opis projektu oprogramowania,

który jest podstawą dla bardziej
szczegółowego projektu i implementacji;

Inżynieria oprogramowania, wykład 2, slajd 44

Odbiorcy wymagań

Wymagania

użytkownika

Wymagania

systemowe

Specyfikacja

oprogramowania

Menedżerowie klienta
Użytkownicy systemu
Inżynierowie klienta
Menedżerowie zleceniobiorcy
Architekci systemu

Użytkownicy systemu
Inżynierowie klienta
Architekci systemu
Twórcy oprogramowania

Inżynierowie klienta (jeśli są)
Architekci systemu
Twórcy oprogramowania

Typ wymagania

Typ odbiorcy

Inżynieria oprogramowania, wykład 2, slajd 45

Wymagania użytkownika



Wymagania użytkownika są przeznaczone dla
osób, które mają używać i zaopatrywać się w
system.



Powinny być zrozumiałe dla użytkowników
systemu, którzy nie mają szczegółowej wiedzy
technicznej;



Należy spisać je za pomocą języka naturalnego,
tabel i diagramów tak, aby były zrozumiałe dla
osób bez wiedzy inżynierskiej;



Mówią o usługach oczekiwanych od systemu oraz
o ograniczeniach, w których system ma działać;

Inżynieria oprogramowania, wykład 2, slajd 46

Wymagania użytkownika



Przykład: wymaganie stawiane bazie
danych



4.A.5 Baza danych powinna wspomagać
generowanie obiektów sterujących i
konfiguracyjnych, tzn. obiektów, które same
są grupami innych obiektów bazy danych.
Udogodnienia do sterowania konfiguracją
powinny umożliwiać dostęp do obiektów w
pewnej wersji grupy za pomocą niepełnej
nazwy.

Inżynieria oprogramowania, wykład 2, slajd 47

Wymagania użytkownika



Przykład: wymaganie użytkownika wobec edytora



2.6 Udogodnienia siatki. Przez opcje panelu
sterowania użytkownik może:

– uaktywnić siatkę w centymetrach lub w calach, która

będzie pomagała w umieszczaniu bytów na diagramie.
Siatka może być włączona i wyłączona w dowolnej
chwili sesji edycji; to samo dotyczy przełączania między
calami i centymetrami.
Opcja siatki będzie dostępna w widoku „zmniejsz, aby
dopasować”, ale liczba linii siatki będzie wówczas
zmniejszona, aby uniknąć zapełnienia małego diagramu
liniami siatki.

Inżynieria oprogramowania, wykład 2, slajd 48

Wymagania użytkownika



Problemy formułowania wymagań:

– Jeśli wymagania użytkownika zawierają zbyt

wiele informacji, to ograniczają wolność twórców

systemu w wyborze innowacyjnych rozwiązań

oraz utrudniają zrozumienie wymagań.

– Uzasadnienia związane z wymaganiami są

istotne. Pomagają wytwórcom i konserwatorom

systemu w zrozumieniu, dlaczego takie

wymaganie się pojawiło, i w ocenie wpływu

zmiany tego wymagania.

– Szczegóły implementacyjne nie powinny pojawić

się bez informacji dotyczących działania części

systemu.

Inżynieria oprogramowania, wykład 2, slajd 49

Wymagania użytkownika



Porady dla formułujących wymagania
użytkownika:

– Opracuj standardowy format;
– Zapisz wszystkie wymagania zgodnie z

formatem;

– Konsekwentnie używaj pojęć językowych;
– Unikaj żargonu komputerowego;
– Rozróżniaj wymagania obowiązkowe od

wskazanych;

– Stosuj wyróżnienia (np. pogrubienia, kursywy)

do zaznaczania głównych części wymagania;

Inżynieria oprogramowania, wykład 2, slajd 50

Wymagania systemowe



Wymagania systemowe są szczegółowymi opisami

wymagań użytkownika, tzn. szczegółowo ustalają

usługi systemu i ograniczenia.



Są traktowane przez inżynierów oprogramowania

jako punkt wyjścia do projektowania systemu -

mogą być podstawą kontraktu na implementacje

systemu.



Powinny być pełną i niesprzeczną specyfikacją

całego systemu.



Aby uniknąć niejednoznaczności, można je zapisać

za pomocą jakiegoś języka strukturalnego.



Specyfikacja tych wymagań może zawierać różne

modele systemu.

Inżynieria oprogramowania, wykład 2, slajd 51

Wymagania użytkownika i systemowe -

przykład



Wymagania użytkownika:

– oprogramowanie musi zapewniać mechanizmy reprezentowania i

dostępu do plików zewnętrznych tworzonych przez inne narzędzia.



Dla tego wymagania sformułowano kilka systemowych:

– 1.1 Użytkownik powinien mieć możliwość definiowania typów plików

zewnętrznych.

– 1.2 Każdy typ pliku zewnętrznego może mieć przypisane narzędzie do

obróbki takich plików.

– 1.3 Każdy typ pliku zewnętrznego może być przedstawiony w postaci

charakterystycznej ikony na ekranie użytkownika.

– 1.4 Należy zapewnić udogodnienia do definiowania przez użytkownika

ikon odpowiadających typom plików zewnętrznych.

– 1.5 Gdy użytkownik wybierze ikonę powiązaną z plikiem zewnętrznym,

następuje zastosowanie do tego pliku narzędzia skojarzonego z typem
tego pliku.

Inżynieria oprogramowania, wykład 2, slajd 52

Trudności w określeniu wymagań



Klient z reguły nie wie dokładnie, w jaki sposób osiągnąć

założone cele.



Cele klienta mogą być osiągnięte na wiele sposobów.



Duże systemy są wykorzystywane przez wielu

użytkowników - ich cele są często sprzeczne.



Różni użytkownicy mogą posługiwać się inną terminologią,

mówiąc o tych samych problemach.



Zleceniodawcy i użytkownicy to często inne osoby. Głos

zleceniodawców może być w tej fazie decydujący, chociaż

nie zawsze potrafią oni właściwie przewidzieć potrzeby

przyszłych użytkowników.



Koncentrowanie się na sytuacjach typowych i pomijanie

wyjątków oraz przypadków granicznych - zarówno

użytkownicy jak i analitycy mają tendencję do nie

zauważania sytuacji nietypowych lub skrajnych.

Inżynieria oprogramowania, wykład 2, slajd 53

Wymagania stawiane systemom

informatycznym

Inżynieria oprogramowania, wykład 2, slajd 54

Rodzaje wymagań



Wymagania funkcjonalne

– Są stwierdzeniami, jakie usługi ma oferować system, jak ma reagować

na określone dane wejściowe oraz jak ma się zachowywać w
określonych sytuacjach.

– W niektórych wypadkach wymagania funkcjonalne określają, czego

system nie powinien robić.

– Mogą być również wykonywane przy użyciu systemów zewnętrznych.



Wymagania niefunkcjonalne

– To ograniczenia usług i funkcji systemu.
– Obejmują ograniczenia czasowe, ograniczenia dotyczące procesu

tworzenia, standardy itd.



Wymagania dziedzinowe

– Pochodzą z dziedziny zastosowania systemu - odzwierciedlają jej

charakterystykę.

– Mogą być funkcjonalne lub niefunkcjonalne.

Inżynieria oprogramowania, wykład 2, slajd 55

Wymagania funkcjonalne



Zależą od rodzaju tworzonego oprogramowania,
spodziewanych użytkowników oprogramowania i rodzaju
wytwarzanego systemu.



Występują w wersjach dla:

– wymagań użytkownika - ich opis jest bardziej ogólny;
– wymagań systemowych - szczegółowo definiują funkcje

systemu, jego wejścia, wyjścia, wyjątki itd.



Specyfikacja wymagań funkcjonalnych stawianych
systemowi powinna być kompletna i spójna.



W praktyce w wypadku złożonych systemów nie da się
osiągnąć kompletności i spójności - przyczynami tego są
swoista złożoność tych systemów oraz fakt, że różne
punkty widzenia są związane ze sprzecznymi potrzebami.

Inżynieria oprogramowania, wykład 2, slajd 56

Wymagania funkcjonalne



Określenie wymagań funkcjonalnych obejmuje:

– Określenie wszystkich rodzajów użytkowników, którzy:

» będą korzystać z systemu,
» są niezbędni do działania systemu (obsługa, wprowadzanie

danych, administracja);

– Dla każdego rodzaju użytkownika określenie funkcji

systemu oraz sposobów korzystania z planowanego
systemu.

– Określenie systemów zewnętrznych, które będą

wykorzystywane podczas działania systemu (zewn. bazy
danych, sieci, Internet).

– Ustalenie struktur organizacyjnych, przepisów prawnych,

statutów, zarządzeń, instrukcji, itd., które pośrednio lub
bezpośrednio określają funkcje systemu.

Inżynieria oprogramowania, wykład 2, slajd 57

Wymagania niefunkcjonalne



Mogą definiować ograniczenia systemu, takie jak
możliwości urządzeń wejścia-wyjścia i
reprezentacje danych używane przez interfejsy
systemu.



Wymagania niefunkcjonalne wynikają z:

– potrzeb użytkownika,
– ograniczeń budżetowych,
– strategii firmy,
– konieczności współpracy z innymi systemami sprzętu

lub oprogramowania,

– czynników zewnętrznych.

Inżynieria oprogramowania, wykład 2, slajd 58

Klasyfikacja wymagań

niefunkcjonalnych



Wymagania produktowe

– Określają zachowanie produktu. Przykładami są

wymagania efektywnościowe dotyczące szybkości

działania systemu i jego zapotrzebowania na pamięć,

wymagania niezawodności.



Wymagania organizacyjne

– Wynikają ze strategii i procedur w firmie klienta i w

firmie wytwórcy.



Wymagania zewnętrzne

– Ta szeroka kategoria mieści wszystkie wymagania

wynikające z czynników zewnętrznych. Obejmują m.in.

wymagania współpracy, które definiują interakcje

systemu z systemami innych firm i wymagania prawne.

Inżynieria oprogramowania, wykład 2, slajd 59

Klasy wymagań niefunkcjonalnych

Wymagania

niefunkcjonalne

Wymagania

przenośności

Wymagania

niezawodności

Wymagania

sprawnościowe

Wymagania

etyczne

Wymagania

zewnętrzne

Wymagania

współpracy

Wymagania

produktowe

Wymagania

organizacyjne

Wymagania

efektywnościowe

Wymagania

użyteczności

Wymagania

dostawy

Wymagania

implementacyjne

Wymagania

standardów

Wymagania

prawne

Wymagania

pamięciowe

Wymagania

ochrony

prywatności

Wymagania

zabezpieczeń

Inżynieria oprogramowania, wykład 2, slajd 60

Problemy dot. wymagań

niefunkcjonalnych



Podstawowy problem - trudność weryfikowania.



Odzwierciedlają ogólne dążenia klienta, np.

łatwość użycia, zdolność do naprawy awarii i

szybka reakcja na działania użytkownika - różne

interpretacje.



Klienci mogą nie być w stanie przetłumaczyć

swoich celów na wymagania ilościowe.



Wymagania niefunkcjonalne są często sprzeczne

lub powiązane z innymi wymaganiami

funkcjonalnymi.



Chociaż należy odróżnić wymagania funkcjonalne

i niefunkcjonalne w dokumentacji wymagań, w

praktyce jest to jednak trudne.

Inżynieria oprogramowania, wykład 2, slajd 61

Wymagania niefunkcjonalne -

przykłady



Wymaganie produktowe

– System powinien być łatwy w użyciu dla doświadczonych

kontrolerów, a sposób jego organizacji powinien zmniejszać liczbę

błędów użytkownika.

oraz wersja weryfikowalna:
– Doświadczeni kontrolerzy powinni móc używać wszystkich funkcji

systemu po szkoleniu trwającym dwie godziny.

Po tym szkoleniu średnia liczba błędów robionych przez

doświadczonych użytkowników nie powinna przekroczyć dwóch

dziennie.



Wymaganie organizacyjne

– Proces tworzenia systemu i końcowe dokumenty powinny być

zgodne z procesem i produktami zdefiniowanymi w standardzie

XYZCo-SP-STAN-95.



Wymaganie zewnętrzne

– System nie powinien ujawniać operatorom żadnych danych

osobowych klientów oprócz nazwisk i numerów identyfikacyjnych.

Inżynieria oprogramowania, wykład 2, slajd 62

Miary dla wymagań niefunkcjonalnych

Właściwość

Miara

Szybkość

Rozmiar

Łatwość
użycia

Niezawodn
ość

Solidność

Przenośnoś
ć

Liczba przetworzonych transakcji na sekundę
Czas reakcji na zdarzenie wywołane przez użytkownika
Czas odświeżenia ekranu

Kilobajty
Liczba układów pamięci

Czas szkolenia
Liczba okien pomocy

Średni czas bez awarii
Prawdopodobieństwo niedostępności
Częstość błędów
Dostępność
Czas uruchamiania po awarii
Ułamek zdarzeń powodujących awarie
Prawdopodobieństwo zniszczenia danych
po awarii

Procent poleceń zależnych od platformy
Liczba docelowych systemów

Inżynieria oprogramowania, wykład 2, slajd 63

Wymagania dziedzinowe



Są wyrażone za pomocą języka
specyficznego dla dziedziny zastosowania;



Niestety inżynierowie oprogramowania
często ich nie rozumieją i implementują w
sposób niesatysfakcjonujący;



Eksperci z danych dziedzin mogą pominąć
niektóre informacje, ponieważ jest ona dla
nich oczywista.

Inżynieria oprogramowania, wykład 2, slajd 64

Wymagania dziedzinowe - przykłady



System bezpieczeństwa ruchu pociągów:

– Tempo zmniejszania prędkości pociągu jest wyznaczane

następująco:

» Dpociągu = Dsterowania + Dnachylenia, przy czym Dnachylenia

wynosi:



9,81m/s

* wyrównane nachylenie/alfa,



a 9,81m/s

/alfa są znane dla różnych typów pociągów



System dla biblioteki:

– Wszystkie bazy danych powinny być dostępne przez jednolity

interfejs użytkownika, którego podstawą jest standard Z39.50.

– Ze względu na ochronę praw autorskich niektóre dokumenty

należy składać natychmiast po ich otrzymaniu. Zależnie od
wymagań użytkownika, dokumenty te będą drukowane lokalnie
na serwerze systemowym i przekazywane do rąk czytelnika
albo wysyłane na drukarkę sieciową.

Inżynieria oprogramowania, wykład 2, slajd 65

Specyfikacja wymagań systemu z

użyciem standardowego formularza

ECLIPSE/Workstation/Tools/DE/FS/3.5.1

Funkcja. Dodaj węzeł
Opis. Dodaje węzeł do istniejącego projektu. Użytkownik wybiera
typ i położenie węzła
po dodaniu do projektu węzeł jest zaznaczony. Użytkownik wybiera
miejsce węzła
przesuwając wskaźnik na obszar, w którym dodano węzeł
Dane wejściowe. Typ węzła, Położenie węzła, Identyfikator projektu
Źródło. Typ węzła i Położenie węzła pochodzą od użytkownika, a
Identyfikator projektu
z bazy danych
Dane wyjściowe. Identyfikator projektu
Przeznaczenie. Baza danych projektów. Projekt jest utrwalany w
bazie danych po
zakończeniu operacji
Wymagania. Korzeniem grafu projektu musi być dany identyfikator
projektu
Warunek początkowy. Projekt jest otwarty i wyświetlony na
ekranie użytkownika
Warunek końcowy. Projekt nie uległ zmianie z wyjątkiem dodania
węzła zadanego
typu o zadanym położeniu
Efekty uboczne. Nie ma

Inżynieria oprogramowania, wykład 2, slajd 66

Specyfikacje wymagań w PDL



Niejednoznaczności języka naturalnego można uniknąć
przez opisywanie wymagań operacyjnie za pomocą języka
opisu programów (Program Description Language, PDL);



Jest on podobny do języków programowania takich jak Java i
Ada;



Proponuje się używać PDL w dwóch następujących
sytuacjach:

– Gdy operacja jest specyfikowana jako ciąg prostszych akcji,

których kolejność wykonania jest istotna.

» Opisy takich sekwencji w języku naturalnym są czasami mylące,

zwłaszcza gdy te ciągi obejmują zagnieżdżone warunki i pętle;

– Gdy trzeba wyspecyfikować interfejsy sprzętowe i programowe.

» W wielu wypadkach interfejsy między podsystemami są definiowane

w specyfikacji wymagań systemowych;

Inżynieria oprogramowania, wykład 2, slajd 67

Specyfikacje wymagań w PDL



Wady użycia PDL do specyfikowania
wymagań:

– Język używany do zapisu specyfikacji

może nie być wystarczająco wyrazisty,
aby określić funkcjonalność systemu;

– Notacja jest zrozumiała jedynie dla osób,

które znają podstawy języków
programowania, ale można ją połączyć z
użyciem strukturalnego języka
naturalnego;

Inżynieria oprogramowania, wykład 2, slajd 68

Specyfikacje wymagań w PDL

Class Bankomat {
// tu deklaracje
public static void main (String args []) throws ZłaKarta {
try {
taKarta.odczytaj(); //może zgłosić wyjątek ZłaKarta
pin = Klawiatura.odczytajPin();próby =1;
while (!ta Karta.pin.equals(pin) & próby < 4)
{ pin = Klawiatura.odczytajPin(); próby = próby + 1;

}

if (!taKarta. pin.equals(pin))

throw new ZłaKarta („Zły PIN”);

toSaldo = taKarta.odczytajSaldo();
do { Ekran.pytanie(„Wybierz usługę”);

usługa = Ekran.dotkniętyKlawisz();

switch (usługa) {
case Usługi.wypłataZPokwitowaniem:
wymaganePokwitowanie = true;

Przykład - fragment opisu działania bankomatu

Inżynieria oprogramowania, wykład 2, slajd 69

Specyfikacje wymagań w PDL



Specyfikacja interfejsów:

– Większość systemów oprogramowania musi współdziałać z

innymi systemami, które już zaimplementowano i
zainstalowano w ich środowisku.

– To wymaga precyzyjnego wyspecyfikowania interfejsów

pomiędzy nowym systemem a już działającymi systemami.

– Trzy typy interfejsów:

» interfejsy proceduralne;
» struktury danych, które są przekazywane między

podsystemami;

» reprezentacje danych.

– Formalne notacje umożliwiają definiowanie interfejsów w

sposób jednoznaczny, ale ich wyspecjalizowana natura
oznacza, że są niezrozumiałe bez odrębnego szkolenia.

Inżynieria oprogramowania, wykład 2, slajd 70

Specyfikacje wymagań w PDL

Przykład: Opis interfejsu serwera drukowania za pomocą PDL

opartego na Javie

Inżynieria oprogramowania, wykład 2, slajd 71

Inżynieria wymagań

Proces inżynierii wymagań

Inżynieria oprogramowania, wykład 2, slajd 72

Określenie i analiza

wymagań

Specyfikacja

wymagań

Modele

systemu

Wymagania

Użyt- kownika

systemu

Zatwierdza

nie

wymagań

Raport o

wykonywalności

Studium

wykonalnoś

Dokumentacja

wymagań

Składowe czynności Specyfikowanie

oprogramowania

Inżynieria oprogramowania, wykład 2, slajd 73

Studium wykonalności



Wynikiem tego studium powinien być raport, który
zaleca albo nie zaleca kontynuacji procesu
inżynierii wymagań i tworzenia systemu.



Studium wykonalności to krótkie, skumulowane
opracowanie, w którym staramy się odpowiedzieć
na kilka pytań:

– Czy system przyczyni się do realizacji ogólnych celów

przedsiębiorstwa?

– Czy system może być zaimplementowany z użyciem

dostępnych technologii, w ramach ustalonego budżetu i
ograniczeń czasowych?

– Czy system może być zintegrowany z istniejącymi

systemami, które już zainstalowano?

Inżynieria oprogramowania, wykład 2, slajd 74

Przeprowadzanie studium

wykonalności



Obejmuje określenie i zebranie informacji oraz

pisanie raportu;



Przykłady pytań:

– Jak firma poradziłaby sobie, jeśli system nie byłby

zaimplementowany?

– Jakie problemy występują w obecnie przyjętych

procesach i jak nowy system ma pomóc w ich eliminacji?

– Jaki byłby bezpośredni wkład systemu w osiąganie celów

gospodarczych?

– Czy można przekazywać informacje do i z innych

systemów przedsiębiorstwa?

– Czy system wymaga technologii, których wcześniej w

firmie nie stosowano?

– Co system musi wspomagać, a czego nie musi?

Inżynieria oprogramowania, wykład 2, slajd 75

Określenie i analiza

wymagań

Specyfikacja

wymagań

Modele

systemu

Wymagania

Użyt- kownika

systemu

Zatwierdza

nie

wymagań

Raport o

wykonywalności

Studium

wykonalnoś

Dokumentacja

wymagań

Składowe czynności Specyfikowanie

oprogramowania

Inżynieria oprogramowania, wykład 2, slajd 76

Określanie i analizowanie wymagań



Po wstępnych studiach wykonalności następna fazą

inżynierii wymagań jest określanie i analizowanie

wymagań.



W trakcie tej czynności techniczni budowniczowie

oprogramowania pracują z klientem i

użytkownikami systemu nad badaniem dziedziny

zastosowania i usług, które system ma oferować,

pożądanej efektywności, ograniczeniach

sprzętowych itd.



W określaniu i analizowaniu wymagań mogą wziąć

udział osoby z różnych stanowisk w firmie. Pojęcie

uczestnik odnosi się do każdego, kto powinien

mieć pewien pośredni lub bezpośredni wpływ na

wymagania systemowe.

Inżynieria oprogramowania, wykład 2, slajd 77

Problemy analizy wymagań



Uczestnicy często nie wiedzą, czego tak naprawdę
oczekują od systemu komputerowego.



Uczestnicy systemu w naturalny sposób wyrażają
wymagania za pomocą własnych pojęć.



Różni uczestnicy mogą stawiać różne wymagania.



Czynniki polityczne mogą mieć wpływ na system



Środowisko ekonomiczne i gospodarcze, w którym
prowadzi się analizę, jest dynamiczne - zmienia się
w trakcie procesu analizy.

Inżynieria oprogramowania, wykład 2, slajd 78

Faza określania i analizowania

wymagań

Początek

procesu

Rozpoznanie

dziedziny

Zbieranie

wymagań

Klasyfikacja

Usuwanie

sprzeczności

Nadawanie

priorytetów

Sprawdzenie

wymagań

Specyfikacja

wymagań

Dokumentacja

wymagań

Inżynieria oprogramowania, wykład 2, slajd 79

Faza określania i analizowania

wymagań



Czynności procesu

– Rozpoznanie dziedziny
– Zbieranie wymagań
– Klasyfikacja
– Usuwanie sprzeczności
– Nadawanie priorytetów
– Sprawdzanie wymagań

Inżynieria oprogramowania, wykład 2, slajd 80

Określenie i analiza

wymagań

Specyfikacja

wymagań

Modele

systemu

Wymagania

Użyt- kownika

systemu

Zatwierdza

nie

wymagań

Raport o

wykonywalności

Studium

wykonalnoś

Dokumentacja

wymagań

Składowe czynności Specyfikowanie

oprogramowania

Inżynieria oprogramowania, wykład 2, slajd 81

Modelowanie systemu



Różne modele mogą powstawać podczas różnych
czynności analizy wymagań;



Określanie i analizowanie wymagań jest procesem
iteracyjnym - cykl rozpoczyna się od rozpoznania
dziedziny a kończy na sprawdzeniu wymagań;



Stopień zrozumienia dziedziny przez analityków
rośnie z każdym cyklem;



Wybrane metody:

– Określanie oparte na punktach widzenia
– Scenariusze:

» Przypadki użycia

Inżynieria oprogramowania, wykład 2, slajd 82

Określanie oparte na punktach

widzenia



Średnie i wielkie systemy maja zwykle kilku

różnych użytkowników;



Wielu uczestników w jakiś sposób interesuje się

wymaganiami systemowymi;



Uczestnicy miewają różne punkty widzenia na

ten sam problem;



Analiza z wielu perspektyw jest ważna, ponieważ

nie istnieje jedynie słuszna metoda na

analizowanie wymagań;



Punkty widzenia w naturalny sposób porządkują

wymagania;

Inżynieria oprogramowania, wykład 2, slajd 83

Określanie oparte na punktach

widzenia



Typy punktów widzenia:

– Źródło lub przeznaczenie danych

» Punkt widzenia odpowiedzialny za produkowanie lub

użytkowanie danych

» Analiza polega na rozpoznaniu wszystkich takich punktów

widzenia i sprawdzeniu, czy założenia dotyczące danych są
poprawne

– Zrąb reprezentacji

» Osoba związana z konkretnym typem modelu systemu
» Odpowiednie dla systemów czasu rzeczywistego.

– Odbiorca usług

» Punkty widzenia są zewnętrzne wobec systemu.

Inżynieria oprogramowania, wykład 2, slajd 84

Metoda VORD

Identyfikacja

punktów widzenia

Strukturalizacja

punktów widzenia

Dokumentacja

punktów widzenia

Przyporządkowanie

punktów widzenia

do systemu

A viewpoint-oriented

method

Inżynieria oprogramowania, wykład 2, slajd 85

Model procesu VORD



Identyfikacja punktów widzenia

– Znajdowanie punktów widzenia, których reprezentanci

korzystają z usług systemu i usług dla tych
reprezentantów



Strukturalizacja punktów widzenia

– Grupowanie podobnych punktów widzenia w hierarchię
– Wspólne usługi są umieszczone powyżej



Dokumentowanie punktów widzenia

– Udoskonalanie opisów punktów widzenia i usług



Przyporządkowywanie punktów widzenia

– Przekształcanie punktów widzenia w projekt obiektowy

Inżynieria oprogramowania, wykład 2, slajd 86

Szablony formularzy VORD

Szablon do punktu widzenia

Odnośnik: Nazwa punktu
widzenia

Atrybuty: Atrybuty z
informacją o punkcie
widzenia

Zdarzenia: Odnośnik do
zbioru scenariuszy
opisujących, jak system
reaguje na zdarzenia w
ramach tego punktu
widzenia

Usługi: Odnośnik do zbioru
opisów usług

Podrzędne: Nazwy
podrzędnych punktów

Szablon do usług

Odnośnik: Nazwa usługi

Uzasadnienie: Przyczyna oferowania
usługi

Specyfikacja: Odnośnik do listy
specyfikacji usług, które mogą być
zapisane za pomocą różnych notacji

Punkty widzenia: Lista nazw
punktów widzenia, których
reprezentacji korzystają z usługi

Wymagania niefunkcjonalne:
Odnośnik do zbioru wymagań
niefunkcjonalnych ograniczających
usługę

Dostawca: Lista obiektów systemu
oferujących tę usługę

Inżynieria oprogramowania, wykład 2, slajd 87

Przykład - System obsługi bankomatu



Założenia:

– bankomat jest własnością banku,
– klientom tego banku oferuje pełną gamę usług,
– klientom innych banków usługi w

ograniczonym zakresie;



Usługi zawierają:

– wypłatę pieniędzy,
– wysłanie wiadomości do banku,
– wydruk stanu konta,
– przelew pieniędzy;

Inżynieria oprogramowania, wykład 2, slajd 88

Przykład - System obsługi bankomatu



Punkty widzenia dla bankomatu:

– Klienci banku
– Przedstawiciele innych banków
– Inżynierowie pielęgnacji sprzętu i

oprogramowania

– Dział marketingu banku
– Dyrektorzy oddziałów banku
– Administratorzy baz danych i dział

bezpieczeństwa

– Inżynierowie komunikacji
– Pracownicy obsługi klienta w oddziałach

Inżynieria oprogramowania, wykład 2, slajd 89

Przykład - System obsługi bankomatu

Pytanie

o saldo

Odczyt

transakcji

Zasoby

maszyny

Zdalna

diagnostyka

Wypłata

gotówki

Zdalna

aktualizacja

oprogramowania

Zamówienie

czeków

Przelew

środków

Zamówienie

wyciągu

Przekazywanie

komunikatów

Baza danych

klientów

Menedżer

Właściciel

konta

Obcy

klient

Pielęgnacja

oprogramowania

Kasa

banku

Informacje

o koncie

Interfejs

użytkownika

Koszt systemu

Karta

skradziona

Niezawodność

Aktualizacja

konta

Dziennik

komunikatów

Zwrot

karty

Rozmiar

oprogramowania

Drukarka

Zabezpieczenia

Dziennik

transakcji

Nieuprawniony

użytkownik

Zatrzymanie

karty

Weryfikacja

karty

Burza mózgów w trakcie identyfikacji punktów widzenia

Inżynieria oprogramowania, wykład 2, slajd 90

Przykład - System obsługi bankomatu

Właściciel
konta

Obcy klient

Kasa banku

Lista usług

Wypłata gotówki

Diagnostyka

Pytanie o saldo

Dodanie gotówki

Zamówienie
czeków

Dodanie papieru

Wysłanie
komunikatu

Lista transakcji
Zamówienie

wyciągu
Przelew środków

Informacje o usługach

Inżynieria oprogramowania, wykład 2, slajd 91

Przykład - System obsługi bankomatu

WŁAŚCICIEL

KONTA

Dane

sterujące

Dane

wejściowe

Rozpocznij

transakcję

Informacje z

karty

Anuluj

transakcję

Zakończ

transakcję

Żądana kwota

Wybór usługi Komunikat

Dane wejściowe i sterujące

Inżynieria oprogramowania, wykład 2, slajd 92

Przykład - System obsługi bankomatu

Wszystkie PW

Personel banku

Klient

Właściciel

konta

Klient

obcy

Kasa

Inżynier

Menedżer

Usługi

Pytanie o saldo

Wypłata gotówki

Usługi
Zamówienie czeków
Wysłanie komunikatu
Lista transakcji
Zamówienie wyciągu
Przelew środków

Hierarchia punktów widzenia

Inżynieria oprogramowania, wykład 2, slajd 93

Przykład - System obsługi bankomatu

Odnośnik: Klient

Atrybuty: Numer konta,
PIN

Zdarzenia: Zacznij
transakcję, Wybór usługi,
Anuluj transakcję,
Zakończ transakcję

Usługi: Wypłata gotówki,
Pytanie o saldo

Podrzędne: Właściciel
konta, Klient Obcy

Odnośnik: Wypłata gotówki

Uzasadnienie: Celem jest ulepszenie
obsługi klienta i zmniejszenie liczby
papierowych dokumentów

Specyfikacja: Użytkownicy wybierają
tę usługę przez naciśnięcie przycisku
„wypłata gotówki”. Następnie
wprowadzają żądaną kwotę.
Potwierdza się ją i jeśli na koncie są
odpowiednie środki, następuje wypłata

Punkty widzenia: Klient

Wymagania niefunkcjonalne:
Wypłacić gotówkę najpóźniej po 1
minucie od potwierdzenia kwoty

Dostawca: Wypełnić później

Wzory: klient/wypłata gotówki

Inżynieria oprogramowania, wykład 2, slajd 94

Scenariusze



Ludzie zwykle wolą i rozumieją lepiej przykłady

wzięte z życia niż abstrakcyjne opisy



Scenariusze są przykładami, jak system jest

używany w praktyce



Każdy scenariusz obejmuje jedną lub najwyżej

kilka możliwych interakcji użytkownika z

systemem



Scenariusze są szczególnie przydatne w

dodawaniu szczegółów do ogólnych opisów



Inżynierowie wymagań mogą skorzystać z

informacji zebranych w trakcie dyskusji do

formułowania rzeczywistych wymagań

systemowych

Inżynieria oprogramowania, wykład 2, slajd 95

Opis scenariusza



Stan systemu przed rozpoczęciem
scenariusza



Normalny przebieg zdarzeń scenariusza



Co może pójść źle i jak to jest obsługiwane



Inne zdarzenia, które mogą dziać się w
tym samym czasie



Stan systemu po zakończeniu scenariusza

Inżynieria oprogramowania, wykład 2, slajd 96

Scenariusze zdarzeń



Scenariusze zdarzeń mogą być używane do opisu
jak system odpowiada na jakieś konkretne
zdarzenie np. „początek transakcji”



VORD zawiera graficzne konwencje do
przedstawiania scenariuszy zdarzeń.

– Elipsy to dane przekazywane z i do reprezentantów

punktów widzenia

– Informacja sterująca wychodzi z góry prostokąta
– Dane wychodzą z boku prostokąta
– Wyjątki są pokazywane na dole prostokątów
– Następne zdarzenie w cieniowanym prostokącie

Inżynieria oprogramowania, wykład 2, slajd 97

Przykład - System obsługi bankomatu

Karta

Poproś

o PIN

Przekroczenie

limitu czasu

Zwróć kartę

Karta

skradziona

Zatrzymaj kartę

Karta nieważna

Zwróć kartę

Wsunięto kartę

Zły PIN

Wprowadź

ponownie PIN

Zły PIN

Zwróć kartę

Sprawdź

użytkownika

Numer

konta

Karta ważna

Wybierz

usługę

Użytkownik OK

Numer

konta

Scenariusz zdarzenia – zacznij transakcję

Inżynieria oprogramowania, wykład 2, slajd 98

Przykład - System obsługi bankomatu



Opis wyjątków:

– Przekroczenie limitu czasu. Klientowi

nie udało się wprowadzić kodu PIN w
wyznaczonym czasie

– Karta nieważna. Nie udało się

rozpoznać karty

– Karta skradziona. Karta została

zgłoszona jako skradziona

Inżynieria oprogramowania, wykład 2, slajd 99

Scenariusze zdarzeń - Przypadki użycia



Po raz pierwszy użyte w metodzie Objectory
(Jacobson, 1993)



Obecnie podstawowy element notacji UML do
opisywania obiektowych modeli systemu



Definiują aktorów biorących udział w interakcji,
co opisuje samą interakcję



Zbiór przypadków użycia powinien opisywać
wszystkie interakcje w systemie



Diagramy przebiegów mogą służyć do dodawania
szczegółowej informacji do przypadków użycia

Inżynieria oprogramowania, wykład 2, slajd 100

Zarządzanie przypadkami użycia

Wymagania

użytkownika

Wymagania

na system

Model

przypadków użycia

Specyfikacja

uzupełniająca

Wizja

Model projektowy

Model testów

Dokumentacja użytkownika i

materiały treningowe

Inżynieria oprogramowania, wykład 2, slajd 101

Zarządzanie przypadkami użycia



Krótki opis



Aktorzy



Podstawowy przepływ zdarzeń



Przepływy alternatywne

– 4.1

» 4.1.1< Pierwszy przepływ alternatywny

» 4.1.2< Drugi przepływ alternatywny >

– 4.2

<Inny obszar

funkcjonalności>

» 4.2.1< Inny przepływ alternatywny >



Podprzepływy

– 5.1

< Pierwszy podprzepływ

– 5.2

< Drugi podprzepływ >



Kluczowe scenariusze



Warunki wstępne

– 7.1

< Pierwszy warunek

wejściowy >



Warunki końcowe

– 8.1

< Pierwszy warunek

końcowy >



Punkty rozszerzeń

– 9.1

<Nazwa punktu

rozszerzeń>



10.

Specjalne wymagania

– 10.1

< Pierwsze specjalne

wymaganie >

Wymagania

na system

Model

przypadków użycia

Specyfikacja

uzupełniająca

Inżynieria oprogramowania, wykład 2, slajd 102

Przykład - System obsługi biblioteki

Obsługa wypożyczania

Przypadek użycia - wypożyczenie

Czytelnik

Inżynieria oprogramowania, wykład 2, slajd 103

Przykład - System obsługi biblioteki

Czytelnik

Obsługa wypożyczania

Dostawa

Zarządzanie użytkownikami

Obsługa katalogu

Personel
biblioteki

Przypadki użycia biblioteki

Inżynieria oprogramowania, wykład 2, slajd 104

Przykład - System obsługi biblioteki

Sprzedawca
książek

Nabądź

Składnik:
Składnik biblioteki

Książki:
Katalog

Katalogujący:
Personel biblioteki

Nowy

Kataloguj
składnik

Usuń składnik

z katalogu

Usuń

Zarządzanie katalogiem

Inżynieria oprogramowania, wykład 2, slajd 105

Określenie i analiza

wymagań

Specyfikacja

wymagań

Modele

systemu

Wymagania

Użyt- kownika

systemu

Zatwierdza

nie

wymagań

Raport o

wykonywalności

Studium

wykonalnoś

Dokumentacja

wymagań

Składowe czynności Specyfikowanie

oprogramowania

Inżynieria oprogramowania, wykład 2, slajd 106

Zatwierdzanie wymagań



Polega na wykazaniu, że wymagania
naprawdę definiują system, którego
chce użytkownik



Błędy w wymaganiach kosztują tak
dużo, że warto te wymagania
zatwierdzać

– Poprawianie błędów w wymaganiach

może kosztować sto razy więcej niż
poprawianie błędów w implementacji

Inżynieria oprogramowania, wykład 2, slajd 107

Sprawdzenia wymagań



Ważność. Czy system rzeczywiście dostarcza
funkcji, które najlepiej spełniają potrzeby
użytkownika?



Spójność. Czy wymagania nie są sprzeczne?



Kompletność. Czy są wszystkie wymagania?



Realność. Czy można zaimplementować
wszystkie wymagania?



Weryfikowalność. Czy można je
zweryfikować?

Inżynieria oprogramowania, wykład 2, slajd 108

Techniki zatwierdzania wymagań



Przeglądy wymagań

– Systematyczne analizy wymagań



Prototypowanie

– Przedstawianie klientom działającego modelu

systemu



Generowanie testów

– Tworzenie testów dla sprawdzenia czy wymagania

są weryfikowalne



Automatyczne sprawdzanie niesprzeczności

– Sprawdzanie niesprzeczności wymagań wyrażonych

w strukturalnej lub formalnej notacji

Inżynieria oprogramowania, wykład 2, slajd 109

Zarządzanie wymaganiami



Zarządzanie wymaganiami to proces
zarządzania zmianami wymagań podczas
zbierania wymagań i tworzenia systemu



Wymagania są praktycznie zawsze
niekompletne i sprzeczne

– Nowe wymagania pojawiają się podczas

trwania przedsięwzięcia ze względu na zmiany
w otoczeniu i lepsze zrozumienie systemu

– Różne punkty widzenia mają różne i często

sprzeczne wymagania

Inżynieria oprogramowania, wykład 2, slajd 110

Wymagania stałe i zmienne



Wymagania stałe to względnie stabilne
wymagania, które wynikają z podstawowej
działalności firmy i bezpośrednio odnoszą
się do dziedziny systemu



Wymagania zmienne to wymagania, które
prawdopodobnie ulegną zmianie w trakcie
tworzenia systemu albo po przekazaniu go
do użytkownika

Inżynieria oprogramowania, wykład 2, slajd 111

Zmiany wymagań



Ważność wymagań zależy od punktu
widzenia



Klienci systemu mogą wyrażać wymagania
z perspektywy biznesowej co może być
sprzeczne z wymaganiami użytkowników
końcowych



Otoczenie biznesowe i techniczne zmienia
się w trakcie trwania przedsięwzięcia

Inżynieria oprogramowania, wykład 2, slajd 112

Ewolucja wymagań

Czas

Wstępne

zrozumienie

problemu

Wstępne

wymagania

Zmienione

zrozumienie

problemu

Zmienione

wymagania

Inżynieria oprogramowania, wykład 2, slajd 113

Zarządzanie zmianami wymagań



Należy stosować do wszystkich
postulowanych zmian wymagań



Główne kroki

– Analiza problemu. Rozpoznanie problemu z

wymaganiem i propozycja zmian

– Analiza zmiany i ocena kosztów. Szacuje efekty

wprowadzenia zmiany

– Implementacja zmiany. Modyfikuje

dokumentację wymagań i inne dokumentacje
jeśli zachodzi taka potrzeba

Inżynieria oprogramowania, wykład 2, slajd 114

Zarządzanie zmianami wymagań

Analiza problemu

i specyfikacja

zmiany

Analiza zmiany

i ocena kosztów

Implementacja

zmiany

Rozpoznany

problem

Skorygowane

wymaganie

Inżynieria oprogramowania, wykład 2, slajd 115

Narzędzia CASE



Przechowywanie wymagań

– Wymagania należy gromadzić w zabezpieczonej i

administrowalnej składnicy danych



Zarządzanie zmianami

– Proces zarządzania zmianami to proces

przepływu pracy, którego stany mogą być
precyzyjnie zdefiniowane przez co można go
zautomatyzować



Zarządzanie zależnościami

– Automatyczne ustalanie zależności pomiędzy

wymaganiami a innymi elementami systemu

Document Outline

Slide 1
Slide 2
Slide 3
Slide 4
Slide 5
Slide 6
Slide 7
Slide 8
Slide 9
Slide 10
Slide 11
Slide 12
Slide 13
Slide 14
Slide 15
Slide 16
Slide 17
Slide 18
Slide 19
Slide 20
Slide 21
Slide 22
Slide 23
Slide 24
Slide 25
Slide 26
Slide 27
Slide 28
Slide 29
Slide 30
Slide 31
Slide 32
Slide 33
Slide 34
Slide 35
Slide 36
Slide 37
Slide 38
Slide 39
Slide 40
Slide 41
Slide 42
Slide 43
Slide 44
Slide 45
Slide 46
Slide 47
Slide 48
Slide 49
Slide 50
Slide 51
Slide 52
Slide 53
Slide 54
Slide 55
Slide 56
Slide 57
Slide 58
Slide 59
Slide 60
Slide 61
Slide 62
Slide 63
Slide 64
Slide 65
Slide 66
Slide 67
Slide 68
Slide 69
Slide 70
Slide 71
Slide 72
Slide 73
Slide 74
Slide 75
Slide 76
Slide 77
Slide 78
Slide 79
Slide 80
Slide 81
Slide 82
Slide 83
Slide 84
Slide 85
Slide 86
Slide 87
Slide 88
Slide 89
Slide 90
Slide 91
Slide 92
Slide 93
Slide 94
Slide 95
Slide 96
Slide 97
Slide 98
Slide 99
Slide 100
Slide 101
Slide 102
Slide 103
Slide 104
Slide 105
Slide 106
Slide 107
Slide 108
Slide 109
Slide 110
Slide 111
Slide 112
Slide 113
Slide 114
Slide 115

Wyszukiwarka

Podobne podstrony:
IOpr, wykład 1, wprowadzenie
Wyklad 1 Wymagany zakres wiedzy 2012, Ratownictwo medyczne, Ratownictwo medyczne, Farmakologia, Farm
SRR Wykład wymagania 2011, Zarządzanie PWr, II semestr, Struktury rynku i ich regulacje
IOpr, wykład 3, analiza i projekt(1)
IOpr, wykład 1, wprowadzenie
IOpr, wykład 7 2

więcej podobnych podstron

IOpr, wykład 2, wymagania 3

Document Outline