inżynieria wymagań. proces inżynierii wymagań · analiza istniejącego procesu w firmie...

INŻYNIERIA OPROGRAMOWANIAINŻYNIERIA OPROGRAMOWANIA INŻYNIERIAOPROGRAMOWANIA

Inżynieria wymagań. Proces inżynierii wymagań

Wykorzystane materiały:• prezentacje J.E. Sienkiewicza i M.A. Płotki

• I. Sommerville, Inżynieria oprogramowania, WNT 2003 oraz odczyty

• J. Gorman „Driving Development with Use Cases”, http://www.parlezuml.com

Dilbert by Scott Adams, tłum. własne

Ogólne zadania inżynierii wymagań INŻYNIERIAOPROGRAMOWANIA

� Wydobycie wymagań/określenie potrzeb klienta

� Wyspecyfikowanie dobrych (mierzalnych, realnych,

jednoznacznych itp.) wymagań

� Stworzenie kompletnej i spójnej listy wymagań

� Weryfikacja, integracja i pielęgnacja wymagań

� Zamodelowanie potrzeb klienta

� Oszacowanie złożoności, czasu powstania i kosztu

stworzenia systemu

Zebranie wymagań na złożony system zawsze będzie problemem trudnym technicznie

i organizacyjnie

Źródła problemów w inżynierii wymagań INŻYNIERIAOPROGRAMOWANIA

� Trudności w pisaniu – należy dobrać język, który pozwoli opisać wymaganie tak by zostało ono zrozumiałe przez wszystkich udziałowców

� Brak możliwości śledzenia zmian – kto, kiedy i komu podał/zmienił dane wymaganie?

� Zła organizacja – złe oszacowanie, rozplanowanie zadań

� Podatność do zmian –ciągła zmiana wymagań znacznie utrudnia pracę nad projektem („oni wciąż chcą czegoś innego, co my tak właściwie robimy” –pogoń za ruchomym celem), uszkodzenie struktury systemu w czasie licznych zmian

Konsekwencje źle wyspecyfikowanych wymagańKonsekwencje źle wyspecyfikowanych wymagań INŻYNIERIAOPROGRAMOWANIA

To, co klient zamówił To co, analityk zrozumiał To, co opisywał projekt To, co wykonali programiści

Projekt po poprawkach i wdrożeniu

To, czego klient potrzebowałTo, za co klient zapłacił

Praktyczne zastosowanie projektu

Konsekwencje źle wyspecyfikowanych wymagańKonsekwencje źle wyspecyfikowanych wymagań INŻYNIERIAOPROGRAMOWANIA

�� System może być dostarczony później i kosztować więcej niż System może być dostarczony później i kosztować więcej niż

planowanoplanowano

�� Klient i użytkownicy końcowi mogą nie być zadowoleni z systemu. Klient i użytkownicy końcowi mogą nie być zadowoleni z systemu.

Mogą w ogóle nie używać wybranych jego funkcji lub odrzucić go wMogą w ogóle nie używać wybranych jego funkcji lub odrzucić go w

całościcałości

�� System może działać niepewnie w normalnym użytkowaniu, System może działać niepewnie w normalnym użytkowaniu,

generować błędy, zawieszać się itp.generować błędy, zawieszać się itp.

�� Koszt konserwacji i ewolucji systemu może znacząco wzrosnąćKoszt konserwacji i ewolucji systemu może znacząco wzrosnąć

Wniosek:Wniosek: należy przyjrzeć się bliżej należy przyjrzeć się bliżej procesowi inżynierii procesowi inżynierii

oprogramowaniaoprogramowania, który służy do określania, analizowania i , który służy do określania, analizowania i

zatwierdzania wymagań stawianych systemowi i obejmuje wszystkie zatwierdzania wymagań stawianych systemowi i obejmuje wszystkie

czynności niezbędne do opracowania i aktualizacji dokumentacji czynności niezbędne do opracowania i aktualizacji dokumentacji

wymagań systemowychwymagań systemowych

Czynności procesu inżynierii wymagańCzynności procesu inżynierii wymagań INŻYNIERIAOPROGRAMOWANIA

Ogólne czynności w procesie inżynierii wymagań:Ogólne czynności w procesie inżynierii wymagań:

�� studium wykonalnościstudium wykonalności

�� określanie i analizowanie wymagańokreślanie i analizowanie wymagań

�� specyfikowanie i dokumentowanie wymagańspecyfikowanie i dokumentowanie wymagań

�� zatwierdzanie wymagańzatwierdzanie wymagań

Studiumwykonalności

Określanie i analizowanie

wymagańSpecyfikowanie

wymagań Zatwierdzanie wymagań

Raportwykonalności

Dokumentacjawymagań

Określanie i analizowanie wymagań INŻYNIERIAOPROGRAMOWANIA

�� Polega na pracy z klientem i użytkownikami Polega na pracy z klientem i użytkownikami

systemu nad badaniem dziedziny zastosowania i systemu nad badaniem dziedziny zastosowania i

usług, które system ma oferować, pożądanej usług, które system ma oferować, pożądanej

efektywności, ograniczeń sprzętowych, efektywności, ograniczeń sprzętowych,

organizacyjnych itd.organizacyjnych itd.

�� W określaniu i analizowaniu wymagań mogą wziąć W określaniu i analizowaniu wymagań mogą wziąć

udział osoby z różnych stanowisk w firmie. udział osoby z różnych stanowisk w firmie.

Pojawia się pojęcie udziałowca.Pojawia się pojęcie udziałowca.

UdziałowiecUdziałowiec ((ang. ang. StakeholderStakeholder) ) –– każdy, kto ma każdy, kto ma

pośredni lub bezpośredni wpływ na wymaganiapośredni lub bezpośredni wpływ na wymagania

Udziałowcy – różne perspektywy INŻYNIERIAOPROGRAMOWANIA

