Inżynieria wymagań

Inżynieria wymagań 1/1

Wymagania stawiane oprogramowaniu

I Opisy usług i ograniczeń są wymaganiami stawianymisystemowi.

I Proces wynajdowania, analizowania, dokumentowania orazsprawdzania usług i ograniczeń nosi nazwę inżynierii wymagań.

Inżynieria wymagań 2/1

Pojęcie wymogu

I W przemyśle informatycznym pojęcie wymaganie nie jeststosowane konsekwentnie.

I Niekiedy wymaganie jest postrzegane jako zapisane nawysokim poziomie, abstrakcyjne określenie usług, które systempowinien oferować, albo ograniczenie działania systemu.

I Niektórzy określają wymaganie jako szczegółową,matematycznie formalną definicję funkcji systemu.

Inżynieria wymagań 3/1

Typy wymagań

I Wymagania użytkownikaI To wyrażenia w języku naturalnym oraz diagramy o usługach

oczekiwanych od systemu oraz o ograniczeniach, w którychsystem ma działać.

I Wymagania systemoweI Szczegółowo ustalają usługi systemu i ograniczenia.

Dokumentacja wymagań systemowych, zwana czasemspecyfikacją funkcjonalną, powinna być precyzyjna.

I Specyfikacja projektuI Jest abstrakcyjnym opisem projektu oprogramowania, który

jest podstawą bardziej szczegółowego projektu i implementacji.

Inżynieria wymagań 4/1

Czytelnicy różnych rodzajów specyfikacji

Inżynieria wymagań 5/1

Wymagania funkcjonalne i niefunkcjonalne

I Wymagania funkcjonalneI 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órychwypadkach wymagania funkcjonalne określają, czego systemnie powinien robić.

I Wymagania niefunkcjonalneI To ograniczenia usług i funkcji systemu. Obejmują

ograniczenia czasowe, ograniczenia dotyczące procesutworzenia, standardy itd.

I Wymagania dziedzinoweI Pochodzą z dziedziny zastosowania systemu, odzwierciedlają jej

charakterystykę. Mogą być funkcjonalne lub niefunkcjonalne.

Inżynieria wymagań 6/1

Wymagania funkcjonalne

I Wymagania funkcjonalne stawiane systemowi opisująfunkcjonalność lub usługi, które system powinien oferować.

I Zależą od rodzaju tworzonego oprogramowania,spodziewanych użytkowników oprogramowania i rodzajuwytwarzanego systemu.

I Gdy mają postać wymagań użytkownika, ich opis jest zwyklebardziej ogólny, natomiast wymagania funkcjonalne systemoweszczegółowo definiują funkcje systemu, jego wejścia, wyjścia,wyjątki itd.

Inżynieria wymagań 7/1

Przykłady wymagań funkcjonalnych

System biblioteki studenckiej

I Użytkownik będzie mógł przeszukać zbiór wszystkich bazdanych lub wybrać tylko ich podzbiór.

I System udostępni odpowiednie narzędzia do oglądania, abyużytkownik mógł czytać dokumenty z magazynu.

I Każde zamówienie będzie oznaczone unikatowymidentyfikatorem (ORDE ID), który będzie można skopiowaćdo pamięci trwałej konta użytkownika.

Inżynieria wymagań 8/1

Kompletność i spójność specyfikacji wymagańfunkcjonalnych

I W zasadzie specyfikacja wymagań funkcjonalnych stawianychsystemowi powinna być kompletna i spójna.

I Kompletność oznacza, że wszystkie potrzebne użytkownikowiusługi powinny być zdefiniowane.

I Spójność oznacza, że wymagania nie powinny miećsprzecznych definicji.

I W praktyce w wypadku 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 punktywidzenia są związane ze sprzecznymi potrzebami.

Inżynieria wymagań 9/1

Wymagania niefunkcjonalne

I Mogą definiować ograniczenia systemu, takie jak możliwościurządzeń wejścia-wyjścia i reprezentacje danych używane przezinterfejsy systemu.

I Przykładami wymagań stawianych procesowi są specyfikacjastandardó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óregonależy przestrzegać.

I Wymagania niefunkcjonalne wynikają z potrzeb użytkownika,ograniczeń budżetowych, strategii firmy, koniecznościwspółpracy z innymi systemami sprzętu lub oprogramowania,czynników zewnętrznych.

Inżynieria wymagań 10/1

