Inżynieria wymagań I

Ian Sommerville

Software Engineering, 9.

wyd.

Zawartość



Wymagania funkcjonalne i
niefunkcjonalne



Dokumentowanie wymagań



Specyfikacja wymagań



Proces inżynierii wymagań



Wydobywanie i analizowanie wymagań



Zatwierdzanie wymagań



Zarządzanie wymaganiami

Inżynieria wymagań



Proces ustalenia, analizowania oraz

dokumentowania usług i

ograniczeń stawianych

oprogramowaniu.



Same wymagania to opis usług i

ograniczeń oprogramowania

ustalonych w procesie inżynierii

wymagań.



W przemyśle informatycznym

pojęcie wymagania nie jest

stosowane konsekwentnie.

Czym jest wymaganie?



Z jednej strony, wymagania mogą być
postrzegane jako zapisane na wysokim
poziomie, abstrakcyjne określenie usług
oferowanych przez system albo ograniczeń
działania systemu.



Z drugiej strony, wymagania można
postrzegać jako szczegółową matematycznie
formalną definicję funkcji i ograniczeń
systemu.



Wybór jednego z powyższych poziomów opisu
zależy od kontekstu, w jakim sformułowano
wymagania.

Rodzaje wymagań (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łnienia
oczekiwań firmy zamawiającej. Gdy kontrakt jest już
podpisany, wykonawca musi zapisać dla klienta
dokładniejszą definicję systemu, podając więcej
szczegółów, aby klient mógł zrozumieć i
zweryfikować działanie systemu. Oba te dokumenty
mogą nosić nazwę dokumentacji wymagań
stawianych systemowi.

Rodzaje wymagań



Wymagania użytkownika



Opis w języku naturalnym oraz przy
użyciu diagramów usług i ograniczeń
systemu.



Wymagania systemowe



Szczegółowo definiują wymagania
użytkownika. Mogą służyć jako część
kontraktu między nabywcą systemu, a
jego wytwórcą.

Wymagania użytkownika i
wymagania systemowe

Definicja wymagań użytkownika

Specyfikacja wymagań systemowych

1.

System powinien generować miesięczny raport zawierający

sumaryczny koszt lekarstw zapisanych przez każdą przychodnię

obsługiwaną przez system

1.1

Ostatniego roboczego dnia każdego miesiąca należy wygenerować spis

wszystkich przepisanych leków i ich koszt . Z każdym lekiem należy związać

listę przychodni, które zapisywały ten lek.

1.2

O 17:30 ostatniego dnia miesiąca należy przygotować wydruk miesięcznego

raportu.

1.3

W raporcie, dla każdej przychodni należy podać : listę leków, które zostały

zapisane, liczbę przepisanych porcji każdego leku, i całkowity koszt każdego

leku.

1.4

Powyższe informacje należy rozdzielić na poszczególne dawki leku.

1.5

Dostęp do informacji o lekach będzie ograniczony do autoryzowanych

użytkowników.

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

Wymagania funkcjonalne i
niefunkcjonalne



Wymagania funkcjonalne



Określają, jakie usługi ma ofiarować system, jak ma

reagować na określone dane wejściowe oraz jak ma się

zachowywać w określonych sytuacjach. W niektórych

przypadkach mogą określać, czego system nie powinien

robić.



Wymagania niefunkcjonalne



Ograniczają usługi i funkcje systemu. Obejmują

ograniczenia czasowe, sprzętowe, ograniczenia dotyczące

procesu tworzenia, standardy itp.



Wymagania dziedzinowe



Odzwierciedlają charakterystykę dziedziny systemu. Mogą

być funkcjonalne lub niefunkcjonalne.

Wymagania funkcjonalne



Opisują funkcjonalność lub usługi, które
system powinien oferować.



Zależą od rodzaju tworzonego
oprogramowania oraz spodziewanych
użytkowników.



Jeśli mają postać wymagań
użytkownika, ich opis jest stosunkowo
ogólny.



Jeśli są to wymagania systemowe,
szczegółowo definiują funkcje systemu,
jego wejścia, wyjścia, wyjątki itp.

Wymagania funkcjonalne (system
zarządzania przychodniami
leczniczymi

)



Użytkownik będzie mógł przeszukiwać
listy przyjęć we wszystkich
przychodniach.



Każdego dnia rano system będzie
generował, dla każdej przychodni, listę
zapisanych na ten dzień pacjentów.



Każdy użytkownik systemu będzie
identyfikowany przy użyciu 8-cyfrowego
numeru.

Niejednoznaczność
wymagań



Wymagania są często niejednoznaczne.



Często wykonawca sam rozwiązuje
niejednoznaczność tak, aby implementacja była
łatwiejsza.



Słowo „przeszukiwać” w wymaganiu pierwszym.



Intencja użytkownika: podaj nazwisko pacjenta
i szukaj



Interpretacja zespołu wytwórczego: wybierz
przychodnię, nazwiska pacjenta i szukaj

Kompletność i spójność
wymagań



Wymagania powinny być kompletne i spójne.



Kompletność:



Wszystkie potrzebne użytkownikowi usługi
powinny być zdefiniowane



Spójność:



Wymagania nie powinny mieć sprzecznych
definicji



W praktyce w wypadku wielkich systemów
osiągnięcie kompletności i spójności jest
niemożliwe.

Wymagania
niefunkcjonalne



Definiują właściwości systemu, takie jak

niezawodność, czas reakcji, wymagania

pamięciowe.



Mogą także definiować ograniczenia systemu, takie

jak możliwości urządzeń wejścia-wyjścia,

reprezentacje danych używane przez interfejsy

systemu, język programowania, metodologia

tworzenia oprogramowania.



Wymagania niefunkcjonalne na ogół dotyczą

całości systemu, a nie jego poszczególnych funkcji.

Oznacza to, że są one bardziej istotne niż

wymagania funkcjonalne. Niespełnienie wymagania

niefunkcjonalnego może często spowodować, że

system staje się całkowicie bezużyteczny.

Funkcjonalne vs.
niefunkcjonalne wymagania



Na ogół łatwo ustalić komponent systemu realizujący
konkretne wymaganie funkcjonalne.



W przypadku wymagania niefunkcjonalnego może to być
dużo trudniejsze.



Wymaganie niefunkcjonalne na ogół dotyczy wielu
komponentów. Na przykład wymogi niezawodności
systemu mogą wymuszać minimalizację komunikacji
pomiędzy komponentami.



Pojedyncze wymaganie niefunkcjonalne może generować
wiele wymagań funkcjonalnych. Np. wymóg
bezpieczeństwa systemu może wymusić konieczność
zapewnienia przywracania systemu.

Typy wymagań
niefunkcjonalnych

Wymagania

niefunkcjonalne

Wymagania
produktowe

Wymagania

organizacyjne

Wymagania
zewnętrzne

Wymagania produktowe



Określają zachowanie produktu.



Wymagania sprawnościowe. Dotyczą szybkości
działania produktu i jego zapotrzebowania na
pamięć.



Wymagania niezawodności. Dotyczą miar
związanych z awariami i dostępnością, np.
prawdopodobieństwa awarii przy zleceniu,
częstotliwości występowania awarii, średniego czasu
do awarii lub dostępności usługi.



Wymagania przenośności. Dotyczą możliwości
użycia systemu na różnych platformach
sprzętowych i systemach operacyjnych.



Wymagania użytkowe. Dotyczą wizualnych
aspektów oprogramowania, takich jak estetyka
interfejsu.

Wymagania organizacyjne



Wynikają ze strategii i procedur w firmie klienta i
firmie wytwórcy.



Wymagania standardów. Dotyczą standardów
obowiązujących w firmie, takich jak wygląd
interfejsu czy schematu dokumentacji.



Wymagania implementacyjne. Dotyczą
aspektów związanych z implementacją
systemu, takich jak język programowania czy
metoda projektowania.



Wymagania dostawy. Określają termin
dostarczenia oprogramowania i dokumentacji.

Wymagania zewnętrzne



Ta szeroka kategoria mieści wszystkie
wymagania wynikające z czynników
zewnętrznych dla systemu i procesu jego
tworzenia.



Wymagania współpracy. Definiują interakcje systemu
z systemami innych firm.



Wymagania prawne. Definiują wymagania, które
należy spełnić, aby system działał zgodnie z prawem,
takie jak ochrona prywatności czy wymagania
zabezpieczeń.



Wymagania etyczne. Zapewniają akceptację
systemu przez jego użytkowników i społeczeństwo.

Przykłady wymagań
niefunkcjonalnych



Wymaganie produktowe



System musi być dostępny od poniedziałku do

piątku od 8:00 do 20:00, a czas przestoju

systemu nie może przekroczyć 60 sekund

(wymaganie niezawodności)



Wymaganie organizacyjne



Końcowa dokumentacja powinna być zgodna

ze standardem D-STAN-35 (wymaganie

standardowe)



Wymaganie zewnętrzne



System nie powinien ujawniać poufnych

danych osobowych klientów (wymaganie

prawne)

Cele i wymagania



Wymagania niefunkcjonalne mogą być trudne do
formalnego zdefiniowania i często trudno je
zweryfikować.



Cel



Ogólna intencja użytkownika, np. łatwość
użycia



Weryfikowalne wymaganie niefunkcjonalne



Wymaganie zawierające jakąś miarę, którą
można przetestować



Cele, choć na ogół mało precyzyjne, są
wartościowe, ponieważ opisują ogólną intencję
użytkownika.

Cel i weryfikowalne
wymaganie



Cel systemu



System powinien być łatwy w użyciu dla
doświadczonych kontrolerów, a sposób jego
organizacji powinien minimalizować liczbę błędów
użytkownika.



Weryfikowalne wymaganie niefunkcjonalne



Doświadczeni użytkownicy powinni móc używać
wszystkich funkcji systemu po szkoleniu
trwającym 4 godziny. Po tym szkoleniu średnia
liczba błędów robionych przez doświadczonych
użytkowników nie powinna przekroczyć dwóch
dziennie

Miary do specyfikowania
wymagań niefunkcjonalnych

Właściwość

Miara

Szybkość

Liczba przetworzonych transakcji na sekundę

Czas reakcji na zdarzenie wywołane przez

użytkownika

Czas odświeżenia ekranu

Rozmiar

Kilobajty

Liczba układów pamięci RAM

Łatwość

użycia

Czas szkolenia

Liczba okien pomocy

Niezawodność Średni czas bez awarii

Częstość błędów

Prawdopodobieństwo niedostępności usługi

Solidność

Czas uruchomienia po awarii

Prawdopodobieństwo zniszczenia danych po awarii

Przenośność

Procent poleceń zależnych od platformy

Liczba docelowych platform sprzętowych

Wymagania dziedzinowe



Wynikają z dziedziny zastosowania systemu



Na przykład system wspomagający pracę
maszynisty musi uwzględnić różne
charakterystyki hamowania w zależności od
warunków atmosferycznych



Wymagania dziedzinowe mogą być nowymi
wymaganiami funkcjonalnymi, mogą
ograniczać istniejące wymagania funkcjonalne
lub ustalać sposób wykonywania konkretnych
obliczeń.



Jeśli wymagania dziedzinowe nie są spełnione,
system może się nie nadawać do użycia.

System bezpieczeństwa
ruchu pociągów



Tempo hamowania pociągu wyraża się wzorem

D

pociągu

= D

sterowania

+ D

nachylenia

przy czym

D

nachylenia

= 9.81*α, gdzie α zależy od

typu pociągu



Dla niespecjalisty powyższy wzór może być mało
zrozumiały. Ponadto może nie być jasne, jak wzór
oddziałuje na inne wymagania

Problemy z wymaganiami
dziedziny



Zrozumiałość



Wymagania dziedziny są często
wyrażane w języku tej dziedziny. Ten
język może być niezrozumiały dla
twórców systemu



Domyślność



Eksperci dziedziny dobrze ją
rozumieją. Dlatego może im nie
przyjść do głowy, aby pewne fakty
sformułować explicite.

Dokumentacja wymagań
stawianych oprogramowaniu



Dokumentacja wymagań (specyfikacja

wymagań) jest oficjalną deklaracją tego, co

jest wymagane od wytwórców

oprogramowania.



Powinna zawierać zarówno wymagania

użytkownika, jak i szczegółowy opis wymagań

systemowych.



Wymagania użytkownika stanowią na ogół

wstęp do wymagań systemowych.

Dokumentacja wymagań nie jest dokumentem

projektowym!! Powinna opisywać usługi

systemu, nie precyzując jak mają być

zrealizowane.

Wymagania w metodach
zwinnych



Większość metod zwinnych zakłada, że

dokumentacja wymagań jest zbędna,

ponieważ często się zmieniają.



Metody zwinne realizują przyrostową inżynierię

wymagań.



Takie rozwiązanie może być słuszne w

przypadku niewielkich systemów o charakterze

technologiczno-biznesowym. Staje się jednak

problematyczne w przypadku systemów

wymagających głębokiej analizy przed budową

(systemy krytyczne) lub wielkich systemów

tworzonych przez wiele zespołów.

Użytkownicy dokumentacji
wymagań

Użytkownicy

Sposób korzystania

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
systemów

Używają wymagań jako pomocy w

zrozumieniu systemu i związków między
jego częściami

Różnorodność dokumentacji
wymagań



Wielu potencjalnych czytelników dokumentacji
wymagań sprawia, że musi ona być pewnym
kompromisem pomiędzy komunikowaniem wymagań
użytkownikom, a ich dokładną definicją potrzebną
osobom tworzącym, testującym i pielęgnującym
oprogramowanie.



Informacje zawarte w dokumentacji wymagań zależą
również od rodzaju oprogramowania oraz metodologii
jego wytwórstwa. Dokumentacja wymagań dla
systemów budowanych przyrostowo jest często niezbyt
precyzyjna.



Istnieją standardy dokumentowania wymagań.
(Departament Obrony Stanów Zjednoczonych, IEEE)

Struktura dokumentacji
wymagań (IEEE 1998)

Rozdział

Opis

Przedmowa Należy w niej określić, dla jakich czytelników jest ten

dokument oraz opisać historię jego wersji wraz z

uzasadnieniem ich tworzenia oraz zmian wprowadzonych w

kolejnych wersjach

Wstęp

Należy w niej wyjaśnić, dlaczego ten system jest potrzebny.

Należy krótko opisać usługi systemu i sposób jego

współpracy z innymi systemami. Należy również wyjaśnić,

jak system przystaje do celów gospodarczych i

strategicznych firmy, która go kupuje.

Słownik

Należy tu zdefiniować techniczne pojęcia występujące w

dokumencie. Nie należy nic zakładać o doświadczeniu i

wiedzy czytelnika

Opis

wymagań

użytkownik

a

W tym punkcie należy opisać usługi dostarczane

użytkownikowi i wymagania niefunkcjonalne systemu. W

opisie można się posłużyć językiem naturalnym,

diagramami lub inną notacją zrozumiałą dla klientów.

Powinno się też określić wymagane standardy dotyczące

produktu i/lub procesu.

Struktura dokumentacji
wymagań (IEEE 1998)

Rozdział

Opis

Architektu

ra

systemu

W tym rozdziale należy podać krótki opis architektury

systemu z uwzględnieniem zależności pomiędzy

konkretnymi usługami a konkretnymi komponentami.

Należy wizualnie wyróżnić komponenty wielokrotnego

użycia.

Wymagan

ia

systemow

e

Tu należy bardziej szczegółowo opisać wymagania

funkcjonalne i niefunkcjonalne. Jeśli jest to konieczne

pewne wymagania niefunkcjonalne mogą zostać

uszczegółowione poprzez wprowadzenie miar.

Modele

systemu

Tu należy podać jeden lub więcej modeli systemu, w

których odzwierciedlono związki między systemem, jego

komponentami oraz środowiskiem. Mogą to być modele

obiektowe, modele przepływu danych lub modele

semantyczne.

Struktura dokumentacji
wymagań (IEEE 1998)

Rozdział

Opis

Ewolucja

systemu

Powinno się tu opisać główne założenia systemu i

przewidywane modyfikacje, które mogą wystąpić w

wyniku ewolucji sprzętu, zmiany potrzeb użytkowników

itd.

Dodatki

Należy tu przedstawić szczegółową, specyficzną

informację związaną z budowanym oprogramowaniem.

Przykładami dodatków są opisy sprzętu i opisy bazy

danych. W wymaganiach sprzętowych definiuje się

konfigurację minimalną i optymalną. W wymaganiach

bazy danych określa się logiczną organizację danych

używanych przez system i związki między tymi danymi

Skorowidz

Do dokumentu można dołączyć kilka skorowidzów.

Oprócz skorowidza alfabetycznego może to być

skorowidz diagramów, skorowidz usług itd.

Specyfikacja wymagań



Specyfikacja wymagań jest to proces

sformułowania funkcjonalnych i

niefunkcjonalnych wymagań systemu i

zapisania ich w dokumentacji wymagań.



Wymagania użytkownika powinny być

zrozumiałe dla osób bez przygotowania

technicznego.



Wymagania systemowe mogą być bardziej

formalne i mogą zawierać informacje

techniczne.



Dokumentacja wymagań stanowi często jeden

z fragmentów umowy między zleceniobiorcą i

zleceniodawcą. Dlatego ważna jest jej

kompletność.

Notacje specyfikacji
wymagań

Notacja

Opis

Język

naturalny

Wymagania zapisujemy używając numerowanych zdań w

języku naturalnym. Jedno zdanie odpowiada jednemu

wymaganiu.

Strukturalny

język

naturalny

Używamy języka naturalnego, ale używamy standardowych

formularzy do wyrażania wymagań. Każde pole formularza

dotyczy jednego aspektu opisu wymagania

Języki opisu

projektu

W tym podejściu używa się języka podobnego do języka

programowania, ale bardziej abstrakcyjnego. Notacja rzadko

używana, choć dobrze nadaje się do specyfikowania interfejsu

Notacje

graficzne

Wymagania zapisujemy w postaci diagramów. Obecnie

najbardziej znaną notacją graficzną są diagramy przypadków

użycia w języku UML

Specyfikacje

matematyczn

e

Są to notacje czysto formalne oparte na pojęciach

matematycznych takich jak maszyny stanowe czy zbiory.

Zapewniają jednoznaczność specyfikacji. Większość klientów

nie rozumie jednak formalnych specyfikacji i jest niechętna

przyjęciu ich jako fragmentu kontraktu na budowę

oprogramowania.

Wymagania i
projektowanie



Wymagania i projekt powinny być odseparowane.

Wymagania definiują usługi systemu, projekt

wskazuje, jak te usługi zostaną zrealizowane.



W praktyce rozdzielenie wymagań od projektu

jest bardzo trudne



Szkic architektury systemu może być

konieczny, aby ustrukturalizować wymagania



System może współpracować z innymi

systemami, co może prowadzić do wymagań

architektonicznych.



Użycie konkretnej architektury może wynikać z

wymagań dziedziny lub regulacji zewnętrznych

Wymagania w języku
naturalnym



Używamy języka naturalnego wspomaganego
tabelami, diagramami itp.



Język naturalny jest prawie zawsze używany w
przypadku wymagań użytkownika. Często
używa się go również do zapisu wymagań
systemowych.



Atrakcyjność języka naturalnego jako
narzędzia do opisu wymagań wynika z jego
uniwersalności intuicyjności i ogromnej sile
ekspresji.

Wskazówki dotyczące
definiowania wymagań w języku
naturalnym



Przyjmij jakiś standardowy format i używaj go

do opisu wszystkich wymagań.



Używaj języka w sposób spójny. Rozróżniaj

pomiędzy „powinien” (dotyczy pożądanych

wymagań) i „będzie” (dotyczy obligatoryjnych

wymagań).



Wyróżniaj najważniejsze fragmenty tekstu

(kursywa, pogrubienie, kolor itp.)



Unikaj żargonu informatycznego.



Jeśli możliwe, uzasadniaj dlaczego dane

wymaganie jest ważne.

Wady języka naturalnego
jako notacji do opisu
wymagań



Brak jednoznaczności



Bardzo trudno o precyzję, jeśli dokument

ma być łatwy do czytania.



Zrozumienie języka naturalnego w

ogromnej mierze zależy od tego, czy

czytelnicy autorzy specyfikacji używają

tych samych słów do oznaczenia tych

samych pojęć



Istnieje tendencja mieszania wymagań

funkcjonalnych z niefunkcjonalnymi.



Tendencja do łączenia



Często następuje nieświadome złączenie

kilku wymagań w jedno

Przykładowe wymagania
dotyczące pompy insulinowej

3.2 System będzie mierzył poziom cukru we krwi

co 10 minut i jeśli potrzeba wstrzykiwał insulinę.

(Zmiany poziomu cukru są relatywnie wolne,

zatem nie ma potrzeby mierzyć częściej.

Rzadsze pomiary mogłyby spowodować zbytnie

podwyższenie poziomu cukru.)

3.5 Co 1 minutę system będzie przeprowadzał

test aparatury i podejmował ewentualne

działanie, jak opisano w Tabeli 1. (To pozwoli

poinformować użytkownika o ewentualnej awarii

pompy.)

Strukturalny język naturalny
do opisu wymagań



Istotą tego podejścia jest
standaryzacja definiowania
wymagań poprzez stosowanie
odpowiednich formularzy.



To podejście dobrze działa dla
pewnych zastosowań, na przykład
w przypadku systemów
wbudowanych. Dla wielu
systemów o charakterze
biznesowym podejście to jest zbyt
sztywne.

Zawartość formularza
definiującego wymaganie



Opis specyfikowanej funkcji lub bytu



Opis jej danych wejściowych i źródło ich
pochodzenia



Opis jej danych wyjściowych i źródło ich
przeznaczenia



Określenie innych bytów z których korzysta funkcja
specyfikowana



Warunek początkowy, który musi być spełniony
przed wywołaniem funkcji (jeśli się stosuje)



Warunek końcowy, który będzie zachodził po
wywołaniu funkcji (jeśli się stosuje)



Opis efektów ubocznych (jeśli występują)

Specyfikacja wymagania dla
pompy insulinowej z użyciem
formularza

Pompa insulinowa W 3.2
Funkcja Oblicz dawkę

Opis Oblicza dawkę insuliny do podania w przypadku kiedy aktualny poziom

cukru we krwi jest w bezpiecznej strefie między 3 i 7 jednostek

Wejście Bieżący odczyt cukru (r2) i dwa odczyty poprzednie, r0 i r1

Źródło Źródłem r2 jest sensor; r0 i r1 pochodzą z pamięci pompy

Wyjście CompDose – dawka insuliny do wstrzyknięcia

Przeznaczenie Główna pętla sterująca pompą

Działanie Jeśli poziom cukru jest stabilny lub się obniża lub się podwyższa, ale

szybkość podwyższania się spada, to CompDose=0. W przeciwnym przypadku

podziel różnicę pomiędzy obecnym i poprzednim poziomem cukru przez 4 i

zaokrąglij do liczby całkowitej. Jeśli otrzymałeś 0, to CompDose= minimalna

dawka, którą można podać

Wymagania Dwa poprzednie odczyty

Warunek wstępny Zbiornik pompy zawiera co najmniej maksymalną

możliwą dawkę insuliny

Warunek końcowy r0 zostaje zastąpione przez r1; r1 zostaje zastąpione

przez r2

Efekty uboczne Brak

Tabelaryzacja specyfikacji



Uzupełnia tekst w języku naturalnym.



Szczególnie przydatna w przypadku,
kiedy mamy do czynienia z wieloma
alternatywnymi działaniami.



Pompa insulinowa opiera swoje
obliczenia na trzech pomiarach poziomu
cukru we krwi. Użycie tabeli znacznie
upraszcza rachunki opisane w języku
naturalnym.

Tabelaryczna specyfikacja
obliczenia dla pompy
insulinowej

Warunek

Działanie

Opadający poziom cukru (r2<r1)

CompDose=0

Stabilny poziom cukru (r2=r1)

CompDose=0

Poziom cukru rosnący i szybkość

wzrostu malejąca (r2>r1) i (r2-

r1)<(r1-r0)

CompDose=0

Poziom cukru rosnący i szybkość

wzrostu rosnąca lub stabilna

(r2>r1) i (r2-r1)≥(r1-r0)

CompDose= round((r2-r1)/4)

If CompDose=0 then

CompDose=MinDose

Podsumowanie



Wymagania definiują usługi systemu i właściwości
jakim musi podlegać.



Wymagania funkcjonalne określają usługi systemu.



Wymagania niefunkcjonalne określają właściwości
systemu.



Dokumentacja wymagań (specyfikacja wymagań)
jest oficjalną deklaracją tego, co jest wymagane od
wytwórców systemu. Powinna zawierać zarówno
wymagania użytkownika, jak i szczegółowy opis
wymagań systemowych.



Podstawowe notacje do opisu wymagań to język
naturalny, strukturalny język naturalny, języki opisu
projektu, notacje graficzne i języki formalne.

Inżynieria wymagań II

Ian Sommerville

Software Engineering, 9.

wyd.

Proces inżynierii wymagań



Procesy inżynierii wymagań mogą się różnić w zależności od
dziedziny tworzonego oprogramowania, przyjętej metodologii
tworzenia i firmy tworzącej. Tym niemniej cztery czynności
występują w każdym takim procesie.



Studium wykonalności – czy warto zaczynać budowę
systemu?



Określenie i analizowanie wymagań – wyodrębnienie
wszystkich istotnych wymagań



Specyfikowanie wymagań – zapisanie wyodrębnionych
wymagań w jakiejś standardowej postaci



Zatwierdzenie wymagań -- sprawdzenie, że wymagania
definiują system oczekiwany przez klienta

(Uproszczony) proces
inżynierii wymagań

Studium

wykonalności

Określania

I analiza

wymagań

Specyfikowanie

wymagań

Zatwierdzanie

wymagań

Raport o

wykonalności

Model

systemu

Wymagania użytkownika

I wymagania systemowe

Dokumentacja

wymagań

Studium wykonalności



Punktem startowym tego etapu jest ogólny opis systemu i jego
wykorzystanie w ramach przedsiębiorstwa zleceniodawcy.



Wynikiem studium wykonalności jest raport, który zaleca lub
odradza kontynuowanie prac związanych z procesem tworzenia
systemu. W raporcie można też zaproponować zmiany zakresu
systemu, budżetu lub harmonogramu.



W trakcie tego etapu należy odpowiedzieć na trzy pytania



Czy system przyczyni się do realizacji zakładanych celów
przedsiębiorstwa?



Czy system można zbudować z użyciem dostępnych
technologii, w ramach ustalonego budżetu i ograniczeń
czasowych?



Czy system może być zintegrowany z istniejącymi
systemami, które już zainstalowano?

Określanie i analizowanie
wymagań



W trakcie tego etapu inżynierowie budowy

oprogramowania pracują z klientami i

użytkownikami systemu nad badaniem

dziedziny zastosowania i usług, które system

ma oferować, pożądanej efektywności,

wymagań sprzętowych itd.



W etapie tym biorą udział osoby z różnych

stanowisk w firmie zlecającej: użytkownicy,

którzy będą pracować z systemem,

inżynierowie budujący lub pielęgnujący inne

powiązane systemy, menedżerowie

przedsiębiorstwa, eksperci z różnych dziedzin.

Wszystkie te osoby nazywamy

użytkownikami.

Problemy związane z
określaniem i analizą
wymagań



Użytkownicy często nie wiedzą czego oczekują od

systemu poza ogólnikami. Mogą stawiać nierealne

żądania efektywnościowe lub dotyczące kosztu.



Użytkownicy często używają własnej technicznej

terminologii.



Wymagania stawiane przez różnych użytkowników są

często sprzeczne.



Czynniki polityczne w firmie mogą mieć wpływ na

system. Mogą pochodzić od menedżerów żądających

konkretnych wymogów, które umożliwią zwiększenie ich

wpływów.



Środowisko ekonomiczne i gospodarcze, w którym

prowadzi się analizę jest dynamiczne. Mogą się pojawić

nowe wymagania pochodzące od nowych użytkowników.

Określanie i analiza
wymagań



Proces określania i analizy wymagań
może się nieznacznie różnić w różnych
firmach. Tym niemniej powinien
zawierać następujące etapy:



Rozpoznanie wymagań



Klasyfikacja i organizacja wymagań



Nadawanie priorytetów i usuwanie
sprzeczności



Specyfikacja wymagań

Proces określania i analizy
wymagań

Rozpoznanie

wymagań

Klasyfikacja

i organizacja

wymagań

Nadawanie priorytetów

i usuwanie sprzeczności

Specyfikacja
wymagań

Etapy procesu



Rozpoznanie wymagań



Współpraca z użytkownikami w celu rozpoznania

ich wymagań. Na tym etapie zbiera się również

wymagania dotyczące dziedziny.



Klasyfikacja i organizacja wymagań



Polega na podzieleniu nieustrukturalizowanego

zbioru wymagań na spójne grupy



Nadawanie priorytetów i usuwanie

sprzeczności



Wymagania formułowane przez wielu użytkowników

są zazwyczaj sprzeczne. Nadanie priorytetów

poszczególnym wymaganiom pozwala te

sprzeczności usunąć. Etap ten wymaga na ogół

negocjacji z użytkownikami.



Specyfikacja wymagań



Udokumentowanie dotychczas rozpoznanych

wymagań

Rozpoznanie wymagań



Rozpoznanie (wydobycie) wymagań polega na
zbieraniu informacji o tworzonym systemie i
podobnych działających systemach oraz użycie
tej informacji w celu zdefiniowania wymagań
użytkownika i wymagań systemowych.



Źródłem informacji służącej do specyfikacji
wymagań są użytkownicy oraz dokumentacje
podobnych

systemów informatycznych.

Użytkownicy systemu
wspomagającego pracę kliniki
medycznej



Pacjenci, których dane znajdują się w systemie.



Lekarze odpowiedzialni za diagnozowanie i leczenie
pacjentów.



Pielęgniarki koordynujące konsultacje pacjentów z
lekarzami i wykonujące zabiegi.



Pracownicy rejestracji zapisujący pacjentów na wizyty.



Zespół techniczny odpowiedzialny za zarządzanie
sprzętem i oprogramowaniem w klinice.



Osoba odpowiedzialna za przestrzeganie norm
etycznych związanych z pacjentami.



Dyrekcja kliniki, wykorzystująca system do zarządzania
kliniką.



Zespół archiwizujący odpowiedzialny za
przechowywanie informacji

Rozmowy z użytkownikami



Mniej lub bardziej formalne rozmowy z
użytkownikami są częścią większości procesów
inżynierii wymagań.



Rodzaje rozmów



Zamknięte, oparte na liście wcześniej
przygotowanych pytań



Otwarte, gdzie pytania tworzone są dynamicznie



Cechy dobrego prowadzenia rozmowy



Otwartość na nowe pomysły, umiejętność
słuchania innych



Umiejętne zachęcanie do dyskusji (poprzez
formułowanie ciekawych pytań lub precyzowania
gotowych wymagań).

Rozmowy w praktyce



W praktyce rozmowy z użytkownikami są
mieszanką rozmów zamkniętych i otwartych.



Rozmowy stanowią dobrą technikę uzyskania
ogólnego obrazu na temat działalności
użytkowników i ich potencjalnej interakcji z
systemem.



Rozmowy nie są dobrym narzędziem do
wyrobienia opinii o wymaganiach dziedziny

.



Eksperci z firmy zamawiającej na ogół używają
terminologii niezrozumiałej dla osób z zewnątrz



Co gorsze, na ogół nie są w stanie tego zmienić

Scenariusze



Scenariusze modelują rzeczywiste użycie

systemu.



Są szczególnie przydatne przy

uszczegółowianiu istniejących wymagań.



Scenariusz powinien opisywać jedną

(wyjątkowo kilka) interakcji użytkownik-

system.



Scenariusz powinien zawierać:



Opis stanu systemu na początku

scenariusza



Opis normalnego następstwa zdarzeń

scenariusza



Opis tego, co może pójść źle, i jak to jest

obsługiwane



Informacje o innych czynnościach, które

można wykonywać w tym samym czasie



Opis stanu systemu po zakończeniu

scenariusza

Scenariusz edycji karty
pacjenta



Stan początkowy. Pacjent widział jak rejestratorka
tworzy jego kartę choroby, wprowadzając dane
osobowe: imię, nazwisko, adres itd. Do systemu
zalogowana jest aktualnie pielęgniarka, której zadaniem
jest uzupełnienie karty o dane medyczne.



Działanie normalne. Pielęgniarka wyszukuje kartę
pacjenta posługując się nazwiskiem. W przypadku kilku
pacjentów o tym samym nazwisku, bierze pod uwagę
imię i ewentualnie datę urodzenia.

Po znalezieniu karty pacjenta, pielęgniarka wybiera

zakładkę

„dodaj informacje medyczne”.

Scenariusz edycji karty
pacjenta



Działanie normalne (cd.) Wybierając odpowiednie
zakładki, pielęgniarka wprowadza różne informacje:
informacje dotyczące aktualnego stanu pacjenta
(formularz), konsultacje w innych klinikach (formularz),
alergie (zwykły tekst), lista przyjmowanych leków
(wybór z listy)



Co może się nie udać. W bazie nie ma karty pacjenta.
Pielęgniarka powinna utworzyć nową kartę i zapisać w
niej dane osobowe.

Lek przyjmowany przez pacjenta nie znajduje się na
liście. Należy wybrać zakładkę „brak leku” i wpisać jako
zwykły tekst.

Scenariusz edycji karty
pacjenta



Co może się nie udać (cd.) Pacjent nie chce podać
istotnych informacji. Należy wydrukować standardowe
pismo o odmowie, które pacjent musi podpisać.



Inne czynności. Podczas wprowadzania informacji,
inne upoważnione osoby mogą przeglądać kartę
pacjenta, ale nie mogą jej edytować.



Stan końcowy. Użytkownik jest zalogowany. Dane
medyczne zostały wprowadzone. W rejestrze zdarzeń
systemu zapisano godzinę rozpoczęcia, godzinę
zakończenia sesji oraz identyfikator pielęgniarki
wprowadzającej dane.

Przypadki użycia



Wchodzą w skład języka UML. Stanowią bardzo
popularną graficzną technikę rozpoznawania
wymagań.



W najprostszej postaci przypadek użycia
definiuje aktora zaangażowanego w interakcję
z systemem nadaje tej interakcji nazwę. Aktor
to człowiek lub inny system.



Nie ma jednoznacznej zgody, czy przypadek
użycia jest scenariuszem, czy zbiorem
scenariuszy.

Przypadki użycia kliniki
medycznej

Rejestratorka

Pielęgniarka

Lekarz

Kierownik

kliniki

Rejestracja

Ogląd danych

osobowych

Ogląd karty

pacjenta

Edycja karty

pacjenta

Zapis na

wizytę

Generowanie

karty wypisu

Generowanie

raportu

zewnętrznego

Etnografia



Systemy informatyczne nie istnieją w izolacji. Są
użytkowane w środowisku społecznym i organizacyjnym.



Etnografia to metoda obserwacji, która może służyć do
rozpoznawania wymagań społecznych i
organizacyjnych.



Zaletą etnografii jest to, że pomaga rozpoznać niejawne
wymagania systemowe odzwierciedlające rzeczywiste, a
nie formalne procesy, w których biorą udział ludzie.



Te niejawne wymagania są bardzo trudne do uzyskania
inną drogą niż obserwacja. Wynika to z faktu, że wiele
czynności związanych z pracą wykonuje się w sposób
automatyczny.

Zakres etnografii



Etnografia jest szczególnie przydatna do znajdowania dwóch

typów wymagań



Wymagania wynikające z rzeczywistego sposobu pracy osób,

a nie ze sposobu zalecanego przez formalne definicje

procesów. Kontrolerzy lotów mogą wyłączać pewne

podsystemy używanego systemu, pomimo, że procedury

tego zabraniają.



Wymagania, które wynikają z kooperacji i świadomości

czynności innych osób. Kontrolerzy lotów mogą

zmodyfikować swoją strategię na podstawie liczby

samolotów w sąsiednich sektorach. W takim przypadku

system kontroli lotów powinien umożliwiać kontrolerom

podglądanie sąsiednich sektorów.



Etnografia jest użyteczna, aby zrozumieć i poprawić szczegóły

istniejących procesów. Nie nadaje się do wykrycia zupełnie

nowych wymagań.

Zatwierdzanie wymagań



Polega na sprawdzeniu, że wymagania

definiują system zgodny z oczekiwaniami

klienta.



Koszt błędów związanych z wymaganiami jest

dużo większy niż błędy implementacyjne.

Dzieje się tak, ponieważ duże zmiany

wymagań często pociągają duże zmiany

projektowo-implementacyjne i dodatkowo

konieczność ponownego testowania.

Sprawdzanie wymagań



Trafność.

Czy zbiór wymagań jest optymalny z punktu

widzenia wszystkich użytkowników mających często różne ,
być może sprzeczne, potrzeby.



Niesprzeczność.

Czy istnieją konflikty pomiędzy

wymaganiami?



Kompletność.

Czy uwzględniono wszystkie istotne

wymagania?



Realność.

Czy zdefiniowane wymagania mogą być

zaimplementowane biorąc pod uwagę stan współczesnej
technologii oraz przeznaczony czas i budżet?



Weryfikowalność.

Czy opracowano metodę sprawdzenia, że

zdefiniowane wymagania zostały poprawnie
zaimplementowane?

Techniki zatwierdzania
wymagań



Przegląd wymagań.



Systematyczna ręczna analiza wymagań



Prototypowanie.



Konstruowanie wykonywalnego modelu

systemu



Generowanie testów.



Częścią zatwierdzania wymagań może być

przygotowanie testów dla wymagań. Jeśli

sprawia to trudność, istnieje duże

prawdopodobieństwo, że będą problemy w

czasie implementacji.

Przeglądy wymagań



Jest to ręczny proces, w którym przedstawiciele

klienta oraz wytwórców sprawdzają ręcznie

dokumentację wymagań w celu znalezienia błędów.



Przegląd powinien mieć miejsce od razu po

zdefiniowaniu wymagań.



Przeglądy mogą być nieformalne i formalne.



Podczas przeglądu nieformalnego wytwórcy

rozmawiają z jak największą grupą użytkowników.



W czasie przeglądu formalnego zespół wytwórczy

prezentuje klientowi wszystkie wymagania

systemowe i wyjaśnia konsekwencje każdego

wymagania.

Formalne przeglądy
wymagań



W czasie formalnego przeglądu wymagań, poza

niesprzecznością i kompletnością, należy

sprawdzić:



Możliwość weryfikacji.

Czy wymaganie

zdefiniowano tak, że będzie można je

sprawdzić?



Zrozumiałość.

Czy użytkownicy właściwie

zrozumieli wymaganie?



Pochodzenie.

Czy jawnie zaznaczono źródło, z

którego pochodzi wymaganie? Źródło może być

istotne, gdy chcemy ocenić wpływ zmiany.



Elastyczność.

Czy wymaganie może być

zmienione bez znaczącego wpływu na inne

wymagania?

Zarządzanie wymaganiami



Jest to proces rozpoznawania i panowania nad
zmianami wymagań systemowych.



Nowe wymagania mogą pojawić się w trakcie
tworzenia systemu i na ogół zawsze pojawiają
się w czasie jego użytkowania.



Należy ustawicznie śledzić powiązania
pomiędzy wymaganiami, aby je uwzględnić
przy zmianach.

Powody zmian wymagań



Z wielkich systemów korzystają na ogół różni

użytkownicy, przypisujący wymaganiom różne

priorytety. Ostateczne wymagania systemowe są z

konieczności pewnym kompromisem. W miarę

tworzenia/użytkowania systemu może się okazać, że

bilans wspomagania różnych użytkowników musi być

zmieniony.



Ludzie płacący za system i użytkownicy faktyczni to na

ogół różni klienci. Wymagania osób płacących mogą

być sprzeczne z wymaganiami użytkowników z powodu

ograniczeń organizacyjno-budżetowych.



Zmienia się otoczenie technologiczne i gospodarcze

mogące wymuszać zmiany wymagań.

Wymagania stałe i
zmienne



Wymagania stałe

to względnie stabilne

wymagania systemowe, które wynikają z

podstawowej działalności firmy i bezpośrednio

odnoszą się do dziedziny systemu. W szpitalu

zawsze będą wymagania dotyczące lekarzy,

pielęgniarek, pacjentów, terapii itp.



Wymagania zmienne

to wymagania, które

łatwo mogą ulec zmianie w trakcie tworzenia

systemu lub w trakcie jego pielęgnacji. Takimi

wymaganiami są na przykład wymagania,

które wynikają z polityki zdrowotnej rządu.

Ewolucja wymagań

Wstępne
rozumienie
problemu

Wstępne

wymagania

Zmienione

rozumienie

problemu

Zmienione
wymagania

Czas

Planowanie zarządzania
wymaganiami



W trakcie tej fazy zarządzania wymaganiami należy

podjąć decyzje dotyczące następujących zagadnień:



Identyfikowanie wymagań.

Każde wymaganie musi

być unikatowo oznakowane, tak aby można się było

do niego odwoływać.



Proces zarządzania zmianami.

Jest to zbiór czynności

szacowania wpływu i kosztu zmian.



Strategia śledzenia pochodzenia.

Definiują zależności

między wymaganiami oraz między wymaganiami a

systemem oraz sposób gromadzenia tych zależności.



Użycie narzędzi CASE.

Narzędzia, które mogą być

użyte to wyspecjalizowane systemy zarządzania

wymaganiami, arkusze kalkulacyjne czy proste bazy

danych.

Pochodzenie wymagań



Warto gromadzić trzy typy informacji o pochodzeniu
wymagań



Informacje o pochodzeniu

wiążą wymaganie z

użytkownikiem, które je zaproponował. Warto z nim
skonsultować zmianę.



Informacje o uzależnieniu wymagań

definiują związki

pomiędzy wymaganiami, które od siebie zależą. Ta
informacja pozwala oszacować koszt zmiany.



Informacje o uzależnieniu projektu

wiążą wymagania z

modułami, które je implementują. Ta informacja jest
używana do oszacowania wpływu zmian na projekt systemu
i jego implementację.

Zarządzanie zmianami
wymagań

Analiza problemu

i specyfikacja

zmiany

Analiza zmiany

i ocena kosztów

Implementacja

zmiany

Rozpoznany

problem

Skorygowane

wymagania

Zarządzanie zmianami
wymagań



Kroki procesu zarządzania zmianami



Analiza problemu i specyfikacja zmiany

. Proces

rozpoczyna się od rozpoznania problemu z

wymaganiem lub od konkretnej propozycji zmiany.

Postulat jest sprawdzany pod względem słuszności.



Analiza zmiany i ocena kosztów.

Korzystając z

informacji o uzależnieniu wymagania szacuje się

wpływ zmiany na system i jej koszt. W kroku tym

podejmuje się decyzję, czy kontynuować zmianę.



Implementacja zmiany.

Modyfikuje się dokumentację

wymagań oraz, jeśli potrzeba, również projekt i

implementację systemu.

Podsumowanie



Proces inżynierii wymagań ma charakter

iteracyjny. Składa się z określenia i analizy

wymagań, specyfikowania wymagań

,zatwierdzenia wymagań i zarządzania

wymaganiami.



Analizowanie wymagań obejmuje rozpoznanie

wymagań, ich klasyfikację i strukturalizację,

nadawanie priorytetów i usuwanie

sprzeczności.



Zatwierdzanie wymagań polega na

sprawdzeniu, że wymagania definiują system

zgodny z oczekiwaniami klienta.

Inżynieria wymagań III
(Specyfikacja formalna)

Ian Sommerville

Software Engineering, 9

wyd.

Zawartość



Specyfikacja formalna w procesie
tworzenia oprogramowania



Specyfikacja interfejsu



Specyfikacja zachowania

Metody formalne



Specyfikacja formalna wchodzi w skład
technik występujących pod nazwą metody
formalne.



Podstawą metod formalnych jest
matematyka.



Metody formalne obejmują kilka czynności
związanych z wytwarzaniem
oprogramowania

.



Formalne specyfikowanie systemu



Analizowanie i weryfikację specyfikacji



Proces tworzenia programowania z
przekształceniem



Dowodzenie poprawności programów

Metody formalne w inżynierii
oprogramowania



W latach osiemdziesiątych ubiegłego wieku panowało
przekonanie, że metody formalne wyprą inne techniki
wytwarzania oprogramowania. Tak się jednak nie stało.



Inne techniki okazały się skuteczne dla poprawienia jakości
oprogramowania (programowanie strukturalne, zarządzanie
konfiguracjami, ukrywanie informacji).



O ile kiedyś głównym problemem było zapewnienie jakości
oprogramowania, o tyle dzisiaj często ważniejsza jest
szybkość jego dostarczenia. Metody formalne zwiększają
czas utworzenia oprogramowania.



Zakres metod formalnych jest ograniczony. Metody te nie są
dobrze dostosowane do specyfikowania interfejsu
użytkownika, który jest kluczowy w wielu zastosowaniach.
Ponadto metody formalne nie skalują się dobrze.

Zakres metod formalnych



Główną korzyścią ze metod formalnych jest

redukcja błędów. Zaobserwowano to we

wszystkich udanych przedsięwzięciach, w

których zastosowano te metody.



Naturalną dziedziną dla metod formalnych jest

wytwórstwo systemów krytycznych.



Jest to prawdopodobnie jedyna dziedzina,

gdzie koszt błędów jest większy niż koszt

związany ze stosowaniem metod formalnych.

Specyfikowanie i
projektowanie

Rosnący udział zleceniobiorcy

Malejący udział klienta

Definiowanie

wymagań

użytkownika

Specyfikowanie

wymagań

systemowych

Projektowanie

architektury

Specyfikowanie

formalne

Projektowanie

szczegółowe

Specyfikowanie

Projektowanie

Zalety i wady specyfikacji
formalnej



W miarę opracowywania szczegółów

specyfikacji zwiększa się jej zrozumienie przez

autora. Skorzystanie ze specyfikacji formalnej

zmusza do drobiazgowej analizy systemu,

ponieważ wszystkie wymagania muszą być

opisane językiem formalnym o dobrze

zbadanych i zrozumiałych właściwościach

matematycznych.



Ta drobiazgowa analiza redukuje liczbę błędów

podczas specyfikowania systemu.



Wadą tego podejścia jest zwiększony koszt

specyfikowania, częściowo zredukowany

mniejszymi nakładami na zatwierdzanie

oprogramowania.

Koszty budowy oprogramowania ze
specyfikacją normalną

Koszt

S -- Specyfikowanie

S

PiI

Z

PiI

S

Z

PiI -- Projektowanie
i implementacja

Z -- zatwierdzanie

Bez specyfikacji formalnej

Ze specyfikacją formalną

Techniki specyfikacji
formalnej



Podejście algebraiczne



W którym zapisuje się system w
kategoriach operacji i ich związków



Podejście oparte na modelach



W którym buduje się model systemu
za pomocą pojęć matematycznych,
takich jak zbiory i ciągi. Operacje
systemu definiuje się przez
wywoływane przez nie zmiany stanu
systemu

Specyfikacja interfejsu



Wielkie systemy składają się z

podsystemów. Aby podsystemy te mogły

być budowane niezależnie wymagane są

interfejsy między nimi.



Interfejsy podsystemów zwykle definiuje

się jako zbiór abstrakcyjnych typów danych

lub obiektów, które opisują dane i operacje

dostępne przez interfejsy tych

podsystemów.



Jasne i jednoznaczne specyfikacje

interfejsów podsystemów zmniejszają

prawdopodobieństwo nieporozumień

między podsystemami oferującymi pewne

usługi a podsystemami korzystającymi z

tych usług.

Interfejsy podsystemów

Podsystem

A

Podsystem

B

Obiekty

interfejsu

Struktura specyfikacji
algebraicznej

<NAZWA SPECYFIKACJI>{<PARAMETRY>}

typ <nazwa>
imports <LISTA NAZW SPECYFIKACJI>
Nieformalny opis typu i jego operacji

Sygnatury operacji zdefiniowanych typie
<nazwa> ustalające

ich nazwy i typy parametrów
Aksjomaty definiujące operacje typie <nazwa>

Składniki specyfikacji



Wstęp



Określa nazwę typu i inne typy, które będą

używane



Opis typu



Nieformalny opis operacji związanych ze

specyfikowanym typem



Sygnatury



Definiuje składnię tych operacji i ich

parametry



Aksjomaty



Definiują semantykę poprzez podanie

aksjomatów charakteryzujących

poszczególne operacje

Proces budowy specyfikacji
formalnej interfejsu



Strukturalizacja specyfikacji



Uporządkuj nieformalną specyfikację interfejsu,

nadając jej formę zbioru abstrakcyjnych typów

danych lub klas obiektów. Nieformalnie zdefiniuj

operacje związane z każdą klasą



Nazwanie specyfikacji



Nadaj nazwę każdej specyfikacji abstrakcyjnego

typu. Ustal, czy powinna mieć parametry ogólne i

nadaj nazwę każdemu zidentyfikowanemu typowi.



Wybór operacji



Określ zbiór operacji dla każdej specyfikacji na

podstawie rozpoznanej funkcjonalności interfejsu.

Powinieneś uwzględnić operacje do tworzenia

egzemplarzy, do modyfikowania wartości

egzemplarzy. Być może, będziesz musiał dodać

nowe operacje do tych zdefiniowanych nieformalnie

wcześniej

Proces budowy specyfikacji
formalnej interfejsu



Specyfikowanie nieformalne operacji



Napisz specyfikację nieformalną każdej operacji.
Powinna ona opisywać wpływ operacji na
definiowany typ.



Definiowanie składni



Zdefiniuj składnię operacji i ich parametrów. Będzie
to część sygnaturowa specyfikacji formalnej. Jeśli to
konieczne, zaaktualizuj specyfikację nieformalną



Definiowanie aksjomatów



Zdefiniuj semantykę operacji, opisując warunki ,
które są zawsze prawdziwe dla różnych kombinacji
operacji

Prosta specyfikacja listy

LISTA(Elem)

typ Lista

imports INTEGER

Definiuje listę, do której dodaje się elementy na końcu, a usuwa na początku.

Operacje to

Utwórz

, która powoduje utworzenie pustej listy,

Cons

, która dodaje

element na koniec listy,

Długość

, która oblicza długość listy,

Głowa

, która podaje

pierwszy element na liście i

Ogon

, która tworzy nową listę przez usunięcie głowy ze

swojej listy.

Niezdefiniowane

reprezentuje niezdefiniowaną wartość typu Elem.

Utwórz  Lista

Cons(Lista, Elem)  Lista

Głowa(Lista)  Elem

Długość(Lista)  Integer

Ogon(Lista)  Lista
Głowa(Utwórz)= Niezdefiniowane exception (lista pusta)

Głowa(Cons(L,w))= if L=Utwórz then w else Głowa(L)

Długość(Utwórz)=0

Długość(Cons(L,w))= Długość(L)+1

Ogon(Utwórz)=Utwórz

Ogon(Cons(L,w))=if L=Utwórz then Utwórz else Cons(Ogon(L),w)

Operacje specyfikacji



Operacje konstruktorowe (konstruktory)



Tworzą lub modyfikują byty typu definiowanego w

specyfikacji. W przykładzie listy są to Utwórz, Cons i

Ogon



Operacje inspekcyjne



Obliczają atrybutu typu zdefiniowanego w

specyfikacji. W przykładzie listy są to Głowa i

Długość.



Należy zdefiniować aksjomaty dla każdej operacji

inspekcyjnej względem każdego konstruktora

podstawowego, czyli konstruktora, którego nie można

zdefiniować przy użyciu innych konstruktorów. Dla

konstruktorów nie podstawowych należy dodać

odpowiednie definicje. W przykładzie z listami Utwórz i

Cons są konstruktorami podstawowymi. Przy ich

pomocy można zdefiniować Ogon.

Specyfikacja interfejsu w
systemie krytycznym



W systemie kontroli lotów
zaproponowano obiekty reprezentujące
sektory kontrolowanej przestrzeni
powietrznej.



Każdy sektor może zawierać kilka
samolotów, ale muszą być one
oddzielone.



W przykładzie przyjmujemy odległość co
najmniej 300 metrów w pionie.



System powinien zawiadomić kontrolera
lotów jeśli umieszczenie samolotu
łamałoby tę regułę.

Obiekt sektor



Na obiekcie określone są operacje:



Wejdź.

Dodaje samolot do sektora na

podanej wysokości (obowiązuje reguła 300

m)



Wyjdź.

Usuwa samolot z sektora



Przesuń.

Przesuwa samolot z jednej

wysokości na inną (obowiązuje reguła 300

m)



Znajdź.

Podaje wysokość samolotu



Parametrem (jednym z parametrów) każdej

operacji jest identyfikator reprezentujący

samolot.

Operacje pomocnicze



W celu uproszczenia specyfikacji wprowadzamy
operacje pomocnicze.



Utwórz.

Tworzy pusty sektor



Umieść.

Uproszczona wersja operacji Wejdź. Dodaje

samolot do sektora nie sprawdzając warunku 300 m



W-przestrzeni.

Dla zadanego sektora zwraca

wartość true jeśli samolot jest w sektorze (wpp
false)



Zajęta.

Dla zadanej wysokości zwraca wartość true

jeśli w trzystumetrowym otoczeniu znajduje się jakiś
samolot (wpp false)

Specyfikacja kontrolowanego
sektora

SEKTOR

typ Sektor

imports INTEGER,BOOLEAN

Wejdź – dodaje samolot do sektora, o ile spełniona jest reguła trzystu metrów

Wyjdź – usuwa samolot z sektora

Przesuń – zmienia wysokość samolotu, o ile spełniona jest reguła trzystu

metrów

Znajdź – podaje wysokość samolotu w sektorze

Utwórz

– tworzy pusty sektor

Umieść

– dodaje samolot do sektora bez sprawdzania reguły trzystu metrów

W_przestrzeni

– sprawdza, czy samolot jest w sektorze

Zajęta

– sprawdza, czy podana wysokość jest dostępna

Wejdź(Sektor, Samolot, Wysokość)  Sektor

Wyjdź(Sektor, Samolot)  Sektor

Przesuń(Sektor, Samolot, Wysokość)  Sektor

Znajdź(Sektor, Samolot)  Wysokość

Utwórz  Sektor

Umieść(Sektor, Samolot, Wysokość) Sektor

W_przestrzeni(Sektor, Samolot)  Boolean

Zajęta(Sektor, Wysokość)  Boolean

Specyfikacja kontrolowanego
sektora

Wejdź(sek, sam, w)= if W-przestrzeni(sek, sam) then sek

else if Zajęta(sek,w) then sek) else Umieść(sek,sam,w)