Proces określania i analizowania wymagań INŻYNIERIAOPROGRAMOWANIA

Start

Rozpoznaniedziedziny

Zbieraniewymagań

Klasyfikacja

Usuwaniesprzeczności

Nadawaniepriorytetów

Sprawdzeniewymagań

Specyfikacjawymagań

Dokumentacjawymagań

Techniki pozyskiwania wymagańTechniki pozyskiwania wymagań INŻYNIERIAOPROGRAMOWANIA

�� Studia dziedzinowe Studia dziedzinowe –– standardy, regulacje, przepisy prawne, standardy, regulacje, przepisy prawne,

schematy, opisy procedur i stanowisk itp.schematy, opisy procedur i stanowisk itp.

�� Analiza istniejącego procesu w firmie Analiza istniejącego procesu w firmie –– gdzie jest problem?gdzie jest problem?

�� Wywiady Wywiady –– pozyskiwanie informacji podczas bezpośredniej pozyskiwanie informacji podczas bezpośredniej

rozmowy z klientemrozmowy z klientem

�� Obserwacje Obserwacje –– obserwowanie istniejącego stanu rzeczyobserwowanie istniejącego stanu rzeczy

�� Praca grupowa Praca grupowa –– npnp. „burza mózgów”. „burza mózgów”

�� Ankiety, kwestionariuszeAnkiety, kwestionariusze

�� Prezentacje wstępnej reprezentacji zebranych wymagań (Prezentacje wstępnej reprezentacji zebranych wymagań (npnp. w . w

postaci diagramu przypadków użycia) pozostałym udziałowcom postaci diagramu przypadków użycia) pozostałym udziałowcom

�� Symulacje Symulacje –– symulowanie różnych punktów widzeniasymulowanie różnych punktów widzenia

�� EksperymentyEksperymenty

�� PrototypowaniePrototypowanie

Dlaczego określanie wymagań jest takie nudne Dlaczego określanie wymagań jest takie nudne trudne?trudne?

INŻYNIERIAOPROGRAMOWANIA

�� Biznes jest zwykle prowadzony w szybko zmieniającym się Biznes jest zwykle prowadzony w szybko zmieniającym się

środowiskuśrodowisku (ekonomicznym, rynkowym, prawnym, politycznym, (ekonomicznym, rynkowym, prawnym, politycznym,

technologicznym), zatem wymagania na system ciągle się zmieniajątechnologicznym), zatem wymagania na system ciągle się zmieniają

�� Zwykle w procesie zbierania wymagań Zwykle w procesie zbierania wymagań występuje wielu występuje wielu

udziałowcówudziałowców ze znacząco różnymi celami, oczekiwaniami ze znacząco różnymi celami, oczekiwaniami

względem systemu oraz priorytetami (często sprzecznymi ze sobą)względem systemu oraz priorytetami (często sprzecznymi ze sobą)

�� Udziałowcy często nie wiedzą, czego tak naprawdę oczekująUdziałowcy często nie wiedzą, czego tak naprawdę oczekują od od

nowo tworzonego systemu komputerowegonowo tworzonego systemu komputerowego

�� Udziałowcy mogą stawiać nierealne żądaniaUdziałowcy mogą stawiać nierealne żądania ((npnp. nie uwzględniając . nie uwzględniając

kosztu ich wprowadzenia)kosztu ich wprowadzenia)

�� Udziałowcy systemu wyrażają wymagania za pomocą własnych Udziałowcy systemu wyrażają wymagania za pomocą własnych

pojęć. pojęć. Inżynier oprogramowania musi zrozumieć tak wyrażone Inżynier oprogramowania musi zrozumieć tak wyrażone

wymagania i przełożyć je na wymagania systemowewymagania i przełożyć je na wymagania systemowe

Dlaczego określanie wymagań jest takie trudne? Dlaczego określanie wymagań jest takie trudne? Czynniki polityczne i ludzkieCzynniki polityczne i ludzkie


�� Kluczowi udziałowcy zawsze mają inne rzeczy na głowie!Kluczowi udziałowcy zawsze mają inne rzeczy na głowie!

Opracowanie (podanie) szczegółowych wymagań dla przyszłego Opracowanie (podanie) szczegółowych wymagań dla przyszłego

systemu często nie ma zbyt wysokiego priorytetu u osób, które bęsystemu często nie ma zbyt wysokiego priorytetu u osób, które będą dą

dotknięte tymi wymaganiami. W związku z tym nie są w stanie dotknięte tymi wymaganiami. W związku z tym nie są w stanie

wyrazić wymagań szczegółowo, robią to mało konkretniewyrazić wymagań szczegółowo, robią to mało konkretnie

�� Udziałowcy nie muszą być przekonani do końca, że tworzenie Udziałowcy nie muszą być przekonani do końca, że tworzenie

systemu jest koniecznesystemu jest konieczne lub uważać, że nie jest to sprawa lub uważać, że nie jest to sprawa

priorytetowapriorytetowa.. Mogą więc aktywnie bądź pasywnie odmawiać Mogą więc aktywnie bądź pasywnie odmawiać

współpracywspółpracy

�� Czynniki polityczne i organizacyjneCzynniki polityczne i organizacyjne u zleceniodawcy również mają u zleceniodawcy również mają

zwykle spory wpływ na system, a udziałowcy nie chcą lub nie zwykle spory wpływ na system, a udziałowcy nie chcą lub nie

potrafią ich określić czy uzasadnić. Z kolei twórcy systemu nie potrafią ich określić czy uzasadnić. Z kolei twórcy systemu nie są w są w

stanie ich zrozumieć. Decyzje dotyczące wymagań mogą być więc stanie ich zrozumieć. Decyzje dotyczące wymagań mogą być więc

podejmowane na irracjonalnym gruncie, opartym o czyjeś osobiste podejmowane na irracjonalnym gruncie, opartym o czyjeś osobiste