Klasyfikacja wymagań niefunkcjonalnych

I Wymagania produktoweI Określają zachowanie produktu. Przykładami są wymagania

efektywnościowe dotyczące szybkości działania systemu i jegozapotrzebowania na pamięć, wymagania niezawodności.

I Wymagania organizacyjneI Wynikają ze strategii i procedur w firmie klienta i w firmie

wytwórcy.I Wymagania zewnętrzne

I Ta szeroka kategoria mieści wszystkie wymagania wynikające zczynników zewnętrznych. Obejmują m.in. wymaganiawspółpracy, które definiują interakcje systemu z systemamiinnych firm i wymagania prawne.

Inżynieria wymagań 11/1

Typy wymagań niefunkcjonalnych

Inżynieria wymagań 12/1

Przykłady wymagań niefunkcjonalnych

I Wymaganie produktoweI Wszelka niezbędna komunikacja między środowiskiem

wspomagającym programowanie w Adzie (APSE) iużytkownikiem powinna dać się wyrazić za pomocąstandardowego zestawu symboli Ady.

I Wymaganie organizacyjneI Proces tworzenia systemu i końcowe dokumenty powinny być

zgodne z procesem i produktami zdefiniowanymi w standardzieXYZCo-SP-STAN-95.

I Wymaganie zewnętrzneI System nie powinien ujawniać operatorom żadnych danych

osobowych klientów oprócz nazwisk i numerówidentyfikacyjnych.

Inżynieria wymagań 13/1

Problemy związane z wymaganiaminiefunkcjonalnymi

I Powszechnie występującym problemem z wymaganiaminiefunkcjonalnymi jest fakt, że czasem trudno je zweryfikować.

I Mogą one być zapisywane w sposób odzwierciedlający ogólnedążenia klienta, takie jak łatwość użycia, zdolność do naprawyawarii i szybka reakcja na działania użytkownika.

I To jednak zostawia bardzo duży margines do interpretacji.

Inżynieria wymagań 14/1

Miary specyfikowania wymagań niefunkcjonalnych

Właściwość MiaraSzybkość Liczba przetworzonych transakcji na sekundę

Czas reakcji na zdarzenie wywołane przez użytkownikaCzas odświeżania ekranu

Rozmiar Kilobajty pamięci RAMKilobajty przestrzeni dyskowej

Łatwość użycia Czas szkoleniaLiczba okien pomocy

Niezawodność Średni czas bez awariiPrawdopodobieństwo niedostępnościCzęstość błędówDostępność

Solidność Czas uruchomienia po awariiUłamek zdarzeń powodujących awarięPrawdopodobieństwo zniszczenia danych po awarii

Przenośność Procent poleceń zależnych od platformyLiczba docelowych systemów

Inżynieria wymagań 15/1

Wymagania dziedzinowe

I Wymagania dziedzinowe wynikają bardziej z dziedzinyzastosowania systemu niż z konkretnych potrzebużytkowników.

I Mogą być nowymi wymaganiami funkcjonalnymi, ograniczaćistniejące wymagania funkcjonalne albo ustalać sposóbwykonywania konkretnych obliczeń.

I Wymagania dziedzinowe są istotne, ponieważ odzwierciedlająpodstawy dziedziny zastosowania. Jeśli nie są spełnione, tosystem nie może działać w sposób zadowalający.

Inżynieria wymagań 16/1

Wymagania dziedzinowe z systemu bezpieczeństwaruchu pociągów

Tempo zmniejszania prędkości pociągu jest wyznaczanenastępująco:

Dpociagu = Dsterowania + Dnachylenia

przy czym Dnachylenia wynosi 9,81m/s2 ∗ wyrównanienachylenie/alfa, a 9,81m/s2/alfa znane są dla różnych typówpociągów.

Inżynieria wymagań 17/1

Zasadnicze problemy z wymaganiami dziedzinowymi

I Są one wyrażone za pomocą języka specyficznego dladziedziny zastosowania, co sprawia, że inżynierowieoprogramowania często ich nie rozumieją.

I Eksperci z danych dziedzin często mogli pominąć teinformację, ponieważ po prostu jest dla nich oczywista.

I Może nie być jednak oczywista dla twórców systemu, którzymogą to wymaganie zaimplementować w sposóbniesatysfakcjonujący.

Inżynieria wymagań 18/1

Wymagania użytkownika

