©Ian Sommerville 2000
Inżynieria oprogramowania,, Rozdział 5
Slide 1
Wymagania stawiane
oprogramowaniu
Przedstawienie
zagadnienia wymagań
stawianych systemowi
oprogramowania i opisanie
różnych sposobów
wyrażania tych wymagań
©Ian Sommerville 2000
Inżynieria oprogramowania,, Rozdział 5
Slide 1
Wymagania stawiane
oprogramowaniu
Przedstawienie
zagadnienia wymagań
stawianych systemowi
oprogramowania i opisanie
różnych sposobów
wyrażania tych wymagań
©Ian Sommerville 2000
Inżynieria oprogramowania,, Rozdział 5
Slide 2
Cele
•
Rozumieć pojęcie wymagań użytkownika i wymagań
systemowych oraz wiedzieć, dlaczego te dwa rodzaje
wymagań mogą być zapisywane za pomocą różnych
notacji;
•
Rozumieć różnice między wymaganiami
funkcjonalnymi i niefunkcjonalnymi;
•
Znać dwie metody zapisywania wymagań, tzn.
strukturalny język naturalny i opisy oparte na
językach programowania;
•
Wiedzieć, jak wymagania mogą być zorganizowane w
dokumentacji wymagań stawianych oprogramowaniu.
©Ian Sommerville 2000
Inżynieria oprogramowania,, Rozdział 5
Slide 3
Zawartość
Wymagania funkcjonalne i niefunkcjonalne
Wymagania użytkownika
Wymagania systemowe
Dokumentacja wymagań stawianych
oprogramowaniu
©Ian Sommerville 2000
Inżynieria oprogramowania,, Rozdział 5
Slide 4
Inżynieria wymagań
Opisy usług i ograniczeń są wymaganiami
stawianymi systemowi.
Proces wynajdowania, analizowania,
dokumentowania oraz sprawdzania usług i
ograniczeń nosi nazwę inżynierii
wymagań.
©Ian Sommerville 2000
Inżynieria oprogramowania,, Rozdział 5
Slide 5
Co to jest wymóg?
W przemyśle informatycznym pojęcie
wymagania nie jest stosowane konsekwentnie.
Niekiedy wymaganie jest postrzegane jako
zapisane na wysokim poziomie, abstrakcyjne
określenie usług, które system powinien
oferować, albo ograniczenie działania systemu.
Niektórzy określają wymaganie jako
szczegółową, matematycznie formalną definicję
funkcji systemu.
©Ian Sommerville 2000
Inżynieria oprogramowania,, Rozdział 5
Slide 6
Dlaczego występują
rozbieżności (Davis,1993)
“
Jeśli firma chce podpisać kontrakt na wielkie przedsięwzięcie
budowy oprogramowania, to musi najpierw 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 ten kontrakt, być może oferując
różne sposoby spełniania oczekiwać firmy – klienta. Gdy kontrakt
jest już podpisany, wykonawca musi zapisać klientowi definicję
systemu, podając więcej szczegółów, aby klient mógł zrozumieć i
zweryfikować to, co system będzie robił. Oba te dokumenty mogą
nosić nazwę dokumentacji wymagań stawianych systemowi.”
©Ian Sommerville 2000
Inżynieria oprogramowania,, Rozdział 5
Slide 7
Typy wymagań
Wymagania użytkownika
•
To wyrażenia w języku naturalnym oraz diagramy o
usługach oczekiwanych od systemu oraz o
ograniczeniach, w których system ma działać.
Wymagania systemowe
•
Szczegółowo ustalają usługi systemu i ograniczenia.
Dokumentacja wymagań systemowych, zwana czasem
specyfikacją funkcjonalną, powinna być precyzyjna.
Specyfikacja projektu oprogramowania
•
Jest abstrakcyjnym opisem projektu oprogramowania,
który jest podstawa bardziej szczegółowego projektu i
implementacji.
©Ian Sommerville 2000
Inżynieria oprogramowania,, Rozdział 5
Slide 8
Wymagania użytkownika
systemu
Definicja wymagań użytkownika
Oprogramowanie musi zapewniać mechanizmy reprezentowania i
dostępu do plików zewnętrznych tworzonych przez inne narzędzia.
Specyfikacja wymagań
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.
©Ian Sommerville 2000
Inżynieria oprogramowania,, Rozdział 5
Slide 9
Czytelnicy różnych rodzajów
specyfikacji
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
Architekci systemu
Twórcy oprogramowania
©Ian Sommerville 2000
Inżynieria oprogramowania,, Rozdział 5
Slide 10
Wymagania funkcjonalne i
niefunkcjonalne
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
itd.
Wymagania dziedzinowe
•
Pochodzą z dziedziny zastosowania systemu odzwierciedlają jej
charakterystykę. Mogą być funkcjonalne lub niefunkcjonalne.
©Ian Sommerville 2000
Inżynieria oprogramowania,, Rozdział 5
Slide 11
Wymagania funkcjonalne
Wymagania funkcjonalne stawiane systemowi
opisują funkcjonalność lub usługi, które system
powinien oferować.
Zależą od rodzaju tworzonego oprogramowania,
spodziewanych użytkowników oprogramowania
i rodzaju wytwarzanego systemu.
Gdy mają postać wymagań użytkownika, ich
opis jest zwykle bardziej ogólny, natomiast
wymagania funkcjonalne systemowe
szczegółowo definiują funkcje systemu, jego
wejścia, wyjścia, wyjątki itd.
©Ian Sommerville 2000
Inżynieria oprogramowania,, Rozdział 5
Slide 12
Przykłady wymagań
systemowych
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 (ORDE_ID), który będzie można
skopiować
do
pamięci
trwałej
konta
użytkownika.
©Ian Sommerville 2000
Inżynieria oprogramowania,, Rozdział 5
Slide 13
Brak ścisłego określania
specyfikacji wymagań
•
Natura programisty każe mu interpretować jednoznaczne
wymagania tak, aby uprościć implementację. Zwykle nie
jest to jednak to, czego chciał klient.
•
Należy opracować nowe wymagania i dokonać zmian w
systemie. Opóźnia to dostarczenie systemu i podnosi
koszty.
•
Rozważmy wymaganie stawiane systemowi biblioteki,
które mówi o „odpowiednich narzędziach do oglądania”.
• Celem tego wymagania jest zapewnienie narzędzia do
oglądania wszystkich tych formatów.
• Programista działający pod presją czasu może udostępnić
po prostu narzędzie do oglądania tekstu i ogłosić
spełnienie wymagania.
©Ian Sommerville 2000
Inżynieria oprogramowania,, Rozdział 5
Slide 14
Kompletność i spójność
•
W zasadzie specyfikacja wymagań funkcjonalnych
stawianych systemowi powinna być kompletna i spójna.
•
Kompletność oznacza, że wszystkie potrzebne
użytkownikowi usługi powinny być zdefiniowane.
•
Spójność oznacza, że wymagania nie powinny mieć
sprzecznych definicji.
•
W praktyce w wypadku wielkich złożonych systemów
nie da się 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.
©Ian Sommerville 2000
Inżynieria oprogramowania,, Rozdział 5
Slide 15
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.
•
Przykładami wymagań stawianych procesowi są
specyfikacja standardów jakości, których należy użyć
w procesie, stwierdzenie, że projekt należy opracować
za pomocą konkretnego zbioru narzędzi CASE, i opis
procesu, którego należy przestrzegać.
•
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.
©Ian Sommerville 2000
Inżynieria oprogramowania,, Rozdział 5
Slide 16
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- kliencie i w firmie-
wytwórcy.
Wymagania zewnętrzne
•
Ta szeroka kategoria mieści wszystkie wymagania
wynikające z czynników zewnętrznych dla systemu i procesu
jego tworzenia. Obejmuje wymagania współpracy, które
definiują interakcje systemu z systemami innych firm,
wymagania prawne.
©Ian Sommerville 2000
Inżynieria oprogramowania,, Rozdział 5
Slide 17
Typy 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ń
©Ian Sommerville 2000
Inżynieria oprogramowania,, Rozdział 5
Slide 18
Przykłady wymagań
niefunkcjonalnych
Wymaganie produktowe
•
Wszelka niezbędna komunikacja między APSE i użytkownikiem
powinna dać się wyrazić za pomocą standardowego zestawu
symboli Ady.
Wymaganie organizacyjne
•
Proces tworzenia systemu i końcowe dokumenty powinny być
zgodne z procesem i produktami zdefiniowanymi w XYZCo-SP-
STAN-95.
Wymaganie zewnętrzne
•
System nie powinien ujawniać operatorom żadnych danych
osobowych klientów oprócz nazwisk i numerów
identyfikacyjnych.
©Ian Sommerville 2000
Inżynieria oprogramowania,, Rozdział 5
Slide 19
Cele i wymagania
•
Powszechnie występującym
problemem z wymaganiami
niefunkcjonalnymi jest fakt, że
czasem trudno je zweryfikować.
©Ian Sommerville 2000
Inżynieria oprogramowania,, Rozdział 5
Slide 20
Przykłady
Cel systemu
•
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.
Weryfikowalne wymaganie
niefunkcjonalne
•
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.
©Ian Sommerville 2000
Inżynieria oprogramowania,, Rozdział 5
Slide 21
Miary do specyfikowania
wymagań niefunkcjonalnych
Właściwość
Miara
Szybkość
Rozmi
ar
Łatwość użycia
Niezawodność
Solidność
Przenośn
ość
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
©Ian Sommerville 2000
Inżynieria oprogramowania,, Rozdział 5
Slide 22
Problemy z określeniem
wymagań
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.
W zasadzie należy odróżnić wymagania
funkcjonalne i niefunkcjonalne w
dokumentacji wymagań. W praktyce jest to
jednak trudne.
©Ian Sommerville 2000
Inżynieria oprogramowania,, Rozdział 5
Slide 23
Wymagania dziedzinowe
Wymagania dziedzinowe wynikają bardziej z
dziedziny zastosowania systemu niż z
konkretnych potrzeb użytkowników.
Mogą być nowymi wymaganiami
funkcjonalnymi, ograniczać istniejące
wymagania funkcjonalne albo ustalać sposób
wykonywania konkretnych obliczeń.
Wymagania dziedzinowe są istotne, ponieważ
odzwierciedlają podstawy dziedziny
zastosowania. Jeśli nie są spełnione, to system
nie może działać w sposób zadowalający.
©Ian Sommerville 2000
Inżynieria oprogramowania,, Rozdział 5
Slide 24
Wymagania stawiane systemowi
biblioteki
1.
Wszystkie bazy danych powinny być dostępne
przez jednolity interfejs użytkownika, którego
podstawą jest przyjety standard.
2.
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ą.
©Ian Sommerville 2000
Inżynieria oprogramowania,, Rozdział 5
Slide 25
Wymagania dziedzinowe z
systemu bezpieczeństwa
ruchu pociągów
Tempo zmniejszania prędkości pociągu
jest wyznaczane następująco:
• D
pociągu
= D
sterowania
+ D
nachylenia
przy czym D
nachylenia
wynosi
9,81m/s
2
*
wyrównane nachylenie/alfa, a 9,81m/s
2
/alfa są znane dla różnych typów pociągów
.
©Ian Sommerville 2000
Inżynieria oprogramowania,, Rozdział 5
Slide 26
Zasadnicze problemy z
wymaganiami
dziedzinowymi
Są one wyrażone za pomocą języka
specyficznego dla dziedziny zastosowania, co
sprawia, że inżynierowie oprogramowania
często ich nie rozumieją.
Eksperci z danych dziedzin często mogli
pominąć te informację, ponieważ po prostu jest
dla nich oczywista.
Może nie być jednak ona oczywista dla twórców
systemu, którzy mogą to wymaganie
zaimplementować w sposób niezadowalający.
©Ian Sommerville 2000
Inżynieria oprogramowania,, Rozdział 5
Slide 27
Wymagania użytkownika
Wymagania użytkownika stawiane
systemowi powinny określać wymagania
funkcjonalne i niefunkcjonalne tak, aby
były zrozumiałe dla użytkowników
systemu, którzy nie mają szczegółowej
wiedzy technicznej.
Należy je zapisywać w języku naturalnym,
używając formularzy i prostych
intuicyjnych diagramów.
©Ian Sommerville 2000
Inżynieria oprogramowania,, Rozdział 5
Slide 28
Problemy z językiem
naturalnym
Brak jasności
•
Czasem trudno jest wyrażać się w języku naturalnym
precyzyjnie i jednoznacznie bez czynienia dokumentów
gadatliwymi i nieczytelnymi.
Sprzeczność wymagań
•
Trudno jest jasno rozgraniczać wymagania
funkcjonalne, wymagania niefunkcjonalne, cele systemu
i elementy projektu.
Łączenie wymagań
•
Kilka różnych wymagań może być zapisanych razem
jako jedno wymaganie.
©Ian Sommerville 2000
Inżynieria oprogramowania,, Rozdział 5
Slide 29
Wymaganie stawiane bazie
danych
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.
©Ian Sommerville 2000
Inżynieria oprogramowania,, Rozdział 5
Slide 30
Wymaganie użytkownika
stawiane siatce edytora
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.
©Ian Sommerville 2000
Inżynieria oprogramowania,, Rozdział 5
Slide 31
Problemy przy stawianiu
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.
©Ian Sommerville 2000
Inżynieria oprogramowania,, Rozdział 5
Slide 32
Definicja siatki w edytorze
2.6 Siatka
2.6.1 Edytor będzie udostępniał siatkę, tzn. matrycę linii
pionowych jako tło okna edytora. Ta sama siatka powinna być
pasywna, tzn. za układanie bytów odpowiada użytkownik.
Uzasadnienie: Siatka pomaga użytkownikowi w tworzeniu
schludnego diagramu ze starannie poukładanymi bytami. Chociaż
siatka aktywna, przy której byty przeskakują do linii siatki, może
być użyteczna, jednak wówczas układ diagramu jest nieprecyzyjny.
Użytkownik jest najwłaściwszą osobą do decydowania o położeniu
bytów.
Specyfikacja: ECLIPSE/WS/Tools/DE/FS Punkt 5.6
©Ian Sommerville 2000
Inżynieria oprogramowania,, Rozdział 5
Slide 33
Wymagania użytkownika
wobec dodawania węzłów
3.5.1 Dodawanie węzłów do projektu
3.5.1.1 Edytor będzie udostępniał użytkownikom udogodnienia
do dodawania do swoich projektów węzłów określonego typu
3.5.1.2 Sekwencja czynności, które prowadzą do dodania węzła,
powinna być następująca:
1. Użytkownik powinien wybrać typ węzła, jaki należy dodać
2. Użytkownik powinien przesunąć wskaźnik do przybliżonego
miejsca nowego węzła na diagramie i zalecić dodanie symbolu
węzła w tym punkcie
3. Użytkownik powinien następnie przeciągnąć węzeł do jego
ostatecznego położenia
Uzasadnienie: Użytkownik jest najwłaściwszą osobą do
decydowania o położeniu węzłów na diagramie. Takie podejście
daje użytkownikowi całkowite panowanie nad wyborem typu węzła
i jego umiejscowieniem
Specyfikacja: ECLIPSE/WS/Tools/DE/FS Punkt 3.5.1
©Ian Sommerville 2000
Inżynieria oprogramowania,, Rozdział 5
Slide 34
Rady do zapisywania
wymagań użytkownika
Opracuj standardowy format i spraw, aby
wszystkie definicje wymagań były z nim zgodne.
Konsekwentnie używaj języka. W szczególności
rozróżnij wymagania obowiązkowe od
wskazanych.
Stosuj wyróżnienia (wytłuszczenia, kursywy) do
zaznaczania głównych części wymagania.
Unikaj, jak tylko się da, żargonu
komputerowego.
©Ian Sommerville 2000
Inżynieria oprogramowania,, Rozdział 5
Slide 35
Wymagania systemowe
Wymagania systemowe są bardziej
szczegółowymi opisami wymagań użytkownika.
Mogą być podstawą kontraktu na implementacje
systemu, powinny być zatem pełną i
niesprzeczną specyfikacją całego systemu.
Są traktowane przez inżynierów
oprogramowania jako punkt wyjścia do
projektowania systemu.
Specyfikacja wymagań systemowych może
zawierać różne modele systemu.
©Ian Sommerville 2000
Inżynieria oprogramowania,, Rozdział 5
Slide 36
Wymagania, a projekt
W dokumentacji wymagań można zdefiniować
wstępną architekturę systemu, aby nadać
specyfikacji odpowiednią strukturę. Wymagania
systemowe są zorganizowane zgodnie z podziałem
na podsystemy wchodzące w skład systemu.
W większości wypadków systemy muszą
współpracować z innymi istniejącymi systemami.
Ograniczają one projekt, co implikuje dodatkowe
wymagania stawiane nowemu systemowi.
Użycie specyficznego projektu może być
zewnętrznym wymaganiem systemowym.
©Ian Sommerville 2000
Inżynieria oprogramowania,, Rozdział 5
Slide 37
Dalsze kłopoty z językiem
naturalnym
Niejednoznaczność języka naturalnego prowadzi
do nieporozumień. Jackson (1995) daje wyśmienity
przykład takiej sytuacji, opisując symbole
wyświetlane przez ruchome schody. Mówią one
„buty trzeba założyć” i „psy trzeba nieść”
Do czytelnika należy stwierdzenie, czy dwa
wymagania są takie same, czy też się od siebie
różnią.
Nie ma łatwego podziału wymagań w języku
naturalnym na moduły. Znalezienie wszystkich
powiązanych wymagań może być trudne.
©Ian Sommerville 2000
Inżynieria oprogramowania,, Rozdział 5
Slide 38
Notacje specyfikacji
wymagań
Notacja
Opis
Strukturalny język To podejście polega na definiowaniu standardowych
formularzy
naturalny i szablonów do wyrażania specyfikacji wymagań
Języki opisu W tym podejściu używa się języka podobnego do
języka programowania,
projektu ale z bardziej abstrakcyjnymi elementami do
specyfikowania wymagań
poprzez model operacyjny systemu
Notacje graficzne Do definiowania wymagań funkcjonalnych stawianych
systemowi używa
się języka graficznego z tekstowymi dopiskami.
Przykładem jednego z
pierwszych takich języków graficznych
jest SADT (Ross, 1977;
Schoman i Ross, 1977).
Ostatnio używa się przypadków użycia
(Jacobsen i
inni;1993)
Specyfikacje Są to notacje oparte na pojęciach matematycznych,
takich jak skończone matematyczne maszyny stanowe lub zbiory.
Takie jednoznaczne specyfikacje
zmniejszają spory na
temat funkcjonalności między klientem a
zleceniobiorcą. Większość klientów nie rozumie jednak formalnych
specyfikacji i jest niechętna przyjęciu ich jako kontraktu na
budowę
systemu.
©Ian Sommerville 2000
Inżynieria oprogramowania,, Rozdział 5
Slide 39
Strukturalny język naturalny
Strukturalny język naturalny jest ograniczoną
postacią języka naturalnego, przeznaczoną do
zapisywania wymagań systemowych.
Zaletą tego podejścia jest to, że zachowując
wyrazistość i zrozumiałość języka naturalnego,
zapewnia w pewnym stopniu jednolitość specyfikacji.
Notacje oparte na języku strukturalnym mogą
ograniczać używaną terminologię i obejmować
szablony do specyfikowania wymagań systemowych.
Zawierają zwykle konstrukcje sterujące podobne do
spotykanych w językach oprogramowania i graficzne
wyróżnienia do podziału specyfikacji.
©Ian Sommerville 2000
Inżynieria oprogramowania,, Rozdział 5
Slide 40
Formularz do definiowania
wymagań
Opis specyfikowanej funkcji lub bytu
Opis jej danych wejściowych i źródło ich pochodzenia
Opis jej danych wyjściowych i miejsce ich przeznaczenia
Określenie, z których innych bytów się korzysta (część
wymaga)
Jeśli użyto podejścia funkcjonalnego, to jest wywołany
warunek początkowy, który musi być prawdziwy przed
wywołaniem tej funkcji, oraz warunek końcowy, który
musi być prawdziwy po wywołaniu funkcji.
Opis efektów ubocznych operacji (jeśli występują)
©Ian Sommerville 2000
Inżynieria oprogramowania,, Rozdział 5
Slide 41
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 wejś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
©Ian Sommerville 2000
Inżynieria oprogramowania,, Rozdział 5
Slide 42
Specyfikacje wymagań w PDL
Niejednoznaczności charakterystycznych dla języka
naturalnego można uniknąć przez opisywanie
wymagań operacyjnie za pomocą języka opisu
programów (Program Description Language, PDL).
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. PDL
umożliwia definiowanie typów i obiektów interfejsowych.
©Ian Sommerville 2000
Inżynieria oprogramowania,, Rozdział 5
Slide 43
Opis części działania
bankomatu za pomocą 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;
©Ian Sommerville 2000
Inżynieria oprogramowania,, Rozdział 5
Slide 44
Wady PDL
1.
Język używany do zapisu specyfikacji może nie
być wystarczająco wyrazisty, aby określić
funkcjonalność systemu.
2.
Notacja jest zrozumiała jedynie dla osób, które
znają podstawy języków programowania.
3.
Wymaganie może być potraktowane jako
specyfikacja projektu, a nie jako model, który
ma pomóc użytkownikom w zrozumieniu
systemu.
©Ian Sommerville 2000
Inżynieria oprogramowania,, Rozdział 5
Slide 45
Specyfikacja interfejsów
Większość systemów oprogramowania musi
współdziałać z innymi systemami, które już
zaimplementowano i zainstalowano w ich środowisku.
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.
©Ian Sommerville 2000
Inżynieria oprogramowania,, Rozdział 5
Slide 46
Opis interfejsu serwera
drukowania za pomocą PDL
opartego na Javie
interface SerwerDrukowania {
// definiuje abstrakcyjny serwer drukowania
// wymaga: interface Drukarka, interface DokumentDoWydruku
// udostepnia: inicjuj, drukuj, wyświetlKolejkeZadań, anulujZadanieDrukowania,
// zmieńDrukarkę
void inicjuj ( Drukarka d ) ;
void drukuj ( Drukarka d, DokumentDoWydruku w) ;
void wyświetlKolejkęZadań ( Drukarka d ) ;
void anulujZadanieDrukowania (Drukarka d, DokumentDoWydruku w) ;
void zmieńDrukarkę(Drukarka d1, Drukarka d2, DokumentDoWydruku w) ;
} //SerwerDrukowania
©Ian Sommerville 2000
Inżynieria oprogramowania,, Rozdział 5
Slide 47
Dokumentacja wymagań
stawianych oprogramowaniu
Dokumentacja wymagań stawianych
oprogramowaniu (nazywana czasem specyfikacją
wymagań stawianych oprogramowaniu lub
Software Requirements Specification, SRS) jest
oficjalną deklaracją tego, co jest wymagane od
wytwórców systemu.
Powinna zawierać zarówno wymagania
użytkownika stawiane systemowi, jak i
szczegółowe specyfikacje wymagań systemowych
Nie jest projektem. Powinna opisywać co system
ma robić, a nie jak to robić
©Ian Sommerville 2000
Inżynieria oprogramowania,, Rozdział 5
Slide 48
Klienci systemu
Menedżerowie
Inżynierowie systemów
Inżynierowie testów systemu
Inżynierowie
pielęgnacji systemów
Określają wymagania i czytają je,
aby sprawdzić, czy odpowiadają
ich potrzebom. Określają także
zmiany wymagań.
Używają dokumentacji wymagań
do planowania oferty budowy
systemu i do planowania
procesu jego tworzenia
Używają wymagań,
aby zrozumieć,
jaki system
ma być zbudowany
Używają wymagań, aby
opracować testy
zatwierdzające system
Używają wymagań jako pomocy
w zrozumieniu systemu
i związków między jego
częściami
Użytkownicy
dokumentacji
wymagań
©Ian Sommerville 2000
Inżynieria oprogramowania,, Rozdział 5
Slide 49
Wymagania, które powinny być
spełnione przez dokumentację
wymagań
Powinna określać zachowanie systemu jedynie z
zewnątrz.
Powinna określać ograniczenia implementacji.
Powinno być łatwo ja zmieniać.
Powinna być informatorem dla konserwatorów
systemu.
Powinna obejmować przewidywania przyszłego
cyklu życia systemu.
Powinna charakteryzować akceptowalne relacje
na niepożądane zdarzenia.
©Ian Sommerville 2000
Inżynieria oprogramowania,, Rozdział 5
Slide 50
Standard wymogów IEEE
1
.
Wstęp
1.1. Przeznaczenie tej 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
3. Szczegółowe wymagania
4. Dodatki
5. Skorowidz – jest zbyt ogólny, aby sam mógł być standardem firmowym. Można go
jednak dostosować adoptować tak, aby uzyskać definicję standardu, który
można wykorzystać dla potrzeb konkretnego przedsiębiorstwa.
©Ian Sommerville 2000
Inżynieria oprogramowania,, Rozdział 5
Slide 51
Struktura dokumentacji
wymagań
Przedmowa
Wstęp
Słownik
Definicja wymagań użytkownika
Architektura systemu
Specyfikacja wymagań systemowych
Modele systemu
Ewolucja systemu
Dodatki
Skorowidz
©Ian Sommerville 2000
Inżynieria oprogramowania,, Rozdział 5
Slide 52
Główne tezy
W wymaganiach stawianych systemowi
oprogramowania ustala się co system powinien robić,
oraz definiuje ograniczenia działania i implementację.
Wymagania funkcjonalne to charakterystyki usług,
które system ma oferować, albo opisy sposobu
przeprowadzania pewnych obliczeń.
Wymagania niefunkcjonalne dzieli się na wymagania
produktowe, które ograniczają budowany system,
wymagania procesu, które dotyczą procesu
tworzenia, oraz wymagania zewnętrzne. Zwykle są
powiązane z pojawiającymi się właściwościami
systemu, a zatem stosują się do systemu jako całości.
©Ian Sommerville 2000
Inżynieria oprogramowania,, Rozdział 5
Slide 53
Główne tezy
Wymagania użytkownika są przeznaczone dla osób,
które mają używać i zaopatrywać się w system.
Należy spisać je za pomocą języka naturalnego,
tabel i diagramów tak, aby były zrozumiałe.
Wymagania systemowe służą do poinformowania w
precyzyjny sposób o funkcjach, które system ma
spełniać. Aby uniknąć niejednoznaczności, można
je zapisać jakiegoś języka strukturalnego. Może to
być strukturalna postać języka naturalnego, język
oparty na języku oprogramowania wysokiego
poziomu lub specjalny język do specyfikowania
wymagań.
©Ian Sommerville 2000
Inżynieria oprogramowania,, Rozdział 5
Slide 54
Główne tezy
Dokumentacja wymagań stawianych
oprogramowaniu jest uzgodnionym
zapisem wymagań systemowych. Należy
nadać jej odpowiednią strukturę, aby
mogła być używana zarówno przez
klientów systemu, jak i twórców
oprogramowania.