Transcript 04.InzynieriaWymagan

Jarosław Kuchta
Dokumentacja i Jakość Oprogramowania
Inżynieria wymagań
[email protected]
[email protected]
Cele inżynierii wymagań

Określenie celu biznesowego projektu


Cel biznesowy określa korzyści, jakie osiągną
udziałowcy projektu dzięki jego realizacji
Identyfikacja wymagań
funkcjonalnych
 niefunkcjonalnych


Alokacja wymagań do poszczególnych
składników systemu informatycznego
Dokumentacja i Jakość
Oprogramowania
Inżynieria wymagań
2/28
Składniki systemu
informatycznego
System informatyczny
Sprzęt
Procedury
Oprogramowanie
Baza
danych
Ludzie
Dokumentacja i Jakość
Oprogramowania
Inżynieria wymagań
Dokumentacja
3/28
Alokacja wymagań – przykład

Rejestracja opinii od klientów
1.
2.
3.
Rozwiązanie pierwsze – pracownik działu reklamacji analizuje opinie
przychodzące telefonicznie lub pocztą i wpisuje je do odpowiedniego
formularza. Dane są rejestrowane w bazie danych.
Rozwiązanie drugie – serwis internetowy udostępnia formularz opinii.
Klienci składający reklamacje muszą odpowiednio szczegółowo wypełnić
formularz. Dane są rejestrowane w bazie danych.
Rozwiązanie trzecie – włącza się automatyczny serwis telefoniczny.
System rozpoznawania głosu wyławia kluczowe słowa z wypowiedzi
klienta i tworzy skróconą charakterystykę opinii. Dane są rejestrowane w
bazie danych wraz z pełnym nagraniem wypowiedzi.
Dokumentacja i Jakość
Oprogramowania
Inżynieria wymagań
4/28
Ustalenie osób
zainteresowanych






użytkownicy końcowi (wymagania funkcjonalne)
administrator systemu (szczególne wymagania
funkcjonalne, niezawodność, dostępność,
testowalność)
wyższe kierownictwo (cele biznesowe)
kierownik marketingu (cechy marketingowe)
kierownik finansowy (koszty)
kierownik ochrony (bezpieczeństwo)
Dokumentacja i Jakość
Oprogramowania
Inżynieria wymagań
5/28
Ustalenie udziałowców









Każda osoba zainteresowana może występować w kilku rolach (np.
administrator może też być użytkownikiem końcowym).
Z każdą rolą jest związany określony punkt widzenia.
Osoba występująca w danej roli jest udziałowcem projektu.
Każde urządzenie lub system współpracujący z projektowanym systemem
również może mieć swoje wymagania i w tym sensie również jest
udziałowcem projektu.
Punkty widzenia różnych udziałowców są różne.
Wszystkie punkty widzenia udziałowców są ważne, chociaż nie wszystkie w
tym samym stopniu.
Wszystkie punkty widzenia powinny zostać wzięte pod uwagę.
Wszystkie punkty widzenia powinny zostać przeanalizowane.
Pojawiające się konflikty powinny zostać rozstrzygnięte.
Dokumentacja i Jakość
Oprogramowania
Inżynieria wymagań
6/28
Ustalenie klienta




Klientem jest osoba lub organizacja, która ma ostateczny wpływ na kształt
projektu. Z klientem uzgadniamy specyfikację wymagań i podpisujemy
kontrakt.
Klient powinien należeć do udziałowców projektu, w przeciwnym wypadku
nie jest zainteresowany wprowadzeniem systemu, stąd szanse powodzenia są
minimalne.
W organizacji musi być wyznaczona osoba odpowiedzialna reprezentująca
klienta. Osoba ta musi mieć odpowiednią władzę nad innymi udziałowcami,
aby zapewnić ich współpracę w fazie formułowania wymagań.
W przypadku klienta szerokiego (produkt przeznaczony dla masowego
odbiorcy) trzeba znaleźć osobę lub grupę osób reprezentujących
udziałowców (najczęściej użytkowników końcowych) i od nich pozyskiwać
wymagania.
Dokumentacja i Jakość
Oprogramowania
Inżynieria wymagań
7/28
Proces pozyskiwania
wymagań
Wydobywanie informacji
Wstępna reprezentacja
Wstępna analiza
Ocena specyfikacji
Dokumentacja i Jakość
Oprogramowania
Inżynieria wymagań
8/28
Podstawowy problem –
zrozumienie
Wiem, że sądzisz, iż rozumiesz to, co myślisz, że ja
powiedziałem, ale nie jestem pewien, czy zdajesz
sobie sprawę z tego, że to co słyszałeś nie jest tym, co
ja myślałem...
Dokumentacja i Jakość
Oprogramowania
Inżynieria wymagań
9/28
Wydobywanie informacji




