Transcript Software Requirements

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
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 2
Zawartość




Wymagania funkcjonalne i niefunkcjonalne
Wymagania użytkownika
Wymagania systemowe
Dokumentacja wymagań stawianych oprogramowaniu
©Ian Sommerville 2000
Inżynieria oprogramowania,, Rozdział 5
Slide 3
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 4
Co to jest wymóg?



W przemyśle informatycznym pojęcie wymaganie 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 5
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 6
Typy wymagań

Wymagania użytkownika
•

Wymagania systemowe
•

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ć.
Szczegółowo ustalają usługi systemu i ograniczenia. Dokumentacja
wymagań systemowych, zwana czasem specyfikacją funkcjonalną,
powinna być precyzyjna.
Specyfikacja projektu oprogramowania
•
©Ian Sommerville 2000
Jest abstrakcyjnym opisem projektu oprogramowania, który jest
podstawa bardziej szczegółowego projektu i implementacji.
Inżynieria oprogramowania,, Rozdział 5
Slide 7
Wymagania użytkownika systemu
Definicja wymagań użytkownika
1. 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 8
Czytelnicy różnych rodzajów
specyfikacji
Wymagania
użytkownika
Menedżerowie klienta
Użytkownicy systemu
Inżynierowie klienta
Menedżerowie zleceniobiorcy
Architekci systemu
Wymagania
systemowe
Użytkownicy systemu
Inżynierowie klienta
Architekci systemu
Twórcy oprogramowania
Specyfikacja
Projektu
oprogramowania
©Ian Sommerville 2000
Inżynierowie klienta (być może)
Architekci systemu
Twórcy oprogramowania
Inżynieria oprogramowania,, Rozdział 5
Slide 9
Wymagania stawiane systemom
oprogramowania

Wymagania funkcjonalne
•

Wymagania niefunkcjonalne
•

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ć.
To ograniczenia usług i funkcji systemu. Obejmują ograniczenia
czasowe, ograniczenia dotyczące procesu tworzenia, standardy itd.
Wymagania dziedzinowe
•
©Ian Sommerville 2000
Pochodzą z dziedziny zastosowania systemu odzwierciedlają jej
charakterystykę. Mogą być funkcjonalne lub niefunkcjonalne.
Inżynieria oprogramowania,, Rozdział 5
Slide 10
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 11
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 12
Problemy wynikające z braku ś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 drugie na tej liście 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 13
Kompletność i spójność specyfikacji
wymagań funkcjonalnych




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ę 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.
©Ian Sommerville 2000
Inżynieria oprogramowania,, Rozdział 5
Slide 14
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 15
Klasyfikacja wymagań
niefunkcjonalnych

Wymagania produktowe
•

Wymagania organizacyjne
•

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.
Wynikają ze strategii i procedur w firmie klienta i w firmie wytwórcy.
Wymagania zewnętrzne
•
©Ian Sommerville 2000
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,, Rozdział 5
Slide 16
Typy wymagań niefunkcjonalnych
Wymagania
niefunkcjonalne
Wymagania
produktowe
Wymagania
sprawnościowe
Wymagania
niezawodności
Wymagania
użyteczności
Wymagania
efektywnościowe
Wymagania
organizacyjne
Wymagania
zewnętrzne
Wymagania
współpracy
Wymagania
przenośności
Wymagania
dostawy
Wymagania
implementacyjne
Wymagania
pamięciowe
©Ian Sommerville 2000
Wymagania
standardów
Wymagania
ochrony
prywatności
Inżynieria oprogramowania,, Rozdział 5
Slide 17
Wymagania
etyczne
Wymagania
prawne
Wymagania
zabezpieczeń
Przykłady wymagań niefunkcjonalnych

Wymaganie produktowe
•

Wymaganie organizacyjne
•
•

4.C.8 Wszelka niezbędna komunikacja między środowiskiem
wspomagającym programowanie w Adzie (APSE) i użytkownikiem powinna
dać się wyrazić za pomocą standardowego zestawu symboli Ady.
9.3.2 Proces tworzenia systemu i końcowe dokumenty powinny być zgodne
z procesem i produktami zdefiniowanymi w standardzie
XYZCo-SP-STAN-95.
Wymaganie zewnętrzne
•
7.6.5 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 18
Problemy związane
z wymaganiami niefunkcjonalnymi



