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.