Wyjdź(Utwórz, sam)=Utwórz

Wyjdź(Umieść(sek,sam1,w1),sam)= if sam=sam1 then sek

else Umieść(Wyjdź(sek,sam),sam1,w1)

Przesuń(sek,sam,w)= if sek=Utwórz then Utwórz else if not W_przestrzeni

(sek,sam) then

sek else if Zajęta(sek,w) then sek else Umieść(Wyjdź(sek,sam),sam,w)

Znajdź(Utwórz,sam)=0 (oznacza, że samolotu nie ma w sektorze)

Znajdź(Umieść(sek,sam1,w1),sam)=

if

sam=sam1

then

w1

else

Znajdź(sek,sam)

Zajęta(Utwórz, W)=false

Zajęta(Umieść(sek,sam1,w1),w)=

if abs(w1-w)≤300 then true else Zajęta(sek,w)

W_przestrzeni(Utwórz, sam)= false

W_przestrzeni(Umieść,(sek,sam1,w1),sam)=

if sam=sam1 then true else W_przestrzeni(sek,sam)

Specyfikacja zachowania



Specyfikacje algebraiczne są niewygodne, jeśli
wyniki operacji zależą od wyników
poprzednich operacji.



W takim przypadku można użyć specyfikacji
opartej na modelach. W tym podejściu
specyfikacja modelu ma postać stanu
systemu, a operacje systemu definiuje się
przez ich wpływ na stan systemu.