Powszechnie występującym problemem z
wymaganiami niefunkcjonalnymi jest fakt, że czasem
trudno je zweryfikować.
Mogą one być zapisywane w sposób
odzwierciedlający ogólne dążenia klienta, takie jak
łatwość użycia, zdolność do naprawy awarii i szybka
reakcja na działania użytkownika.
To jednak zostawia bardzo duży margines do
interpretacji.
©Ian Sommerville 2000
Inżynieria oprogramowania,, Rozdział 5
Slide 19
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
•
©Ian Sommerville 2000
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.
Inżynieria oprogramowania,, Rozdział 5
Slide 20
Miary do specyfikowania wymagań
niefunkcjonalnych
Właściwość
Szybkość
Rozmiar
Łatwość użycia
Niezawodność
Solidność
Przenośność
©Ian Sommerville 2000
Miara
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,, Rozdział 5
Slide 21
Trudności 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 22
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 23
Przykład: wymagania stawiane systemowi
biblioteki
1.
2.
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ą.
©Ian Sommerville 2000
Inżynieria oprogramowania,, Rozdział 5
Slide 24
Wymagania dziedzinowe z systemu
bezpieczeństwa ruchu pociągów

Tempo zmniejszania prędkości
wyznaczane następująco:
•
pociągu
jest
Dpociągu = Dsterowania + Dnachylenia
przy czym Dnachylenia wynosi 9,81m/s2 * wyrównane
nachylenie/alfa, a 9,81m/s2 /alfa są znane dla różnych
typów pociągów .
©Ian Sommerville 2000
Inżynieria oprogramowania,, Rozdział 5
Slide 25
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 oczywista dla twórców systemu,
którzy mogą to wymaganie zaimplementować w
sposób niesatysfakcjonujący.
©Ian Sommerville 2000
Inżynieria oprogramowania,, Rozdział 5
Slide 26
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 27
Problemy z językiem naturalnym

Brak jasności
•

Sprzeczność wymagań
•

Czasem trudno jest wyrażać się w języku naturalnym precyzyjnie i
jednoznacznie bez czynienia dokumentów gadatliwymi i
nieczytelnymi.
Trudno jest jasno rozgraniczać wymagania funkcjonalne, wymagania
niefunkcjonalne, cele systemu i elementy projektu.
Łączenie wymagań
•
©Ian Sommerville 2000
Kilka różnych wymagań może być zapisanych razem jako jedno
wymaganie.
Inżynieria oprogramowania,, Rozdział 5
Slide 28
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.
©Ian Sommerville 2000
Inżynieria oprogramowania,, Rozdział 5
Slide 29
Przykład: wymaganie użytkownika
stawiane siatce 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.
©Ian Sommerville 2000
Inżynieria oprogramowania,, Rozdział 5
Slide 30
Problemy przy stawianiu wymagań
•
•
•
©Ian Sommerville 2000
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,, Rozdział 5
Slide 31
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 32
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 33
Rady do zapisywania wymagań
użytkownika




Opracuj standardowy format i spraw, aby wszystkie
definicje wymagań były z nim zgodne.
Konsekwentnie używaj pojęć językowych. 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 34
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 35
Zapis wymagań systemowych w
języku 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ść”
Specyfikacje wymagań są zbyt elastyczne. Tę samą rzecz można wyrazić
na kilka sposobów. 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 37
Notacje specyfikacji wymagań
Notacja
Opis
Strukturalny język
naturalny
To podejście polega na definiowaniu standardowych formularzy
i szablonów do wyrażania specyfikacji wymagań
Języki opisu
projektu
W tym 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
Do definiowania wymagań funkcjonalnych stawianych systemowi używa
się języka graficznego z tekstowymi dopiskami. Ostatnio używa się
przypadków użycia (Jacobsen i inni,1993).
Specyfikacje
matematyczne
Są to notacje oparte na pojęciach matematycznych, takich jak skończone
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 38
Strukturalny język naturalny




Strukturalny język naturalny jest ograniczoną postacią języka
naturalnego, przeznaczoną do zapisywania wymagań
systemowych.
Zaleta tego podejścia jest to, że zachowując wyrazistość i
zrozumiałość języka naturalnego potrafi zapewnić w
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 39
Formularz do definiowania
wymagań funkcjonalnych






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.
Jeśli użyto podejścia funkcjonalnego, to należy określić
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 40
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 41
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). 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. PDL umożliwia definiowanie typów i obiektów
interfejsowych.
©Ian Sommerville 2000
Inżynieria oprogramowania,, Rozdział 5
Slide 42
Część opisu 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 43
Pewne wady użycia PDL do
specyfikowania wymagań
1.
2.
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.
©Ian Sommerville 2000
Inżynieria oprogramowania,, Rozdział 5
Slide 44
Specyfikacja interfejsów


Większość systemów oprogramowania musi współdziałać z innymi
systemami, które już zaimplementowano i zainstalowano w ich
środowisku. Taka sytuacja 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.
©Ian Sommerville 2000
Inżynieria oprogramowania,, Rozdział 5
Slide 45
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 46
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ółową 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 47
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ń
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 ją 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 49
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
©Ian Sommerville 2000
Inżynieria oprogramowania,, Rozdział 5
Slide 50
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 51
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 52
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ć za pomocą
jakiegoś języka strukturalnego.
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.
©Ian Sommerville 2000
Inżynieria oprogramowania,, Rozdział 5
Slide 53