Uświadomienie sobie przez udziałowców ich
potrzeb.
Sformułowanie potrzeb.
Transformowanie potrzeb na wymagania
względem systemu.
Zdobycie informacji potrzebnych do
zrozumienia wymagań.
Dokumentacja i Jakość
Oprogramowania
Inżynieria wymagań
10/28
Uświadomienie potrzeb




Udziałowiec może nie czuć potrzeby wprowadzenia systemu, a
jedynie kierować się odgórnymi nakazami czy trendami.
Udziałowiec może być na tyle przyzwyczajony do
dotychczasowego sposobu pracy, że nie potrafi zrozumieć zmian,
które nastąpią po wprowadzeniu nowego systemu.
Udziałowiec prawie na pewno nie uświadamia sobie wszystkich
swoich potrzeb.
W przypadku, gdy udziałowcem jest urządzenie lub system, jego
wymagania może reprezentować osoba eksperta lub mogą być
one zapisane w dokumentacji.
Dokumentacja i Jakość
Oprogramowania
Inżynieria wymagań
11/28
Formułowanie potrzeb



Udziałowiec może mieć kłopoty z formułowaniem
jasnych wypowiedzi.
Udziałowiec może być niechętny do formułowania
pewnych potrzeb, gdyż może uznać je za słabość swoją
lub swojej organizacji i wstydzić się tej słabości.
Udziałowiec może uznać pewne swoje potrzeby za
oczywiste i nie zdawać sobie sprawy z tego, że ktoś inny
może ich nie znać.
Dokumentacja i Jakość
Oprogramowania
Inżynieria wymagań
12/28
Transformowanie potrzeb na
wymagania systemowe





Nie każdą potrzebę jest w stanie zaspokoić system
informatyczny.
Niektórych potrzeb nie da się zaspokoić bez zmiany organizacji.
Wymagania mogą być funkcjonalne i niefunkcjonalne. Istnieje
konieczność klasyfikacji wymagań.
Wymagania powinny określać, co system ma robić, a nie w jaki
sposób ma to robić.
Różne potrzeby mogą prowadzić do sprzecznych wymagań.
Istnieje konieczność określenia priorytetów ważności wymagań.
Dokumentacja i Jakość
Oprogramowania
Inżynieria wymagań
13/28
Zdobycie informacji potrzebnych do
zrozumienia wymagań





Informacje mogą być „przechowywane w głowach”
pewnych osób, które mogą nie być zainteresowane w
dzieleniu się nimi.
Informacje mogą być zapisane w trudno dostępnej
dokumentacji.
Informacje mogą być niekompletne.
Informacje mogą być sprzeczne.
Informacje mogą być mylące.
Dokumentacja i Jakość
Oprogramowania
Inżynieria wymagań
14/28
Wstępna reprezentacja







Opis słowny – może mieć niejednoznaczną interpretację, może być niejasny
(sformułowany językiem specjalistycznym), duże prawdopodobieństwo
nadmiarowości i sprzeczności.
Opis graficzny – jest bardziej czytelny (notacja musi być znana dla
udziałowców, np. diagramy blokowe, czytelne symbole), ułatwia precyzowanie
faktów.
Opis matematyczny (naukowy, tabelaryczny) – stosuje się jedynie do
niektórych wymagań
Opis kombinowany – problem spójności
Potrzeba logicznego uszeregowania wymagań – ujawnia luki, nadmiarowości i
sprzeczności w wymaganiach.
Wymagania różnych udziałowców rejestruje się osobno i następnie tworzy ich
kompilację.
Wymagania muszą być ponumerowane, tak aby w późniejszych fazach móc się
do nich odwoływać.
Dokumentacja i Jakość
Oprogramowania
Inżynieria wymagań
15/28
Wstępna analiza



