Inżynieria oprogramowania
część V - Wymagania stawiane oprogramowaniu
mgr inż. Piotr Greniewski
Europejska Wyższa Szkoła Informatyczno-
Ekonomiczna
Inżynieria oprogramowania
część V - Wymagania stawiane oprogramowaniu
mgr inż. Piotr Greniewski
Europejska Wyższa Szkoła Informatyczno-
Ekonomiczna
Slajd nr 2
©Ian Sommerville 2000 - Inżynieria oprogramowania
Wymagania stawiane oprogramowaniu
Zawartość:
Wymagania funkcjonalne i niefunkcjonalne
Wymagania użytkownika
Wymagania systemowe
Dokumentacja wymagań stawianych
oprogramowaniu
Slajd nr 3
©Ian Sommerville 2000 - Inżynieria oprogramowania
Wymagania stawiane oprogramowaniu
Davis (1993) brak konsekwencji w stosowaniu
pojęcia wymagania.
Firma chcąca podpisać kontrakt na wielkie
przedsięwzięcie informatyczne musi określić swoje
wymagania w odpowiednio abstrakcyjny sposób, aby z
góry nie definiować rozwiązań.
Wymagania muszą być spisane, aby różni wykonawcy
mogli ubiegać się o kontrakt.
Gdy kontrakt jest podpisany, wykonawca zapisuje dla
klienta definicję systemu, podając więcej szczegółów,
aby klient mógł zrozumieć i zweryfikować to co system
będzie robił.
Oba te dokumenty noszą nazwę
dokumentacji wymagań
stawianych systemowi.
Slajd nr 4
©Ian Sommerville 2000 - Inżynieria oprogramowania
Wymagania stawiane oprogramowaniu
Dodatkowo oprócz tych dwóch dokumentów
powinien powstać bardziej szczegółowy opis
zwany
specyfikacją projektu oprogramowania
,
który zapełnia lukę pomiędzy czynnościami
inżynierii wymagań a projektowaniem.
Wymagania stawiane oprogramowaniu:
wymagania użytkownika
wymagania systemowe
specyfikacja projektu oprogramowania
Slajd nr 5
©Ian Sommerville 2000 - Inżynieria oprogramowania
Wymagania stawiane oprogramowaniu
Wymagania użytkownika
to opis usług jakich
system ma dostarczać, ograniczeń w jakich ma
działać, spisany w języku naturalny.
Wymagania systemowe
szczegółowo ustalają
usługi systemu i ograniczenia. Dokumentacja
wymagań systemowych, zwana czasem
specyfikacją funkcjonalną powinna być napisana w
sposób precyzyjny i jednoznaczny. Może służyć za
kontrakt między nabywcą systemu a wytwórcą
oprogramowania.
Specyfikacja projektu oprogramowania
jest
abstrakcyjnym opisem projektu oprogramowania.
Jest ona podstawą bardziej szczegółowego
projektu i implementacji.
Slajd nr 6
©Ian Sommerville 2000 - Inżynieria oprogramowania
Wymagania użytkownika i systemowe
1. Oprogramowanie musi zapewnić mechanizmy
reprezentowania
i dostępu do plików zewnętrznych tworzonych przez inne
narzędzia
Definicja wymagań użytkownika
1.1. Użytkownik powinien mieć możność definiowania typów
plików
zewnętrznych
1.2. Każdy typ plików zewnętrznych 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żytkowników 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
Specyfikacja wymagań systemowych
Slajd nr 7
©Ian Sommerville 2000 - Inżynieria oprogramowania
Wymagania stawiane oprogramowaniu
Wymagania
użytkownika
Wymagania
systemowe
Specyfikacja
projektu
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 (być
może)
Architekci systemu
Twórcy oprogramowania
Czytelnicy różnych rodzajów specyfikacji
Slajd nr 8
©Ian Sommerville 2000 - Inżynieria oprogramowania
Wymagania funkcjonalne i
niefunkcjonalne
Podział wymagań stawianych systemom
oprogramowania;
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ć.
Wymagania niefunkcjonalne
to ograniczenia usług i
funkcji systemu. Obejmują ograniczenia czasowe,
ograniczenia dotyczące procesu tworzenia, standardy, itp.
Wymagania dziedzinowe
pochodzą z dziedziny
zastosowania systemu i odzwierciedlają jej
charakterystykę. Mogą być funkcjonalne lub
niefunkcjonalne.
Slajd nr 9
©Ian Sommerville 2000 - Inżynieria oprogramowania
Wymagania funkcjonalne
Wymagania funkcjonalne opisują usługi, które system
powinien oferować.
Zależą od rodzaju tworzonego oprogramowania,
spodziewanych użytkowników oprogramowania i rodzaju
wytwarzanego systemu.
Funkcjonalne wymagania systemu definiują jego funkcje, jego
wejścia, wyjścia, wyjątki itp.
Mogą być wyrażane na kilka różnych sposobów w zależności
od inwencji projektanta należy jednak pamiętać o tym że
programista będzie je interpretował tak aby uprościć
implementację.
Specyfikacja powinna być
kompletna
– wszystkie potrzebne
usługi powinny być wyspecyfikowane.
Specyfikacja powinna być
spójna
– czyli wymagania nie
powinny mieć sprzecznych definicji.
Slajd nr 10
©Ian Sommerville 2000 - Inżynieria oprogramowania
Wymagania funkcjonalne
Przykład trzech wymagań funkcjonalnych
stawianych systemowi biblioteki
uniwersyteckiej:
Użytkownik będzie mógł przeszukać zbiór
wszystkich baz danych lub wybrać tylko ich
podzbiór.
System udostępni odpowiednie narzędzia do
oglądania, aby użytkownik mógł czytać dokumenty z
magazynu.
Każde zamówienie będzie oznaczone unikatowym
identyfikatorem (ORDER_ID), będzie można
skopiować do pamięci konta użytkownika.
Slajd nr 11
©Ian Sommerville 2000 - Inżynieria oprogramowania
Wymagania niefunkcjonalne
Wymagania niefunkcjonalne nie dotyczą konkretnych funkcji
systemu.
Mogą być związane z pojawiającymi się właściwościami
systemu, takimi jak niezawodność, czas reakcji na zdarzenie,
zajętość pamięci.
Mogą definiować ograniczenia systemu takie jak możliwości
urządzeń wejścia-wyjścia.
Wiele wymagań dotyczy systemu jako całości co oznacza, że
nie spełnienie wymagania może uczynić system
bezużytecznym.
Mogą ograniczać proces tworzenia systemu np. standardy
stawiane procesowi tworzenia.
Wynikają z potrzeb użytkownika, ograniczeń budżetowych,
strategii firmy, koniecznością współpracy z innymi systemami.
Slajd nr 12
©Ian Sommerville 2000 - Inżynieria oprogramowania
Wymagania niefunkcjonalne
Podział wymagań niefunkcjonalnych wg.
pochodzenia:
Wymagania produktowe
określają zachowanie
produktu. Przykładami są wymagania
efektywnościowe.
Wymagania organizacyjne
wynikają ze strategii i
procedur w firmie-kliencie i firmie-wytwórcy.
Przykładami są standardy implementacyjne,
dostawy, dokumentacji, ISO
Wymagania zewnętrzne
. Ta szeroka kategoria mieści
wszystkie pozostałe wymagania.
Slajd nr 13
©Ian Sommerville 2000 - Inżynieria oprogramowania
Wymagania niefunkcjonalne
Wymagania
niefunkcjonalne
Wymagania
organizacyjne
Wymagania
zewnętrzne
Wymagania
produktowe
Wymagania
przenośności
Wymagania
niezawodności
Wymagania
sprawnościowe
Wymagania
współpracy
Wymagania
etyczne
Wymagania
prawne
Wymagania
standardów
Wymagania
implementacyjne
Wymagania
dostawy
Wymagania
użyteczności
Wymagania
efektywnościowe
Wymagania
pamięciowe
Wymagania
ochrony prywatności
Wymagania
zabezpieczeń
Typy wymagań niefunkcjonalnych
Slajd nr 14
©Ian Sommerville 2000 - Inżynieria oprogramowania
Wymagania niefunkcjonalne
Wymagania produktowe
4.C.8 Wszelka niezbędna komunikacja między serwerami powinna być
zrealizowana za pomocą protokołu SSH
Wymagania organizacyjne
9.3.2 Proces tworzenia systemu i końcowe dokumenty powinny być zgodne
ze standardem opisanym w XYZCo-SP-STAN-2000
Wymagania zewnętrzne
7.6.5. System nie powinien ujawniać operatorom żadnych danych osobowych
klientów oprócz nazwisk i numerów identyfikacyjnych
Przykład wymagań niefunkcjonalnych
Slajd nr 15
©Ian Sommerville 2000 - Inżynieria oprogramowania
Wymagania niefunkcjonalne
Wymagania niefunkcjonalne są trudne do
weryfikacji. Mogą być zapisywane w sposób
odzwierciedlający ogólne dążenia klienta takie
jak: łatwość użycia, zdolność do naprawy po
awarii i szybka reakcja na działanie
użytkownika. Tak zdefiniowane wymagania
stanowią problem dla wytwórców i są
podstawą późniejszych konfliktów.
Należy wyrażać wymagania niefunkcjonalne
ilościowo za pomocą miar, które można
obiektywnie sprawdzić.
Slajd nr 16
©Ian Sommerville 2000 - Inżynieria oprogramowania
Wymagania niefunkcjonalne
Właściwość
Miara
Szybkość
Liczba przetwarzanych transakcji na sekundę
Czas reakcji na zdarzenie wywołane przez użytkownika
Czas odświeżania ekranu
Rozmiar
Kilobajty
Liczba układów pamięci RAM
Łatwość użycia
Czas szkolenia
Liczba okien pomocy
Niezawodność
Średni czas bez awarii
Prawdopodobieństwo niedostępności
Częstość występowania błędów
Dostępność
Solidność
Czas uruchomienia po awarii
Procent zdarzeń powodujących awarię
Prawdopodobieństwo utraty danych w trakcie awarii
Przenośność
Procent poleceń zależnych od platformy
Liczba dostępnych platform
Slajd nr 17
©Ian Sommerville 2000 - Inżynieria oprogramowania
Wymagania dziedzinowe
Wymagania dziedzinowe wynikają bardziej z
dziedziny zastosowania systemu niż z
konkretnych potrzeb użytkowników.
Wymagania dziedzinowe są istotne ponieważ,
ponieważ odzwierciedlają dziedzinę
zastosowań. Jeśli nie są spełnione system
będzie nieprzydatny dla użytkownika.
Slajd nr 18
©Ian Sommerville 2000 - Inżynieria oprogramowania
Wymagania użytkownika
Wymagania użytkownika powinny określać
wymagania funkcjonalne i niefunkcjonalne tak,
aby były zrozumiałe dla użytkowników systemu.
Powinny ustalać jedynie zewnętrzne
zachowanie systemu unikając poruszania spraw
projektowych.
Wymagania nie powinny być definiowane za
pomocą modelu implementacyjnego.
Powinny być zapisane w języku naturalnym,
używając formularzy i prostych intuicyjnych
diagramów.
Slajd nr 19
©Ian Sommerville 2000 - Inżynieria oprogramowania
Wymagania użytkownika
Problemy wynikające z używania języka
naturalnego;
Brak jasności
. Język naturalny stwarza pewne
bariery związane z precyzyjnością i
jednoznacznością. Powoduje, że dokumenty stają się
nieczytelne i przegadane.
Sprzeczność wymagań
. W języku naturalnym trudno
jest rozgraniczyć wymagania funkcjonalne,
niefunkcjonalne, cele systemu i elementy projektu.
Łączenie wymagań
. W języku naturalnym bardzo
łatwo można zapisać kilka wymagań jako jedno.
Slajd nr 20
©Ian Sommerville 2000 - Inżynieria oprogramowania
Wymagania użytkownika
Metody na uniknięcie nieporozumień przy zapisie wymagań
użytkownika:
Należy opracować standardowy format dokumentu i dbać aby
definicje wymagań były z nim zgodne. Standaryzacja formatu
zmniejsza prawdopodobieństwo przeoczeń. Każde wymaganie
powinno posiadać czytelne i jasne uzasadnienie lub
wyjaśnienie. Odnośniki do innych dokumentacji lub
standardów powinny być podane w widoczny sposób.
Język opisu wymagań powinien być używany konsekwentnie.
Należy rozróżnić wymagania obowiązkowe od
nieobowiązkowych.
Należy stosować wyróżnienia (kursywa, wytłuszczenie, itp.) dla
zaznaczenia głównych części wymagania.
Należy unikać stosowania żargonu komputerowego. Należy
natomiast stosować terminy techniczne używane w dziedzinie
zastosowań systemu.
Slajd nr 21
©Ian Sommerville 2000 - Inżynieria oprogramowania
Wymagania systemowe
Wymagania systemowe to:
bardziej szczegółowy opis wymagań użytkownika
podstawa kontraktu na implementację systemu.
pełna i niesprzeczna specyfikacja całego systemu.
punkt wyjścia do projektowania systemu dla
inżynierów oprogramowania
Wymagania systemowe mogą zawierać różne
modele systemu takie jak model obiektów lub
model przepływu danych.
Powinny określać, co system ma robić, a nie
jak powinien być zaimplementowany. Ponieważ
poziom szczegółowości jest wysoki trudno
całkowicie pominąć informacje projektowe.
Slajd nr 22
©Ian Sommerville 2000 - Inżynieria oprogramowania
Wymagania systemowe
Dalsze kłopoty związane z używaniem języka
naturalnego:
Język naturalny jest zrozumiały jeśli autorzy i
czytelnicy używają tych samych słów do oznaczenia
tych samych pojęć.
Specyfikacje wymagań w języku naturalnym są zbyt
elastyczne. Tę samą rzecz można wyrazić na kilka
różnych sposobów.
W języku naturalnym nie ma łatwego sposobu
podziału wymagań na moduły
Slajd nr 23
©Ian Sommerville 2000 - Inżynieria oprogramowania
Wymagania systemowe
Notacja
Opis
Strukturalny
język naturalny
Podejście polega na definiowaniu standardowych formularzy
i szablonów do wyrażania specyfikacji wymagań
Języki opisu
projektu
W podejściu używa się języka podobnego do języka
programowania, ale z bardziej abstrakcyjnymi elementami
do specyfikowania wymagań poprzez model operacyjny
systemu
Notacje
graficzne
Istnieją specjalne języki graficzne takie jak np. SADT
Specyfikacje
matematyczne
Są to notacje oparte na pojęciach matematycznych.
Notacje specyfikacji wymagań
Slajd nr 24
©Ian Sommerville 2000 - Inżynieria oprogramowania
Dokumentacja wymagań stawianych
oprogramowaniu
Heninger (1980) – dokumentacja wymagań:
powinna określać zachowanie systemu jedynie z
zewnątrz
powinna określać ograniczenia implementacji
powinna być łatwa do zmian
powinna być informatorem dla konserwatorów
systemu
powinna obejmować przewidywania przyszłego
cyklu życia systemu
powinna charakteryzować akceptowalne reakcje na
niepożądane zdarzenia
Slajd nr 25
©Ian Sommerville 2000 - Inżynieria oprogramowania
Użytkownicy dokumentacji wymagań
Klienci systemu
Określają wymagania i czytają je, aby sprawdzić, czy
odpowiadają ich potrzebom. Określają także zmiany wymagań
Menedżerowie
Używają dokumentacji wymagań do planowania oferty budowy
systemu i do planowania procesu jego tworzenia
Inżynierowie systemów
Używają wymagań, aby zrozumieć, jaki system ma być
zbudowany
Inżynierowie testów systemów
Używają wymagań, aby opracować testy zatwierdzające system
Inżynierowie pielęgnacji systemu
Używają wymagań jako pomocy w zrozumieniu systemu i
związków między jego częściami
Slajd nr 26
©Ian Sommerville 2000 - Inżynieria oprogramowania
Standard dokumentacji wymagań wg.
IEEE
1. Wstęp
1.1 Przeznaczenie dokumentacji wymagań
1.2 Zakres produktu
1.3 Definicje, akronimy i skróty
1.4. Odnośniki
1.5. Przegląd pozostałej części dokumentu
2. Ogólny opis
2.1 Wizja produktu
2.2 Funkcje produktu
2.3 Charakterystyka użytkowników
2.4 Ogólne ograniczenia
2.5 Założenia i zależności
Slajd nr 27
©Ian Sommerville 2000 - Inżynieria oprogramowania
Standard dokumentacji wymagań wg.
IEEE
3. Szczegółowe wymagania
obejmują wymagania
funkcjonalne, niefunkcjonalne i interfejsy. Jest to
najbardziej istotna część dokumentu. Nie ma
określonego standardu ze względu na ogromną
różnorodność podejść w firmach. Powinno się
udokumentować interfejsy zewnętrzne, opisać
funkcjonalność i efektywność systemu, wyspecyfikować
oczekiwania wobec logicznej bazy danych, ograniczenia
projektowe, pojawiające się właściwości systemu i
charakterystyki jakości.
4. Dodatki
5. Skorowidz
Slajd nr 28
©Ian Sommerville 2000 - Inżynieria oprogramowania
Struktura dokumentacji wymagań
Przedmowa
Należy w niej określić, dla jakich czytelników jest ten
dokument, oraz opisać historię jego wersji wraz z
uzasadnieniem każdej nowej wersji i podsumowaniem
zmian wprowadzanych w wersji
Wstęp
Należy w nim wyjaśnić dlaczego ten system jest
potrzebny. Należy krótko opisać funkcje systemu i
sposób jego współpracy z innymi systemami. Należy
przedstawić jak system przystaje do ogólnych celów
gospodarczych.
Słownik
Należy tu zdefiniować techniczne pojęcia używane w
dokumencie. Nie należy robić żadnych założeń o
doświadczeniach i wiedzy czytelnika
Slajd nr 29
©Ian Sommerville 2000 - Inżynieria oprogramowania
Struktura dokumentacji wymagań
Definicja wymagań użytkownika
W tym punkcie należy opisać usługi dostarczane
użytkownikowi i wymagania niefunkcjonalne systemu.
Można posłużyć się językiem naturalnym, diagramami
lub inną notacją zrozumiałą dla klientów. Powinno się
określić obowiązujące standardy dotyczące produktu i
procesu
Architektura systemu
W tym rozdziale należy przedstawić ogólny przegląd
spodziewanej architektury systemu, z której wynika
podział funkcji pomiędzy modułami systemu. Należy
wyróżnić używane komponenty architektoniczne
Specyfikacja wymagań systemowych
Tu należy bardziej szczegółowo opisać wymagania
funkcjonalne i niefunkcjonalne.
Slajd nr 30
©Ian Sommerville 2000 - Inżynieria oprogramowania
Struktura dokumentacji wymagań
Modele systemu
Tu należy ustalić model systemu (lub modele), w
którym odzwierciedlono związki między jego
komponentami, oraz system i jego środowisko. Mogą
to być modele obiektowe, przepływu danych i
znaczeniowe modele danych.
Ewolucja systemu
Powinno się opisać główne założenia systemu i
przewidywane modyfikacje, które nastąpią w wyniku
ewolucji sprzętu, zmian potrzeb użytkowników itp.
Slajd nr 31
©Ian Sommerville 2000 - Inżynieria oprogramowania
Struktura dokumentacji wymagań
Dodatki
Należy przedstawić szczegółową, specyficzną
informację związaną z budowanym
oprogramowaniem użytkowym. Przykładami
dodatków są opisy sprzętu i opisy bazy danych.
Definiuje się minimalną i optymalną konfigurację.
Określa się organizację danych oraz związki między
nimi
Skorowidz
Do dokumentacji można dołączyć kilka skorowidzów.
Oprócz skorowidza alfabetycznego mogą to być
skorowidze diagramów, funkcji itp.