korzyścikorzyści

Dlaczego określanie wymagań jest takie trudne? Dlaczego określanie wymagań jest takie trudne? Zmienność procesuZmienność procesu


�� Nie ma żadnych obiektywnych sposobów porównywania Nie ma żadnych obiektywnych sposobów porównywania

alternatywnych zestawów wymagań.alternatywnych zestawów wymagań. Wpływ systemu na biznes jest Wpływ systemu na biznes jest

bardzo trudny do zrozumienia, zatem nie możemy w ogólności bardzo trudny do zrozumienia, zatem nie możemy w ogólności

powiedzieć, który system będzie najlepszy dla konkretnego powiedzieć, który system będzie najlepszy dla konkretnego

przedsiębiorstwa przedsiębiorstwa

�� Wymagany poziom szczegółowości specyfikacjiWymagany poziom szczegółowości specyfikacji różni się znacznie różni się znacznie

w zależności od rodzaju opracowywanego produktu. W celu w zależności od rodzaju opracowywanego produktu. W celu

uzyskania specyfikacji mogą być więc wykorzystywane zupełnie uzyskania specyfikacji mogą być więc wykorzystywane zupełnie

różne procesy obejmujące różne typy różne procesy obejmujące różne typy ludzi ludzi –– pojawiają się pojawiają się

ograniczenia standaryzacji procesuograniczenia standaryzacji procesu

�� dla systemu sygnalizacji kolejowej wymagana jest bardzo dla systemu sygnalizacji kolejowej wymagana jest bardzo

szczegółowa specyfikacja, która będzie zatwierdzana przez szczegółowa specyfikacja, która będzie zatwierdzana przez

odpowiednie urzędy (niezależnie od zleceniodawcy)odpowiednie urzędy (niezależnie od zleceniodawcy)

�� specyfikacja gry komputerowej może być z kolei scenariuszem specyfikacja gry komputerowej może być z kolei scenariuszem

ze zdjęciami i przykładamize zdjęciami i przykładami

Dlaczego określanie wymagań jest takie trudne? Dlaczego określanie wymagań jest takie trudne? Na wesoło o użytkownikach końcowych ;)Na wesoło o użytkownikach końcowych ;)


W pewnym momencie podczas realizacji projektu ktoś zaczyna biadoW pewnym momencie podczas realizacji projektu ktoś zaczyna biadolić, że trzeba lić, że trzeba

określić „wymagania”. Wiążą się z tym rozmowy z ludźmi, którzy określić „wymagania”. Wiążą się z tym rozmowy z ludźmi, którzy –– to ciekawe to ciekawe ––

nie wiedzą, czego chcą, ale dokładnie wiedza, kiedy tego potrzebnie wiedzą, czego chcą, ale dokładnie wiedza, kiedy tego potrzebują. Tych ludzi ują. Tych ludzi

nazywa się „użytkownikami finalnymi” lub po prostu „kołkami”.nazywa się „użytkownikami finalnymi” lub po prostu „kołkami”.

Badania wykazały, że na świecie nie ma nić głupszego niż „użytkoBadania wykazały, że na świecie nie ma nić głupszego niż „użytkownik finalny”. wnik finalny”.

Diagram poniżej pokazuje inteligencję względną kilku zwykłych skDiagram poniżej pokazuje inteligencję względną kilku zwykłych składników ładników

gospodarstwa domowego:gospodarstwa domowego:Scott Adams - Zasada DilbertaWyd. Amber, W-wa, 2001

Techniki i narzędzia używane w procesie Techniki i narzędzia używane w procesie inżynierii wymagańinżynierii wymagań


�� Punkty widzeniaPunkty widzenia

�� przyglądamy się systemowi z punktu widzenia przetwarzanych przyglądamy się systemowi z punktu widzenia przetwarzanych

danych lub oferowanych usługdanych lub oferowanych usług

�� ScenariuszeScenariusze

�� opisujemy przebieg interakcji opisujemy przebieg interakcji npnp. między użytkownikiem a . między użytkownikiem a

systememsystemem

Scenariusze i punkty widzenia składają się (w pewnym Scenariusze i punkty widzenia składają się (w pewnym

sensie) w tzw. sensie) w tzw. model przypadków użycia (model przypadków użycia (UseUse CasesCases))

�� Analiza strukturalnaAnaliza strukturalna

�� oparta głównie na formalnych metodach zapisu wymagańoparta głównie na formalnych metodach zapisu wymagań

Określanie wymagań Określanie wymagań oparte na punktach widzenia (VORD)oparte na punktach widzenia (VORD)


VORD: ang. VORD: ang. ViewpointViewpoint--OrientedOriented RequirementsRequirements DefinitionDefinition

Zwykle systemy maja kilka różnych grup użytkowników. Zwykle systemy maja kilka różnych grup użytkowników.

Należy przyjrzeć się systemowi z ich punktu widzenia.Należy przyjrzeć się systemowi z ich punktu widzenia.

Klasyfikacja punktów widzenia:Klasyfikacja punktów widzenia:

�� Ze względu na źródło lub przeznaczenie danychZe względu na źródło lub przeznaczenie danych

Punkt widzenia powiązany jest z użytkowaniem lub produkcją Punkt widzenia powiązany jest z użytkowaniem lub produkcją

danych. Analiza polega na rozpoznawaniu wszystkich danych, danych. Analiza polega na rozpoznawaniu wszystkich danych,

miejsc ich produkcji, użytkowania i przetwarzania.miejsc ich produkcji, użytkowania i przetwarzania.

�� Ze względu na usługi zewnętrzneZe względu na usługi zewnętrzne

W tym wypadku punkty widzenia są zewnętrzne wobec systemu. W tym wypadku punkty widzenia są zewnętrzne wobec systemu.