Cel – walidacja wymagań przez udziałowców.
Środek – analiza przez udziałowca
wyspecyfikowanych przez siebie i
zredagowanych przez analityka wymagań.
Pytania stawiane przez analityka:
Co takiego?
 Dlaczego?
 Czy istnieją inne możliwości?

Dokumentacja i Jakość
Oprogramowania
Inżynieria wymagań
16/28
Środki pomocnicze

prototypowanie



prototypem na etapie specyfikacji może być model systemu
(rysunek szkicowy interfejsu użytkownika, wyszczególnienie
najważniejszych pozycji menu, szkic najważniejszych
raportów)
prototypem może być uproszczony program realizujący
jedynie wybrane funkcje
podejście ewolucyjno-iteracyjne

realizacja projektu ze świadomie ograniczoną
funkcjonalnością przy założeniu dalszego udoskonalania
systemu w przyszłości.
Dokumentacja i Jakość
Oprogramowania
Inżynieria wymagań
17/28
Rezultaty
wymagania poprawnie
wyspecyfikowane
wymagania niepoprawnie
wyspecyfikowane
zakres projektu
Dokumentacja i Jakość
Oprogramowania
Inżynieria wymagań
18/28
Trzy grupy wymagań



Wymagania jawnie wyspecyfikowane (dotyczące
konkretnego projektu)
Wymagania domyślne – nie wyspecyfikowane
jawnie, lecz konieczne dla realizacji celów
projektu
Wymagania obligatoryjne – nie muszą być
wyspecyfikowane jawnie, lecz występują ze
względu na regulacje prawne lub wymogi rynku.
Dokumentacja i Jakość
Oprogramowania
Inżynieria wymagań
19/28
Specyfikacja Wymagań
Systemowych
1.
2.
3.
4.
5.
6.
7.
Wstęp
Opis informacyjny
Wymagania funkcjonalne
Wymagania niefunkcjonalne
Kryteria akceptacyjne
Bibliografia
Dodatki
Dokumentacja i Jakość
Oprogramowania
Inżynieria wymagań
20/28
SWS – Wstęp




Identyfikacja systemu
Skrócony opis organizacji
Cel wprowadzenia systemu (cel biznesowy)
Podstawowe ograniczenia
Dokumentacja i Jakość
Oprogramowania
Inżynieria wymagań
21/28
SWS – Opis informacyjny




Szczegółowy opis problemów do rozwiązania
Diagramy przepływu (sterowania lub danych)
najwyższego poziomu
Reprezentacja zawartości informacyjnej
Opis interfejsów systemowych (użytkownika,
softwerowych, sprzętowych)
Dokumentacja i Jakość
Oprogramowania
Inżynieria wymagań
22/28
SWS – Wymagania funkcjonalne


Lista funkcji (podział hierarchiczny)
Opis każdej funkcji






opis tekstowy
ograniczenia
wymagania wydajnościowe
zastrzeżenia projektowe
diagramy pomocnicze
Opis sterowania


specyfikacja sterowania
zastrzeżenia projektowe
Dokumentacja i Jakość
Oprogramowania
Inżynieria wymagań
23/28
SWS – Wymagania niefunkcjonalne




Wymagania wydajnościowe
Wymagania niezawodnościowe
Wymagania dot. bezpieczeństwa
inne
Dokumentacja i Jakość
Oprogramowania
Inżynieria wymagań
24/28
SWS – Kryteria akceptacyjne



Klasy testów
Oczekiwane odpowiedzi systemu
Zastrzeżenia szczególne
Dokumentacja i Jakość
Oprogramowania
Inżynieria wymagań
25/28
SWS – Bibliografia




Inne dokumenty inżynierii oprogramowania
Instrukcje techniczne
Literatura pomocnicza
Standardy
Dokumentacja i Jakość
Oprogramowania
Inżynieria wymagań
26/28
SWS – Dodatki




Słownik pojęć
Dane tabelaryczne
Wykresy
Specyfikacja szczególnych algorytmów
Dokumentacja i Jakość
Oprogramowania
Inżynieria wymagań
27/28
Literatura


Pressman R.S., Software engineering. A
practitioner’s approach, McGraw-Hill,
International Edition, 1992
Górski J. et al., Inżynieria oprogramowania w
projekcie informatycznym,wyd. Mikom,
Warszawa, 2000
Dokumentacja i Jakość
Oprogramowania
Inżynieria wymagań
28/28