Jedną z formalnych specyfikacji modelowych
jest notacja Z (ang. Z notation).

Strukura schematu Z

Zbiornik

zawartość: N

pojemność: N
zawartość ≤ pojemność

Nazwa schematu

Sygnatura schematu

Predykat schematu

Diagram blokowy pompy
insulinowej

Igła

Pompa

Zegar

Miernik

Sterownik

Alarm

Wyświetlacz

1

Wyświetlacz

2

Schemat pompy
insulinowejo

POMPA INSULINOWA

odczyt? : N //wartość poziomu glukozy odczytana z miernika

dawka, dawka_min, dawka_całkowita: N //dawka do wstrzyknięcia,

dawka minimalna i dawka z pewnego okresu

r0,r1,r2: N // ostatnie trzy odczyty

zapas: N // zapas insuliny w zbiorniku pompy

alarm! : {włączony, wyłączony} // reprezentuje stan wyjątkowy

pompa! : N // liczba reprezentująca sygnał wysłany do zestawu

pompującego

wyświetlacz1!, wyświetlacz2!: STRING // pierwszy wyświetla

komunikaty; drugi

podawaną dawkę

insuliny
(dawka ≤ zapas) Ʌ (dawka ≤ 5) Ʌ (dawka_całkowita ≤ 50)