Osoby mające ten sam punkt widzenia korzystają z jednakowych Osoby mające ten sam punkt widzenia korzystają z jednakowych

usług systemu.usług systemu.

Model zewnętrznych punktów widzeniaModel zewnętrznych punktów widzenia INŻYNIERIAOPROGRAMOWANIA

�� Reprezentanci zewnętrznych punktów widzenia współpracują z Reprezentanci zewnętrznych punktów widzenia współpracują z

systemem przez systemem przez otrzymywanie usług od systemuotrzymywanie usług od systemu oraz oraz

przekazywanie do systemu danych i sygnałów sterującychprzekazywanie do systemu danych i sygnałów sterujących..

�� Punkty widzenia są Punkty widzenia są zewnętrznezewnętrzne wobec systemu, stanowią zatem wobec systemu, stanowią zatem

naturalny sposób strukturalizacji procesu określania wymagań.naturalny sposób strukturalizacji procesu określania wymagań.

�� Punkty widzenia i usługi stanowią dobry sposób strukturalizacjiPunkty widzenia i usługi stanowią dobry sposób strukturalizacji nie nie

tylko wymagań funkcjonalnych, ale również niefunkcjonalnych i tylko wymagań funkcjonalnych, ale również niefunkcjonalnych i

dziedzinowych. Każda usługa może być powiązana z wymaganiami dziedzinowych. Każda usługa może być powiązana z wymaganiami

niefunkcjonalnymi lub dziedzinowymi.niefunkcjonalnymi lub dziedzinowymi.

�� Dość łatwo jest stwierdzić, Dość łatwo jest stwierdzić, czy coś jest punktem widzenia, czy też czy coś jest punktem widzenia, czy też

nienie. Reprezentanci punktów widzenia muszą bowiem w pewien . Reprezentanci punktów widzenia muszą bowiem w pewien

sposób oddziaływać na system.sposób oddziaływać na system.

Punkty widzenia a atrybuty/cele systemuPunkty widzenia a atrybuty/cele systemu INŻYNIERIAOPROGRAMOWANIA

�� Atrybuty i ogólne cele systemu odnoszą się do wszystkich punktówAtrybuty i ogólne cele systemu odnoszą się do wszystkich punktów

widzenia…widzenia…

�� … i są do nich prostopadłe… i są do nich prostopadłe

Przykład Przykład –– system bankomatowysystem bankomatowy INŻYNIERIAOPROGRAMOWANIA

�� System służy do wykonywania operacji System służy do wykonywania operacji bankomatowychbankomatowych

przy użyciu karty przy użyciu karty bankomatowejbankomatowej z przypisanym kodem z przypisanym kodem

PINPIN

�� W uproszczonej wersji służy klientom macierzystego W uproszczonej wersji służy klientom macierzystego

banku („ własny klient”), oferując im bardziej banku („ własny klient”), oferując im bardziej

skomplikowane usługi, oraz klientom innym banków skomplikowane usługi, oraz klientom innym banków

(„obcy klient”) w ograniczonym zakresie(„obcy klient”) w ograniczonym zakresie

�� Usługi zaawansowane obejmują Usługi zaawansowane obejmują npnp. wypłatę i wpłatę . wypłatę i wpłatę

środków, przekazywanie komunikatów do banku, środków, przekazywanie komunikatów do banku,

wyświetlanie informacji (wyświetlanie informacji (npnp. o saldzie konta lub . o saldzie konta lub

wykonanych transakcjach).wykonanych transakcjach).

System bankomatowy System bankomatowy –– burza mózgówburza mózgów INŻYNIERIAOPROGRAMOWANIA

Pytanieo saldo

Menedżer

Odczyttransakcji

Zasobymaszyny

Interfejsużytkownika

Własny klient

Zdalnadiagnostyka

Kartaskradziona

Niezawodność

Informacjeo koncie

Koszt systemu

Baza danychklientów

Wypłatagotówki

Aktualizacjakonta

Zamówieniewyciągu

Obcy klient

Dziennikkomunikatów

Przelew środków

Zdalnaaktualizacja

oprogramowania

Zamówienieczeków

Zwrot karty

Dzienniktransakcji

Drukarka

Rozmiaroprogramowania

Zatrzymaniekarty

Nieuprawnionyużytkownik

Kasabanku

Weryfikacjakarty

Przekazywaniekomunikatów

ZabezpieczeniaPielęgnacja

oprogramowania

System bankomatowy System bankomatowy –– udziałowcyudziałowcy INŻYNIERIAOPROGRAMOWANIA

�� Klienci bankuKlienci banku

�� Klienci innych bankówKlienci innych banków

�� Dyrektorzy oddziałów bankówDyrektorzy oddziałów banków

�� Pracownicy obsługi klienta w oddziałachPracownicy obsługi klienta w oddziałach

�� Kasa bankuKasa banku

�� Administratorzy baz danychAdministratorzy baz danych

�� Osoby odpowiedzialne za bezpieczeństwo w bankuOsoby odpowiedzialne za bezpieczeństwo w banku

�� Dział marketingu bankuDział marketingu banku

�� Inżynierowie pielęgnacji sprzętu i oprogramowaniaInżynierowie pielęgnacji sprzętu i oprogramowania

System bankomatowy System bankomatowy –– punkty widzeniapunkty widzenia INŻYNIERIAOPROGRAMOWANIA

InżynierMenedżerKasa banku

Obcy klientWłasny klient

Klient Personel banku

Wszystkie PW

System bankomatowy System bankomatowy –– punkty widzenia a usługipunkty widzenia a usługi INŻYNIERIAOPROGRAMOWANIA

WŁASNYKLIENT

OBCYKLIENT

KASABANKU

Lista usług Lista usług Lista usług

Wypłata gotówkiPytanie o saldoWysyłanie komunikatuLista transakcjiZamówienie wyciąguPrzelew środków

