Transcript Slajdy cz 4

Część 4
OiZPI
>zarządzanie procesem formułowania wymagań
w materiałach wykorzystano:
K.Subieta: Budowa i integracja systemów informatycznych
A.Kobieliński: Inżynieria Oprogramowania
I.Sommerville: Software Engineering
IBM Rational: RUP™
S.Wyrcza, B.Marcinkowski: Język Inżynierii Systemów SysML, Architektura i Zastosowanie
Organizacja i Zarządzanie Projektem Informatycznym
Zarządzanie procesem formułowania wymagań

Pojęcie inżynierii wymagań

Poziomy szczegółowości wymagań

Dokumentacja fazy określania wymagań
Organizacja i Zarządzanie Projektem Informatycznym
Wymagania

Wymaganie to najogólniej opis tego, co i przy jakich
założeniach system powinien robić by klient osiągnął
postawiony sobie cel.

Formułowanie wymagań to proces zamiany celów
klienta (określonych w fazie strategicznej) na
konkretne wymagania zapewniające osiągnięcie tych
celów.

W fazie określania wymagań klient - samodzielnie albo
wspólnie z grupą doradców i/lub przedstawicielami
producenta - tworzy zbiór wymagań zgodny z jego
celami

Uwaga: pojęcie wymagania może odnosić się także do
zasad prowadzenia i zarządzania projektem.
Organizacja i Zarządzanie Projektem Informatycznym
Metody rozpoznania wymagań
Wywiady i przeglądy.
Wywiady powinny być przygotowane (w postaci listy pytań) i podzielone
na odrębne zagadnienia. Podział powinien przykrywać całość tematu i
powinny być przeprowadzone na reprezentatywnej grupie użytkowników.
Wywiady powinny doprowadzić do szerokiej zgody i akceptacji projektu.
Studia na istniejącym oprogramowaniu.
Dość często nowe oprogramowanie zastępuje stare. Studia powinny ustalić
wszystkie dobre i złe strony starego oprogramowania.
Studia wymagań systemowych.
Dotyczy sytuacji, kiedy nowy system ma być częścią większego systemu.
Studia osiągalności.
Określenie realistycznych celów systemu i metod ich osiągnięcia.
Prototypowanie.
Zbudowanie prototypu systemu działającego w zmniejszonej skali, z
uproszczonymi interfejsami.
Organizacja i Zarządzanie Projektem Informatycznym
Metody rozpoznania wymagań
Warsztaty wymagań.
Jest to spotkanie z inwestorami i użytkownikami (jeśli takich można
wskazać) mające na celu uświadomienie sobie tego, co powinien robić
przyszły system.
Osoba prowadząca – analityk systemowy
Uczestnicy – inwestorzy, użytkownicy i inne osoby, które mogą znać
problemy rozpatrywanej jednostki organizacyjnej
Organizacja i Zarządzanie Projektem Informatycznym
Warsztaty wymagań

Przebieg warsztatów
Każda z osób przemawia i artykułuje – na ile jest to możliwe, czytelnie
swoje problemy
Każdy problem zapisuje się – jakikolwiek by ten problem nie był
Wszyscy uczestnicy starają się znaleźć – na zasadzie "burzy mózgów"
rozwiązanie tego problemu,
Rozwiązania zapisuje się obok problemów
Przykład:
problem:
nie mogę się nigdy doliczyć palet na magazynie
rozwiązanie:
wprowadzić na faktury zakupowe i sprzedażowe pole
określające liczbę przyjętych i wydanych palet.
Organizacja i Zarządzanie Projektem Informatycznym
Warsztaty wymagań