(zapas ≥ 40) => wyświetlacz1! = ` `//komunikat pusty

(zapas < 40) Ʌ (zapas ≥ 10) => wyświetlacz1! =` Niski poziom

insuliny’

(zapas < 10) => (alarm! = włączony) Ʌ wyświetlacz1! =` Bardzo

niski poziom insuliny’

o2 = odczyt

Schemat DAWKOWANIE

DAWKOWANIE

Δ POMPA INSULINOWA

(r2<r1) => dawka = 0

r2 = r1 => dawka = 0

[(r2 > r1) Ʌ [(r2-r1) < (r1-r0)]] => dawka=0

[(r2 > r1) Ʌ [(r2-r1) < (r1-r0)] Ʌ round((r2-r1)/4)=0] =>

dawka=dawka_min

[(r2 > r1) Ʌ [(r2-r1) < (r1-r0)] Ʌ round((r2-r1)/4)>0] => dawka=

round((r2-r1)/4)

zapas’ =zapas – dawka

dawka_całkowita = dawka_całkowita + dawka

(r0’ = r1) Ʌ (r1’ = r2)

Schematy wyjściowe

WYŚWIETLANIE

Δ POMPA INSULINOWA

wyświetlacz2!’ = Liczba_na_napis(dawka) Ʌ