Wypłata gotówkiPytanie o saldo

DiagnostykaDodanie gotówkiDodanie papieruWysłanie komunikatu

System bankomatowy System bankomatowy ––dane sterujące i wejściowedane sterujące i wejściowe


WŁASNYKLIENT Dane sterujące Dane wejściowe

Rozpocznij transakcję Informacje z karty

Anuluj transakcję PIN

Zakończ transakcję Żądana kwota

Wybór usługi

System bankomatowy System bankomatowy –– opis punktów widzenia opis punktów widzenia i usługi usług


Nazwa PW: Klient

Atrybuty: Numer kontaPIN

Zdarzenia: Rozpocznij transakcjęWybór usługiAnuluj transakcjęZakończ transakcję

Usługi: Wypłata gotówkiPytanie o saldo

Podrzędne PW: Własny klientObcy klient

Usługa: Wypłata gotówki

Uzasadnienie: Celem zmniejszenie obciążenia okienek kasowych itp.

Specyfikacja: Użytkownicy wybierają usługęprzez naciśnięcie przycisku„wypłata gotówki”. Następuje weryfikacja numeru PIN.Następnie wprowadzona zostajeżądana kwota. Jeśli na koncie sąwystarczające środki, następujewypłata gotówki.

PW: Klient

Wymaganianiefunkcjonalne: Wypłacić gotówkę najpóźniej

po 1 minucie od potwierdzeniakwoty

Scenariusze (ang. Scenariusze (ang. scenariosscenarios)) INŻYNIERIAOPROGRAMOWANIA

Ludzie zwykle wolą przykłady wzięte z życia Ludzie zwykle wolą przykłady wzięte z życia od abstrakcyjnych opisówod abstrakcyjnych opisów

�� ScenariuszScenariusz –– opis typowego przebiegu zadania opis typowego przebiegu zadania

wykonywanego przez użytkownika systemu (interakcji wykonywanego przez użytkownika systemu (interakcji

użytkownik użytkownik –– system)system)

�� Każdy scenariusz obejmuje jedną lub najwyżej kilka Każdy scenariusz obejmuje jedną lub najwyżej kilka

możliwych interakcji możliwych interakcji

�� Na podstawie scenariuszy można wywieść wymagania Na podstawie scenariuszy można wywieść wymagania

systemowesystemowe

Cechy/atrybuty scenariuszaCechy/atrybuty scenariusza INŻYNIERIAOPROGRAMOWANIA

�� Opis stanu systemu na początku scenariuszaOpis stanu systemu na początku scenariusza

�� Opis normalnego następstwa zdarzeń scenariuszaOpis normalnego następstwa zdarzeń scenariusza

�� Opis tego, co może pójść źle, i jak to jest obsługiwaneOpis tego, co może pójść źle, i jak to jest obsługiwane

�� Informacje o innych czynnościach, które można Informacje o innych czynnościach, które można

wykonywać w tym samym czasiewykonywać w tym samym czasie

�� Opis stanu systemu po zakończeniu scenariuszaOpis stanu systemu po zakończeniu scenariusza

�� Każde odrębne zdarzenie w interakcji może być Każde odrębne zdarzenie w interakcji może być

udokumentowane za pomocą oddzielnego scenariusza udokumentowane za pomocą oddzielnego scenariusza

zdarzeniazdarzenia

�� Opis przepływu danych, akcji systemu i wyjątków, które Opis przepływu danych, akcji systemu i wyjątków, które

mogą się pojawićmogą się pojawić

Przykład scenariusza Przykład scenariusza –– system bankomatowysystem bankomatowy INŻYNIERIAOPROGRAMOWANIA

�� Zdarzenie inicjujące:Zdarzenie inicjujące: wsunięto kartę do szczelinywsunięto kartę do szczeliny

�� Stan początkowy:Stan początkowy: karta w bankomaciekarta w bankomacie

�� Opis:Opis: Wyświetl listę dostępnych operacji. Po wybraniu operacji Wyświetl listę dostępnych operacji. Po wybraniu operacji

przez klienta monituj o podanie numeru PIN. Gdy wpisany numer przez klienta monituj o podanie numeru PIN. Gdy wpisany numer

jest poprawny, zidentyfikuj klienta. jest poprawny, zidentyfikuj klienta.

�� Sytuacje wyjątkowe:Sytuacje wyjątkowe:

�� przekroczony limit czasu: zwróć kartęprzekroczony limit czasu: zwróć kartę

�� karta nieważna lub skradziona: zatrzymaj kartękarta nieważna lub skradziona: zatrzymaj kartę

�� niepoprawny numer PIN: zapytaj ponownieniepoprawny numer PIN: zapytaj ponownie

�� niepoprawny numer PIN podany po raz trzeci: zatrzymaj kartęniepoprawny numer PIN podany po raz trzeci: zatrzymaj kartę

�� Stan końcowy:Stan końcowy: użytkownik zidentyfikowany, przejdź do realizacji użytkownik zidentyfikowany, przejdź do realizacji

wybranej przez klienta operacji.wybranej przez klienta operacji.

Model przypadków użycia (Model przypadków użycia (UseUse CasesCases)) INŻYNIERIAOPROGRAMOWANIA

�� Metoda oparta na scenariuszach i zewnętrznych punktach widzenia,Metoda oparta na scenariuszach i zewnętrznych punktach widzenia,

służąca do określania wymagań i interakcji użytkownika z systemesłużąca do określania wymagań i interakcji użytkownika z systememm

�� Po raz pierwszy użyta w 1993 (I. Po raz pierwszy użyta w 1993 (I. JacobsonJacobson). Obecnie jest ). Obecnie jest

podstawowym elementem notacji UMLpodstawowym elementem notacji UML