Inne podejście
Analityk najpierw rozpoznaje problemy na niezależnych wcześniejszych
spotkaniach
Systematyzuje problemy tworząc listę pytań,
Do każdego pytania można przygotować dodatkową ilustrację (np.. w
postaci slajdu z diagramem, rysunkiem, tabelą, itp.
Podczas warsztatów analityk objaśnia problem, przedstawia ilustrację
Znajduje się rozwiązanie i udziela odpowiedzi na pytania na odpowiednim
formularzu (query sheet)
przykład: XXX
przykład: YYY
Organizacja i Zarządzanie Projektem Informatycznym
Problem ewolucji wymagań

Ewolucja wymagań to najpoważniejszy problem projektowania
systemów informatycznych. Szacuje się, że większość
niepowodzeń projektów ma swe źródło w zmieniających się
wymaganiach.

Niestety zmiany wymagań raczej nie uda się uniknąć - trzeba
raczej spróbować się na nią przygotować - wiedzieć co trzeba
poprawić, gdy zmienią się wymagania
Początkowe
zrozumienie
problemu
Zmiana
zrozumienia
problemu
czas
Początkowe
wymagania
Zmiana
wymagań
Organizacja i Zarządzanie Projektem Informatycznym
Problem ewolucji wymagań

Należy uznać, że ewolucja wymagań jest naturalną
właściwością procesu analizy, w którym wiedza o
rozpatrywanym problemie systematycznie wzrasta

Im dłużej zajmujemy się jakimś zagadnieniem, tym większa
jest nasza wiedza, tym większa jest świadomość użytkowników

Należy przewidzieć mechanizmy pozwalające kontrolować
proces ewolucji wymagań,

Nie należy takiego problemu wykluczać

Kategoryzacja skali zmian – pomocny mechanizm

Poszczególne kategorie odpowiadają zmianom o różnej skali
Organizacja i Zarządzanie Projektem Informatycznym
Rodzaje wymagań
Wymagania
Wymagania
funkcjonalne
Wymaganie
niefunkcjonalne
Organizacja i Zarządzanie Projektem Informatycznym
Wymagania funkcjonalne
Wymagania funkcjonalne opisują operacje wykonywane przez
system.
Inne aspekty wymagań funkcjonalnych

Określenie wszystkich rodzajów użytkowników, którzy będą korzystać z
systemu.

Określenie wszystkich rodzajów użytkowników, którzy są niezbędni do
działania systemu (obsługa, wprowadzanie danych, administracja).

Dla każdego rodzaju użytkownika określenie funkcji systemu oraz
sposobów korzystania z planowanego systemu.

Określenie systemów zewnętrznych (obcych baz danych, sieci, Internetu),
które będą wykorzystywane podczas działania systemu.

Ustalenie struktur organizacyjnych, przepisów prawnych, statutów,
zarządzeń, instrukcji, itd., które pośrednio lub bezpośrednio określają
funkcje wykonywane przez planowany system.
Organizacja i Zarządzanie Projektem Informatycznym
Metody specyfikacji wymagań funkcjonalnych

Język naturalny
najczęściej stosowany. Wady: niejednoznaczność powodująca różne
rozumienie tego samego tekstu; elastyczność, powodująca wyrazić te
same treści na wiele sposobów. Utrudnia to wykrycie powiązanych
wymagań i powoduje trudności w wykryciu sprzeczności.

Język naturalny strukturalny
Język naturalny z ograniczonym słownictwem i składnią. Tematy i
zagadnienia wyspecyfikowane w punktach i podpunktach.

Tablice, formularze
Wyspecyfikowanie wymagań w postaci (zwykle dwuwymiarowych)
tablic, kojarzących różne aspekty (np. tablica ustalająca zależność
pomiędzy typem użytkownika i rodzajem usługi).
Organizacja i Zarządzanie Projektem Informatycznym
Metody specyfikacji wymagań funkcjonalnych

Diagramy blokowe
forma graficzna pokazująca cykl przetwarzania.

Diagramy kontekstowe
ukazują system w postaci jednego bloku oraz jego powiązania z
otoczeniem, wejściem i wyjściem.

Diagramy przypadków użycia
poglądowy sposób przedstawienia aktorów i funkcji systemu.
Organizacja i Zarządzanie Projektem Informatycznym
Trudności fazy formułowania wymagań

Klient nie potrafi rozgraniczyć celów od wymagań; te pierwsze
często formułuje mało konkretnie i ogólnikowo; tych drugich
nie potrafi wyartykułować (trzeba pomóc mu je rozpoznać)

Klient z reguły spodziewa się poprawy stanu aktualnego
organizacji, często nie przewidując jakie zmiany w organizacji
przedsiębiorstwa spowoduje ulepszony system; najchętniej też
nie ponosiłby za nie odpowiedzialności
Organizacja i Zarządzanie Projektem Informatycznym
Trudności fazy formułowania wymagań

Klient z reguły nie wie w jaki sposób osiągnąć założone cele; z
drugiej strony cele klienta można osiągnąć na wiele sposobów

Duże systemy wykorzystywane są przez wielu użytkowników;
ich cele często są sprzeczne; różni użytkownicy mogą
posługiwać się inną terminologią mówiąc o tych samych
problemach

Inwestorzy i użytkownicy do często inne osoby; głos inwestora,
choć decydujący, nie zawsze właściwie potrafi przewidzieć
potrzeby rzeczywistych użytkowników
Organizacja i Zarządzanie Projektem Informatycznym
Zalecenia

Wymagania użytkowników powinny być wyjaśniane poprzez
krytykę i porównanie z istniejącym oprogramowaniem i
prototypami.

Należy uzyskać stan porozumienia pomiędzy projektantami i
użytkownikami dotyczący projektowanego systemu.

Wiedza i doświadczenia potencjalnej organizacji podejmującej
się rozwoju systemu powinny wspomóc studia nad
osiągalnością systemu.

W wielu przypadkach dużym wspomaganiem jest budowa
prototypów.

Wymagania użytkowników powinny być: jasne, jednoznaczne,
weryfikowalne, kompletne, dokładne, realistyczne, osiągalne.
Organizacja i Zarządzanie Projektem Informatycznym
Wymagania niefunkcjonalne
Wymagania niefunkcjonalne określają jakim ograniczeniom podlegać
ma system wypełniając wymagania funkcjonalne.
Najczęściej związane są z

wydajnością systemu,

właściwościami interfejsu użytkownika,

dopasowaniem do określonego środowiska – system operacyjny,
system zarządzania bazą danych
Organizacja i Zarządzanie Projektem Informatycznym
Weryfikowalność wymagań niefunkcjonalnych

Wymagania niefunkcjonalne powinny być weryfikowalne, czyli
powinna istnieć możliwość sprawdzenia lub zmierzenia czy
system je rzeczywiście spełnia, np. wymagania “system ma
być łatwy w obsłudze”, „system ma być niezawodny”, „system
ma być dostatecznie szybki”, itd. nie są weryfikowalne.

Aby uniknąć nieporozumień na etapie odbioru systemu
(testach akceptacyjnych) najlepiej posługi się metryką, która
obiektywizuje spełnienie bądź nie wymagań niefunkcjonalnych.
Organizacja i Zarządzanie Projektem Informatycznym
Przykłady metryk wymagań niefunkcjonalnych
Cecha
Metryka
Szybkość
Liczba transakcji przetwarzanych na sekundę, czas reakcji na sygnał
użytkownika / sygnał zewnętrzny
Rozmiar
KB/MB/GB
Łatwość użycia
Czas treningu użytkownika, liczba stron systemu pomocy, liczba stron
dokumentacji
Niezawodność
Średni czas międzyawaryjny, prawdopodobieństwo niedostępności,
częstotliwość występowania awarii
Odporność na błędy
Czas restartu po awarii, statystyczny procent zdarzeń powodujących
awarie
Przenośność
Procent instrukcji zależnych od systemu operacyjnego, liczba
systemów docelowych
Organizacja i Zarządzanie Projektem Informatycznym
SysML - wymagania

Formułowanie wymagań – najbardziej newralgiczny etap pracy
nad systemami

W języku SysML wyodrębniono dla wymagań osobną kategorie
modelowania

Notacja – diagram wymagań systemowych

Wymaganie – symbol kasy o stereotypie <<requirement>>

Wymaganie jest identyfikowane przez:
 Numer – numeracja o strukturze hierarchiczne, notacja
Deweya (numerowanie wierzchołków drzewa)
 Treść wymagania – spójny, syntetyczny opis właściwości,
która powinien posiadać system (nazwa)

Wymaganie można uzupełnić opisem, korzystając z metki
„tekst” lub z pola notatek
Organizacja i Zarządzanie Projektem Informatycznym
SysML - wymagania
Organizacja i Zarządzanie Projektem Informatycznym
SysML – wymagania i relacje

W SysML przewidziano siedem kategorii zależności:
 Zagnieżdżenie
 Zależność wyprowadzania (<<deriveReqt>>)
 Zależność realizacji (<<satisfy>>)
 Zależność powielenia (<<copy>>)
 Zależność weryfikowania (<<verify>>)
 Zależność precyzowania (<<refine>>)
 Zależność śledzenia (<<trace>>)
Organizacja i Zarządzanie Projektem Informatycznym
SysML: wymagania i relacje – zagnieżdżenie

Najczęściej spotykana relacja

Znaczenie: łączy wymagania nadrzędne z podrzędnymi
pozwalając na tworzenie hierarchicznej struktury powiązań

Na jednym poziomie hierarchii może istnieć tylko jeden
element nadrzędny

Przeniesienie pomiędzy elementami nadrzędnymi – zależność
kopiowania
Organizacja i Zarządzanie Projektem Informatycznym
SysML: wymagania i relacje –
zależność wyprowadzania

Znaczenie: wyprowadzanie jednego wymagania z innego

Wyprowadzone wymaganie to wymaganie pochodne

Strzałka wskazuje wymaganie, z którego wyprowadzono
wymaganie pochodne
Organizacja i Zarządzanie Projektem Informatycznym
SysML: wymagania i relacje –
zależność realizacji

Znaczenie: przypisanie wymagania do spełniającego go
elementu

Strzałka wskazuje spełniane wymaganie
Organizacja i Zarządzanie Projektem Informatycznym
SysML: wymagania i relacje –
zależność powielania

Znaczenie: wyrażanie tożsamości wymagań

Pozwala unikać wielokrotnego definiowania podobnych
wymagań

Strzałka wskazuje powielane wymaganie
Organizacja i Zarządzanie Projektem Informatycznym
SysML: wymagania i relacje –
zależność weryfikowania

Znaczenie: powiązanie testu formalnego z wymaganiem

Test formalny (ang. testcase) jest odrębna kategoria
modelowania SysML (także UML)

Strzałka wskazuje weryfikowane wymaganie
Organizacja i Zarządzanie Projektem Informatycznym
SysML: wymagania i relacje –
zależność precyzowania

Znaczenie: powiązanie wymagania z elementem modelu
wzbogacającym jego specyfikację

Elementem wzbogacającym może być dowolna kategoria
modelowania, ale także specyfikacja tekstowa, projekt
interfejsu, itp.

Strzałka wskazuje wzbogacane wymaganie
Organizacja i Zarządzanie Projektem Informatycznym
SysML: wymagania i relacje –
zależność śledzenia

Znaczenie: pokazanie formalnego związku pomiędzy
wymaganiem i elementami modelu

Duża swoboda posługiwania się znaczeniem (swoboda
interpretacji)

Przykładowe zastosowanie: zależności czasowe
Organizacja i Zarządzanie Projektem Informatycznym