©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
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 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

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 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 (być może)

Architekci systemu

Twórcy oprogramowania

©Ian Sommerville 2000

Inżynieria oprogramowania,, Rozdział 5

Slide 10

Wymagania stawiane 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

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

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 14

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 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 klienta i w firmie

wytwórcy.



Wymagania zewnętrzne

•

Ta szeroka kategoria mieści wszystkie wymagania

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

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

systemami innych firm i wymagania prawne.

©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

•

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.



Wymaganie organizacyjne

•

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 19

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 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

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 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

Przykład: wymagania stawiane
systemowi biblioteki

1.

Wszystkie bazy danych powinny być dostępne

przez jednolity interfejs użytkownika, którego

podstawą jest standard Z39.50.

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 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 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

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 30

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 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 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 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 37

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 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.

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.



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 40

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 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). 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 43

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 44

Pewne wady użycia PDL do
specyfikowania wymagań

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, ale można ją połączyć z
użyciem strukturalnego języka
naturalnego.

©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. 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 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ółową specyfikacje wymagań systemowych



Nie jest projektem. Powinna opisywać co system

ma robić, a nie jak to robić.

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 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 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

©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ć 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.