I Wymagania użytkownika stawiane systemowi powinnyokreślać wymagania funkcjonalne i niefunkcjonalne tak, abybyły zrozumiałe dla użytkowników systemu, którzy nie mająszczegółowej wiedzy technicznej.

I Należy je zapisywać w języku naturalnym, używającformularzy i prostych, intuicyjnych diagramów.

Inżynieria wymagań 19/1

Problemy z językiem naturalnym

I Brak jasnościI Czasem trudno jest wyrażać się w języku naturalnym

precyzyjnie i jednoznacznie bez czynienia dokumentówgadatliwymi i nieczytelnymi.

I Sprzeczność wymagańI Trudno jest jasno rozgraniczać wymagania funkcjonalne,

wymagania niefunkcjonalne, cele systemu i elementy projektu.I Łączenie wymagań

I Kilka różnych wymagań może być zapisanych razem jako jednowymaganie.

Inżynieria wymagań 20/1

Problemy przy stawianiu wymagań

I Jeśli wymagania użytkownika zawierają zbyt wiele informacji,to ograniczają wolność twórców systemu w wyborzeinnowacyjnych rozwiązań oraz utrudniają zrozumieniewymagań.

I Uzasadnienia związane z wymaganiami są istotne. Pomagająwytwórcom i konserwatorom systemu w zrozumieniu, dlaczegotakie wymaganie się pojawiło, i w ocenie wpływu zmiany tegowymagania.

I Szczegóły implementacyjne nie powinny pojawić się bezinformacji dotyczących działania części systemu.

Inżynieria wymagań 21/1

Wymagania systemowe

I Wymagania systemowe są bardziej szczegółowymi opisamiwymagań użytkownika.

I Mogą być podstawą kontraktu na implementację systemu,powinny być zatem pełną i niesprzeczną specyfikacją całegosystemu.

I Są traktowane przez inżynierów oprogramowania jako punktwyjścia do projektowania systemu.

I Specyfikacja wymagań systemowych może zawierać różnemodele systemu.

Inżynieria wymagań 22/1

Wymagania a projekt

I W dokumentacji wymagań można zdefiniować wstępnąarchitekturę systemu, aby nadać specyfikacji odpowiedniąstrukturę. Wymagania systemowe są zorganizowane zgodnie zpodziałem na podsystemy wchodzące w skład systemu.

I W większości wypadków systemy muszą współpracować zinnymi istniejącymi systemami. Ograniczają one projekt, coimplikuje dodatkowe wymagania stawiane nowemu systemowi.

I Użycie specyficznego projektu może być zewnętrznymwymaganiem systemowym.

Inżynieria wymagań 23/1

Notacje specyfikacji wymagań

Notacja OpisStrukturalnyjęzyk natu-ralny

To podejście polega na definiowaniu standardowych formularzyi szablonów do wyrażania specyfikacji wymagań

Język opisuprojektu

W tym podejściu używa się języka podobnego do języka pro-gramowania, ale z bardziej abstrakcyjnymi elementami do spe-cyfikowania wymagań poprzez model operacyjny systemu

Notacje gra-ficzne

Do definiowania wymagań funkcjonalnych stawianych syste-mowi używa się języka graficznego z tekstowymi dopiskami,np. używa się diagramów przypadków użycia.

Specyfikacjematema-tyczne

Są to notacje oparte na pojęciach matematycznych, takich jakskończone matematyczne maszyny stanowe lub zbiory. Takiejednoznaczne specyfikacje zmniejszają spory na temat funkcjo-nalności między klientem a zleceniobiorcą. Większość klientównie rozumie jednak formalnych specyfikacji i jest niechętnaprzyjęciu ich jako kontraktu na budowę systemu.

Inżynieria wymagań 24/1

Dokumentacja wymagańZalecana struktura dokumentacji

1. Wstęp1.1 Przeznaczenie tej dokumentacji wymagań1.2 Zakres produktu1.3 Definicje, akronimy, skróty1.4 Odnośniki1.5 Przegląd pozostałej części dokumentu

2. Ogólny opis2.1 Wizja produktu2.2 Funkcje produktu2.3 Charakterystyka użytkowników2.4 Ogólne ograniczenia2.5 Założenia i zależności

3. Szczegółowe wymagania

4. Dodatki

5. Skorowidz

Inżynieria wymagań 25/1

Proces inżynierii wymagań

Składa się z etapów:

I Studium wykonalnościI Określenie i analizowanie wymagańI Specyfikowanie wymagańI Zatwierdzanie wymagań