(odczyt? <3 => wyświetlacz1!’ = `Niski poziom

cukru’) Ʌ

(odczyt? >30 => wyświetlacz1!’ = `Wysoki poziom

cukru’) Ʌ

(odczyt? ≥ 3) Ʌ (odczyt? ≤ 30) => wyświetlacz1!’ =

`OK.’

ALARM

Δ POMPA INSULINOWA

[(odczyt? < 3) v (odczyt? > 30)] => alarm!’ =

włączony

[(odczyt? ≥ 3) Ʌ (odczyt? ≤ 30)] => alarm!’ =

wyłączony

Podsumowanie



Metody specyfikacji formalnej uzupełniają
metody specyfikacji nieformalnej.



Specyfikacje formalne są dokładne i
jednoznaczne. Niespecjaliści mogą mieć
jednak trudności z ich zrozumieniem. Ponadto
łatwo jest popełnić błędy.



Zasadniczą korzyścią ze stosowania metod
formalnych w procesie budowy
oprogramowania jest wymuszenie analizy
wymagań systemowych już we wczesnej fazie.

Podsumowanie



Metody specyfikacji formalnej najbardziej przydają się przy
budowie systemów krytycznych.



Metody algebraiczne specyfikacji formalnej są szczególnie
przydatne do specyfikowania interfejsów, przy czym przez
interfejs rozumie się zbiór klas obiektów lub abstrakcyjny
typ danych. W tych metodach ukrywa się stan systemu, a
system specyfikuje się w kategoriach związków między
operacjami interfejsu.



W metodach opartych na modelach system przedstawia się
za pomocą pojęć matematycznych, takich jak zbiory i
funkcje. Można w nich odwoływać się do stanu systemu, co
upraszcza niektóre rodzaje specyfikacji zachowania.