�� Podstawowe pojęcia: Podstawowe pojęcia: przypadek użyciaprzypadek użycia, , aktoraktor, , relacjerelacje między między

przypadkami użycia bądź aktoramiprzypadkami użycia bądź aktorami

�� System widziany jest jako czarna skrzynka, zapewniająca określonSystem widziany jest jako czarna skrzynka, zapewniająca określoną ą

funkcjonalnośćfunkcjonalność

�� Model wyraźnie rozdziela system i to, co powinien realizować Model wyraźnie rozdziela system i to, co powinien realizować

(przypadki użycia i relacje między nimi), od tego, co jest poza (przypadki użycia i relacje między nimi), od tego, co jest poza nim nim

(aktorzy i relacje między nimi)(aktorzy i relacje między nimi)

�� Metoda polega na ilustracji graficznej (diagram przypadków użyciMetoda polega na ilustracji graficznej (diagram przypadków użycia), a),

wspieranej odpowiednimi scenariuszamiwspieranej odpowiednimi scenariuszami

Elementy notacji graficznej: Elementy notacji graficznej: przypadek użycia, aktorprzypadek użycia, aktor


�� Aktor:Aktor: abstrakcyjny użytkownik systemu, reprezentujący grupę użytkowniabstrakcyjny użytkownik systemu, reprezentujący grupę użytkowników ków

używających podobnych funkcji systemu i sposobu z nim komunikacjużywających podobnych funkcji systemu i sposobu z nim komunikacjii

symbol graficzny:symbol graficzny:

�� Przypadek użycia:Przypadek użycia: ciąg interakcji pomiędzy aktorem a systemem, dostarczający ciąg interakcji pomiędzy aktorem a systemem, dostarczający

aktorowi pożądanych wynikówaktorowi pożądanych wyników

symbol graficzny:symbol graficzny:

�� Klasyfikacja aktorów:Klasyfikacja aktorów:

�� aktor główny:aktor główny: używa podstawowych funkcji systemuużywa podstawowych funkcji systemu

�� aktor drugorzędny:aktor drugorzędny: używa funkcji administracyjnych i pielęgnacyjnych używa funkcji administracyjnych i pielęgnacyjnych

�� aktor aktywny:aktor aktywny: inicjuje przypadek użyciainicjuje przypadek użycia

�� aktor pasywny:aktor pasywny: uczestniczy w przypadku użycia, ale go nie inicjujeuczestniczy w przypadku użycia, ale go nie inicjuje

Podstawowe relacjePodstawowe relacje INŻYNIERIAOPROGRAMOWANIA

�� Relacja „Relacja „komunikujekomunikuje” („” („communicatescommunicates”, często ”, często

reprezentowana przez zwykłe wiązanie reprezentowana przez zwykłe wiązanie ––

„„associationassociation”)”)

W przypadku W przypadku dwukieunkowymdwukieunkowym (bez strzałki) (bez strzałki)

oznacza inicjowanie przypadku użycia i ew. oznacza inicjowanie przypadku użycia i ew.

odbieranie wyników przez aktora. W przypadku odbieranie wyników przez aktora. W przypadku

relacji jednokierunkowej, aktor jedynie inicjuje relacji jednokierunkowej, aktor jedynie inicjuje

przypadek użycia (aktor aktywny) lub w nim przypadek użycia (aktor aktywny) lub w nim

uczestniczy (aktor pasywny).uczestniczy (aktor pasywny).

�� Relacja „Relacja „zawierazawiera” („” („includeinclude”) ”)

Wskazuje na wspólny fragment kilku Wskazuje na wspólny fragment kilku

przypadków użycia, wykorzystanie wspólnego przypadków użycia, wykorzystanie wspólnego

zachowania. Dawna nazwa: „używa” („zachowania. Dawna nazwa: „używa” („usesuses”).”).

�� Relacja „Relacja „rozszerzarozszerza” („” („extendextend”) ”)

Rozszerza przypadek użycia o sytuację Rozszerza przypadek użycia o sytuację

wyjątkową. Dawna nazwa: „wyjątkową. Dawna nazwa: „extendsextends”.”.

Relacje uogólnienia i inne elementy notacjiRelacje uogólnienia i inne elementy notacji INŻYNIERIAOPROGRAMOWANIA

�� Relacja Relacja uogólnienia aktorauogólnienia aktora („(„actoractor

generalizationgeneralization”)”)

�� Relacja Relacja uogólnienia przypadku użyciauogólnienia przypadku użycia

(„(„useuse casecase generalizationgeneralization”)”)

�� Granice systemu są wyznaczane za pomocą prostokąta. Aktorzy są Granice systemu są wyznaczane za pomocą prostokąta. Aktorzy są

zwykle na zewnątrz systemu, przypadki użycia wewnątrzzwykle na zewnątrz systemu, przypadki użycia wewnątrz

�� Możliwa jest komunikacja aktorów poza systememMożliwa jest komunikacja aktorów poza systemem

�� W szczególności aktorem może być jakiś element systemu (W szczególności aktorem może być jakiś element systemu (npnp. .

wyświetlacz, wyświetlacz, timertimer) lub (rzadziej) jakieś wymaganie ) lub (rzadziej) jakieś wymaganie

niefunkcjonalne/dziedzinowe niefunkcjonalne/dziedzinowe

Przykład kompletnego diagramuPrzykład kompletnego diagramu INŻYNIERIAOPROGRAMOWANIA

Inny kompletny diagram przypadków użycia był zaprezentowany na poprzednim wykładzie

Przykład scenariuszaPrzykład scenariusza INŻYNIERIAOPROGRAMOWANIA

�� Przypadek użycia:Przypadek użycia: Wypłata gotówkiWypłata gotówki

�� Aktorzy:Aktorzy: Własny klient, Obcy klientWłasny klient, Obcy klient

�� Zdarzenie inicjujące:Zdarzenie inicjujące: wybranie w menu opcji „wypłata” oraz wybranie w menu opcji „wypłata” oraz