Inżynieria wymagań 26/1

Studium wykonalności

Odpowiada na pytania

I Czy system przyczyni się do realizacji celów przedsiębiorstwa?I Czy system może być zaimplementowany z użyciem

dostępnych technologii, w ramach ustalonego budżetu iograniczeń czasowych?

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

Raport studium wykonalnościRaport studium wykonalności zawiera zalecenie kontynuacji lubprzerwania budowy systemu. Może również proponować zmianyzakresu systemu, budżetu lub harmonogramu.

Inżynieria wymagań 27/1

Określanie i analizowanie wymagań

UczestnikUczestnik systemu to osoba, która będzie pracować z systemem oraz osoby wprzedsiębiorstwie, na które system będzie mieć wpływ. Uczestnik powinien miećbezpośredni lub pośredni wpływ na wymagania systemowe.

Określanie i analizowanie wymagań jest trudnym procesem,gdyż:

I Uczestnicy mogą nie wiedzieć dokładnie czego oczekują od systemukomputerowego.

I Uczestnicy systemu wyrażają wymagania za pomocą pojęć z własnej dziedziny.I Różni uczestnicy mogą stawiać różne wymagania i mogą je wyrażać na różne

sposoby.I Czynniki polityczne mogą mieć wpływ na system.I Środowisko ekonomiczne i gospodarcze, w którym prowadzi się analizę, jest

dynamiczne.

Inżynieria wymagań 28/1

Czynności procesu określania i analizowaniawymagań

Czynności:

I Rozpoznanie dziedziny.I Zbieranie wymagań.I Klasyfikacja.I Usuwanie sprzeczności.I Nadawanie priorytetów.I Sprawdzanie wymagań.

Inżynieria wymagań 29/1

VORD – Viewpoint-Oriented RequirementsDefinition

Główne kroki:I Identyfikacja punktów widzenia.I Strukturalizacja punktów widzenia.I Dokumentacja punktów widzenia.I Przyporządkowanie punktów widzenia.

Inżynieria wymagań 30/1

Szablony formularzy punktów widzenia i usług

Szablon do punktów widzeniaOdnośnik: Nazwa punktu wi-

dzeniaAtrybuty: Atrybuty z informa-

cją o punkcie widze-nia

Zdarzenia: Odnośnik do zbioruscenariuszy zdarzeńopisujących, jak sys-tem reaguje na zda-rzenia w ramach te-go punktu widzenia

Usługi: Odnośnik do zbioruopisów usług

PodrzędnePW:

Nazwy podrzędnychpunktów widzenia

Szablon do usługOdnośnik: Nazwa usługiUzasadnienie:Przyczyna oferowania

usługiSpecyfikacja: Odnośnik do listy specy-

fikacji usług, które mo-gą być opisane za pomo-cą różnych notacji

Wymaganianiefunkcjo-nalne:

Odnośnik do zbioruwymagań niefunkcjo-nalnych ograniczającychusługę

Dostawca: Odnośnik do listy obiek-tów systemu, które ofe-rują tę usługę

Inżynieria wymagań 31/1

Burza mózgów

Inżynieria wymagań 32/1

Burza mózgów

Inżynieria wymagań 33/1

Usługi przypisane do punktów widzenia

Właściciel kontaLista usługWypłata gotówkiPytanie o saldoZamówienie czekówWysłanie komunikatuLista transakcjiZamówienie wyciąguPrzelew środków

Obcy klientLista usługWypłata gotówkiPytanie o saldo

Kasa bankuLista usługDiagnostykaDodanie gotówkiDodanie papieruWysłanie komunikatu

Inżynieria wymagań 34/1

Hierarchia punktów widzenia

Inżynieria wymagań 35/1

Proces zatwierdzania wymagań

Sprawdzanie wymagań

I Sprawdzenie ważnościI Sprawdzenie niesprzecznościI Sprawdzenie kompletnościI Sprawdzenie realnościI Możliwość weryfikacji

Inżynieria wymagań 36/1

Proces zatwierdzania wymagań

Zatwierdzanie wymagań

I Przeglądy wymagańI PrototypowanieI Generowanie testówI Zautomatyzowane generowanie niesprzeczności

Inżynieria wymagań 37/1

Wykład przygotowany na podstawie

I Sommerville I.: Inżynieria oprogramowania, WNT, Warszawa2003

Inżynieria wymagań 38/1