podanie kwoty do wypłatypodanie kwoty do wypłaty

�� Stan początkowy:Stan początkowy: karta w bankomaciekarta w bankomacie

�� Opis:Opis: Monituj o podanie numeru PIN. Gdy wpisany numer jest Monituj o podanie numeru PIN. Gdy wpisany numer jest

poprawny, zidentyfikuj klienta i sprawdź dostępne środki na koncpoprawny, zidentyfikuj klienta i sprawdź dostępne środki na koncie. ie.

Jeżeli środki są wystarczające, wypłać gotówkę.Jeżeli środki są wystarczające, wypłać gotówkę.

�� Sytuacje wyjątkowe:Sytuacje wyjątkowe:

�� karta nieważna lub skradziona: zatrzymaj kartękarta nieważna lub skradziona: zatrzymaj kartę

�� niepoprawny numer PIN: zapytaj ponownieniepoprawny numer PIN: zapytaj ponownie

�� niepoprawny numer PIN podany po raz trzeci z kolei: zatrzymaj kniepoprawny numer PIN podany po raz trzeci z kolei: zatrzymaj kartęartę

�� brak środków na koncie: wyświetl komunikat „Brak środków”brak środków na koncie: wyświetl komunikat „Brak środków”

�� Stan końcowy:Stan końcowy: gotówka wypłacona, saldo konta zmniejszonegotówka wypłacona, saldo konta zmniejszone

Model przypadków użycia Model przypadków użycia –– najczęstsze błędynajczęstsze błędy INŻYNIERIAOPROGRAMOWANIA

� Granice systemu nie są zdefiniowane bądź nie są stałe

� Przypadki użycia są napisane z perspektywy systemu a nie aktorów

� Nazwy aktorów lub przypadków użycia są niespójne

� Zbyt dużo przypadków użycia

� Zbyt skompilowana pajęczyna relacji

� Zbyt długi scenariusz przypadku użycia

� Mylący scenariusz/specyfikacja przypadków użycia

� Przypadki użycia nieprawidłowo opisują funkcjonalność

systemu

� Przypadki użycia nie są zrozumiałe dla klienta

� Przypadki użycia nigdy nie są ukończone…

Model przypadków użycia Model przypadków użycia –– podsumowaniepodsumowanie INŻYNIERIAOPROGRAMOWANIA

�� Identyfikacja granic systemu i aktorów Identyfikacja granic systemu i aktorów

�� Specyfikacja wymagań funkcjonalnych, Specyfikacja wymagań funkcjonalnych,

postrzeganych przez zewnętrznych aktorówpostrzeganych przez zewnętrznych aktorów

�� Wspomaganie walidacji wymagańWspomaganie walidacji wymagań

�� Punkt wyjścia dla testów systemuPunkt wyjścia dla testów systemu

�� Przydatność dla celów prezentacji funkcjonalności Przydatność dla celów prezentacji funkcjonalności

systemu systemu –– zrozumiałość i komunikatywnośćzrozumiałość i komunikatywność

�� Podstawa do tworzenia diagramów sekwencjiPodstawa do tworzenia diagramów sekwencji

Diagram sekwencji (ang. Diagram sekwencji (ang. sequencesequence diagram)diagram) INŻYNIERIAOPROGRAMOWANIA

Diagram sekwencjiDiagram sekwencji

zostanie szczegółowo zostanie szczegółowo

omówiony na wykładzie omówiony na wykładzie

poświęconym językowi poświęconym językowi

UMLUML

Sprawdzanie i zatwierdzanie wymagańSprawdzanie i zatwierdzanie wymagań INŻYNIERIAOPROGRAMOWANIA

Przed zatwierdzeniem specyfikacji, wymagania należy Przed zatwierdzeniem specyfikacji, wymagania należy sprawdzić sprawdzić –– wykazać, że definiują system,wykazać, że definiują system,

którego chce użytkownikktórego chce użytkownik

�� Sprawdzenie ważności.Sprawdzenie ważności. Czy użytkownicy są przekonani, że system powinien spełniać Czy użytkownicy są przekonani, że system powinien spełniać

wyspecyfikowane funkcje?wyspecyfikowane funkcje?

�� Sprawdzenie zrozumiałości.Sprawdzenie zrozumiałości. Czy klienci i użytkownicy systemu dobrze zrozumieli Czy klienci i użytkownicy systemu dobrze zrozumieli

wymaganie?wymaganie?

�� Sprawdzenie pochodzenia.Sprawdzenie pochodzenia. Czy zaznaczone jest źródło, z którego pochodzi wymaganie?Czy zaznaczone jest źródło, z którego pochodzi wymaganie?

�� Sprawdzenie niesprzeczności.Sprawdzenie niesprzeczności. Czy wymagania nie przeczą sobie nawzajem?Czy wymagania nie przeczą sobie nawzajem?

�� Sprawdzenie kompletności.Sprawdzenie kompletności. Czy zdefiniowano wszystkie funkcje i ograniczenia systemu?Czy zdefiniowano wszystkie funkcje i ograniczenia systemu?

�� Sprawdzenie realności.Sprawdzenie realności. Czy wymagania można zaimplementować przy użyciu dostępnych Czy wymagania można zaimplementować przy użyciu dostępnych

środków?środków?

�� Możliwość weryfikacji.Możliwość weryfikacji. Czy wymagania systemowe są napisane tak, aby można było je Czy wymagania systemowe są napisane tak, aby można było je

zweryfikować?zweryfikować?

�� Sprawdzenie giętkości.Sprawdzenie giętkości. Czy wymaganie może być zmienione bez znaczącego wpływu na Czy wymaganie może być zmienione bez znaczącego wpływu na

pozostałe wymagania?pozostałe wymagania?

Zarządzanie wymaganiamiZarządzanie wymaganiami INŻYNIERIAOPROGRAMOWANIA

�� Oznakowanie wymagańOznakowanie wymagań

Każde wymaganie musi być unikatowo oznakowane tak, aby można Każde wymaganie musi być unikatowo oznakowane tak, aby można

było robić do niego odnośniki z innych wymagań i używać tego było robić do niego odnośniki z innych wymagań i używać tego

wymagania przy ocenianiu pochodzenia.wymagania przy ocenianiu pochodzenia.

�� Strategia śledzenia pochodzeniaStrategia śledzenia pochodzenia

Należy odnotowywać zależności między wymaganiami i projektem Należy odnotowywać zależności między wymaganiami i projektem

systemu używając określonej metody.systemu używając określonej metody.

�� Proces zarządzania zmianamiProces zarządzania zmianami

Zbiór czynności szacowania wpływu zmian na system i ich kosztu.Zbiór czynności szacowania wpływu zmian na system i ich kosztu.

�� Użycie narzędzi CASEUżycie narzędzi CASE

Zarządzanie wymaganiami polega na przetwarzaniu ogromnej liczby Zarządzanie wymaganiami polega na przetwarzaniu ogromnej liczby

informacji o wymaganiach. Narzędzia CASE nie są zbyt informacji o wymaganiach. Narzędzia CASE nie są zbyt

rozbudowane w inżynierii wymagań, ale pomagają rozbudowane w inżynierii wymagań, ale pomagają npnp. w weryfikacji . w weryfikacji

wymagań formalnych czy tworzeniu diagramów UML.wymagań formalnych czy tworzeniu diagramów UML.

Stabilność wymagańStabilność wymagań INŻYNIERIAOPROGRAMOWANIA

�� Wymagania stałeWymagania stałe –– względnie stabilne wymagania, które wynikają z względnie stabilne wymagania, które wynikają z

podstawowej działalności firmy i bezpośrednio odnoszą się do podstawowej działalności firmy i bezpośrednio odnoszą się do

dziedziny systemudziedziny systemu

�� Wymagania zmienneWymagania zmienne –– wymagania, które z dość dużym wymagania, które z dość dużym

prawdopodobieństwem mogą ulec zmianie w trakcie tworzenia prawdopodobieństwem mogą ulec zmianie w trakcie tworzenia

systemu albo po przekazaniu go do użytkowaniasystemu albo po przekazaniu go do użytkowania

�� wymagania zmieniające się:wymagania zmieniające się: zmieniają się na skutek zmian środowiska, w zmieniają się na skutek zmian środowiska, w

którym działa firma.którym działa firma.

�� wymagania pojawiające się:wymagania pojawiające się: pojawiają się w trakcie procesu tworzenia w miarę pojawiają się w trakcie procesu tworzenia w miarę

coraz lepszego rozumienia systemu przez klienta.coraz lepszego rozumienia systemu przez klienta.

�� wymagania wynikowe:wymagania wynikowe: wynikają z wdrożenia systemu komputerowego.wynikają z wdrożenia systemu komputerowego.

�� wymagania zgodności:wymagania zgodności: zzależą od umów lub procesów gospodarczych ależą od umów lub procesów gospodarczych

wewnątrz firmy.wewnątrz firmy.

Wymagania stawiane dużym systemom oprogramowania Wymagania stawiane dużym systemom oprogramowania zawsze się zmieniają zawsze się zmieniają –– trzeba odnotowywać zmianytrzeba odnotowywać zmiany

Zarządzanie zmianami wymagańZarządzanie zmianami wymagań INŻYNIERIAOPROGRAMOWANIA

Zarządzanie zmianami wymagań należy stosować do wszystkich Zarządzanie zmianami wymagań należy stosować do wszystkich

postulowanych zmian wymagańpostulowanych zmian wymagań

Trzy podstawowe kroki:Trzy podstawowe kroki:

�� Analiza problemu i specyfikacja zmiany.Analiza problemu i specyfikacja zmiany. Rozpoznanie problemu z Rozpoznanie problemu z

wymaganiem, konkretna propozycja zmianywymaganiem, konkretna propozycja zmiany

�� Analiza zmiany i ocena kosztów.Analiza zmiany i ocena kosztów. Korzystając z informacji o Korzystając z informacji o

uzależnieniu wymagania od innych i ogólnej wiedzy o wymaganiach uzależnieniu wymagania od innych i ogólnej wiedzy o wymaganiach

systemowych, ocenia się wpływ proponowanej zmiany na cały systemowych, ocenia się wpływ proponowanej zmiany na cały

system i szacuje koszt zmianysystem i szacuje koszt zmiany

�� Implementacja zmiany.Implementacja zmiany. W przypadku podjęcia decyzji o W przypadku podjęcia decyzji o

wprowadzeniu zmiany, modyfikuje się dokumentację wymagań oraz wprowadzeniu zmiany, modyfikuje się dokumentację wymagań oraz

projekt a następnie implementuje się zmianęprojekt a następnie implementuje się zmianę

LiteraturaLiteratura INŻYNIERIAOPROGRAMOWANIA

�� B.W. B.W. Boehm, Boehm, P.N. P.N. PapaccioPapaccio,, Understanding and Understanding and CControlingontroling Software Software

CostCost. . IEEE Press, 1988IEEE Press, 1988

� A. Cockburn, Writing Effective Use Cases. In preparation for Addison-

Wesley Longman, 2000http://www.itu.dk/~petero/t9%20.Net/UseCases-Cockburn.pdf

� Materiały na stronie http://www.parlezuml.com

� Materiały na stronie http://owymaganiach.pl

� K. E. Wiegers, Software Requirements, 2nd Edition. Microsoft Press,

2003

inżynieria wymagań. proces inżynierii wymagań · analiza istniejącego procesu w firmie...

Documents