Inżynieria Programowania Inżynieria wymagań

Podobne dokumenty
Inżynieria Programowania Inżynieria wymagań. Plan wykładu. Motto. Wstęp. Notatki. Notatki. Notatki. Notatki. Arkadiusz Chrobot

Inżynieria oprogramowania. Wykład 7 Inżynieria wymagań: punkty widzenia, scenariusze, przypadki użycia

Proces Inżynierii Wymagań

Inżynieria wymagań. Inżynieria wymagań 1/1

Co to jest jest oprogramowanie? 8. Co to jest inżynieria oprogramowania? 9. Jaka jest różnica pomiędzy inżynierią oprogramowania a informatyką?

Wykład 3 Wymagania. MIS n Inżynieria oprogramowania Październik Kazimierz Michalik Akademia Górniczo-Hutnicza im. S. Staszica w Krakowie

Faza Określania Wymagań

Inżynieria Programowania Zarządzanie projektem

Inżynieria Programowania Zarządzanie projektem. Plan wykładu. Motto. Motto 2. Notatki. Notatki. Notatki. Notatki.

Analiza i projektowanie oprogramowania. Analiza i projektowanie oprogramowania 1/32

Projekt dotyczy stworzenia zintegrowanego, modularnego systemu informatycznego wspomagającego zarządzanie pracownikami i projektami w firmie

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

Diagramy ERD. Model struktury danych jest najczęściej tworzony z wykorzystaniem diagramów pojęciowych (konceptualnych). Najpopularniejszym

Zasady organizacji projektów informatycznych

Instrukcja 3 Laboratoria 3, 4 Specyfikacja wymagań funkcjonalnych za pomocą diagramu przypadków użycia

Gry społecznościowe. wykład 0. Joanna Kołodziejczyk. 24 lutego Joanna Kołodziejczyk Gry społecznościowe 24 lutego / 11

Projektowanie oprogramowania cd. Projektowanie oprogramowania cd. 1/34

Instrukcja 3 Laboratoria 3, 4 Specyfikacja wymagań funkcjonalnych za pomocą diagramu przypadków użycia

Wprowadzenie do metodologii modelowania systemów informacyjnych. Strategia (1) Strategia (2) Etapy Ŝycia systemu informacyjnego

PRZEWODNIK PO PRZEDMIOCIE

Zastosowanie symulacji Monte Carlo do zarządzania ryzykiem przedsięwzięcia z wykorzystaniem metod sieciowych PERT i CPM

Cykle życia systemu informatycznego

PLAN ZARZĄDZANIA WYMAGANIAMI PROJEKT <NAZWA PROJEKTU> WERSJA <NUMER WERSJI DOKUMENTU>

REQB POZIOM PODSTAWOWY PRZYKŁADOWY EGZAMIN

Instrukcja 3 Laboratoria 3, 4 Specyfikacja wymagań funkcjonalnych za pomocą diagramu przypadków użycia

ZARZĄDZANIE STRATEGICZNE OPRACOWANIE

Etapy życia oprogramowania

Cele przedsięwzięcia

Spis treúci. 1. Wprowadzenie... 13

Specyfikowanie wymagań przypadki użycia

Inżynieria wymagań. Wykład 3 Zarządzanie wymaganiami w oparciu o przypadki użycia. Część 5 Definicja systemu

Projektowanie BAZY DANYCH

Projektowanie systemów informatycznych. Roman Simiński siminskionline.pl. Inżyniera wymagań

Inżynieria oprogramowania (Software Engineering)

Egzamin / zaliczenie na ocenę*

Wykład 2 Rola otoczenia w procesie formułowania strategii organizacji

Wykorzystanie standardów serii ISO oraz OGC dla potrzeb budowy infrastruktury danych przestrzennych

Wstęp. Inżynieria wymagań. Plan wykładu. Wstęp. Wstęp. Wstęp. Schemat procesu pozyskiwania wymagań

Komputerowe Systemy Przemysłowe: Modelowanie - UML. Arkadiusz Banasik arkadiusz.banasik@polsl.pl

PRZEWODNIK PO PRZEDMIOCIE

Modelowanie i analiza systemów informatycznych Spis treści

Etapy życia oprogramowania. Modele cyklu życia projektu. Etapy życia oprogramowania. Etapy życia oprogramowania

Narzędzia informatyczne wspierające przedsięwzięcia e-commerce

Analiza danych i data mining.

Organizacja procesu projektowania, rozwoju i serwisowania systemu wspomagającego zarzadzanie uczelnią

zna metody matematyczne w zakresie niezbędnym do formalnego i ilościowego opisu, zrozumienia i modelowania problemów z różnych

Nazwa przedmiotu: MODELOWANIE I ANALIZA SYSTEMÓW INFORMATYCZNYCH. Modeling and analysis of computer systems Forma studiów: Stacjonarne

Jakość w procesie wytwarzania oprogramowania

Narzędzia CASE dla.net. Łukasz Popiel

Zagadnienia (1/3) Inżynieria Oprogramowania

Inżynieria oprogramowania

Wykład 1 Inżynieria Oprogramowania

Rozdział 4 Planowanie rozwoju technologii - Aleksander Buczacki 4.1. Wstęp 4.2. Proces planowania rozwoju technologii

ZARZĄDZANIE I INŻYNIERIA PRODUKCJI

Określanie wymagań. Cele przedsięwzięcia. Kontekst przedsięwzięcia. Rodzaje wymagań. Diagramy przypadków użycia use case diagrams

Projektowanie i wdrażanie systemów informatycznych (materiały do wykładu cz. II)

Matryca efektów kształcenia dla programu studiów podyplomowych ZARZĄDZANIE I SYSTEMY ZARZĄDZANIA JAKOŚCIĄ

OBIEG INFORMACJI I WSPOMAGANIE DECYZJI W SYTUACJACH KRYZYSOWYCH

Modelowanie i analiza systemów informatycznych

Podstawy modelowania programów Kod przedmiotu

Analiza biznesowa a metody agile owe

Usługa: Testowanie wydajności oprogramowania

Przedsięwzięcia Informatyczne w Zarządzaniu

Projekt: Współpraca i Rozwój wzrost potencjału firm klastra INTERIZON

Tom 6 Opis oprogramowania Część 8 Narzędzie do kontroli danych elementarnych, danych wynikowych oraz kontroli obmiaru do celów fakturowania

E-1IZ s2. Informatyka II stopień (I stopień / II stopień) ogólnoakademicki (ogólno akademicki / praktyczny)

Programowanie gier. wykład 0. Joanna Kołodziejczyk. 30 września Joanna Kołodziejczyk Programowanie gier 30 września / 13

AKADEMIA GÓRNICZO-HUTNICZA

E-I2SG-2010-s1. Informatyka II stopień (I stopień / II stopień) ogólnoakademicki (ogólno akademicki / praktyczny)

Metodyka wdrożenia. Bartosz Szczęch. Starszy Konsultant MS Dynamics NAV

WIEDZA T1P_W06. K_W01 ma podstawową wiedzę o zarządzaniu jako nauce, jej miejscu w systemie nauk i relacjach do innych nauk;

Projektowanie Graficznych Interfejsów Użytkownika Robert Szmurło

Liczba godzin Punkty ECTS Sposób zaliczenia. ćwiczenia 16 zaliczenie z oceną

POLITECHNIKA OPOLSKA

PRZEWODNIK PO PRZEDMIOCIE

Inżynieria wymagań. Jarosław Kuchta Dokumentacja i Jakość Oprogramowania

1. WYMAGANIA WSTĘPNE W ZAKRESIE WIEDZY, UMIEJĘTNOŚCI I INNYCH KOMPETENCJI

Polityka bezpieczeństwa informacji Główne zagadnienia wykładu

Efekty kształcenia dla kierunku: Gospodarka przestrzenna I stopień

MiASI. Modele, perspektywy, diagramy UML. Piotr Fulmański. 7 grudnia Wydział Matematyki i Informatyki, Uniwersytet Łódzki, Polska

Język UML w modelowaniu systemów informatycznych

Planowanie tras transportowych

Procesowa specyfikacja systemów IT

SYSTEMY INFORMATYCZNE ćwiczenia praktyczne

Zagadnienia (1/3) Data-flow diagramy przepływów danych ERD diagramy związków encji Diagramy obiektowe w UML (ang. Unified Modeling Language)

Launch. przygotowanie i wprowadzanie nowych produktów na rynek

Wymagania klienta mogą być opisane na różnych poziomach abstrakcji: Podział wymagań: Wymagania funkcjonalne Wymagania niefunkcjonalne

Zintegrowany System Zarządzania w Śląskim Centrum Społeczeństwa Informacyjnego

Egzamin / zaliczenie na ocenę* 0,5 0,5

KARTA MODUŁU KSZTAŁCENIA

INŻYNIERIA OPROGRAMOWANIA TESTOWANIE SYSTEMOWE

Podstawy programowania III WYKŁAD 4

Prezentacja programu. Parentis Sp. z o.o. Dział Informatyki. Kartoszyno, ul. Przemysłowa 5, Krokowa

Jarosław Żeliński analityk biznesowy, projektant systemów

Poniższy program może być skrócony do 1 dnia lub kilkugodzinnej prezentacji.

Adonis w Banku Spółdzielczym w Trzebnicy

Bazy danych 2. Wykład 1

KIERUNKOWE EFEKTY KSZTAŁCENIA

PRZEWODNIK PO PRZEDMIOCIE

Transkrypt:

Katedra Informatyki, Politechnika Świętokrzyska w Kielcach Kielce, 11 marca 2017

Plan wykładu 1 2 3 Określanie i analizowanie wymagań 4 5

Plan wykładu 1 2 3 Określanie i analizowanie wymagań 4 5

Plan wykładu 1 2 3 Określanie i analizowanie wymagań 4 5

Plan wykładu 1 2 3 Określanie i analizowanie wymagań 4 5

Plan wykładu 1 2 3 Określanie i analizowanie wymagań 4 5

Motto Plan wykładu Dział sprzedaży cybernetycznej korporacji Syriusza definiuje robota jako «przyjaciela, z którym przyjemnie przebywać». Autostopem przez Galaktykę definiuje dział sprzedaży cybernetycznej korporacji Syriusza jako «sforę bezmózgich szaleńców, którzy pierwsi pójdą pod ścianę, gdy nadejdzie rewolucja».... Douglas Adams, Autostopem przez galaktykę

Plan wykładu Inżynieria wymagań (ang. requirements engineering) jest procesem, którego celem jest opracowanie, a następnie aktualizacja dokumentacji wymagań dla oprogramowania.

Proces inżynierii wymagań Studium wykonalności Określanie i analizowanie wymagań Specyfikowanie wymagań Zatwierdzanie wymagań Raport o wykonywalności Model systemu Wymagania systemowe i użytkownika Dokumentacja wymagań

jest krótkim opracowaniem, które odpowiada na trzy następujące pytania: 1 Czy system przyczyni się do realizacji ogólnych celów przedsiębiorstwa? 2 Czy system może być zaimplementowany z użyciem dostępnych technologii, w ramach ustalonego budżetu i ograniczeń czasowych? 3 Czy system może być zintegrowany z istniejącymi systemami, które już zainstalowano?

jest krótkim opracowaniem, które odpowiada na trzy następujące pytania: 1 Czy system przyczyni się do realizacji ogólnych celów przedsiębiorstwa? 2 Czy system może być zaimplementowany z użyciem dostępnych technologii, w ramach ustalonego budżetu i ograniczeń czasowych? 3 Czy system może być zintegrowany z istniejącymi systemami, które już zainstalowano?

jest krótkim opracowaniem, które odpowiada na trzy następujące pytania: 1 Czy system przyczyni się do realizacji ogólnych celów przedsiębiorstwa? 2 Czy system może być zaimplementowany z użyciem dostępnych technologii, w ramach ustalonego budżetu i ograniczeń czasowych? 3 Czy system może być zintegrowany z istniejącymi systemami, które już zainstalowano?

Pytania ułatwiające zebranie informacji: 1 Jak firma poradziłaby sobie, jeśli system nie byłby zaimplementowany? 2 Jakie problemy występują w obecnie przyjętych procesach i jak nowy system ma pomóc w ich eliminacji? 3 Jaki byłby bezpośredni wkład systemu w osiąganie celów gospodarczych? 4 Czy można przekazywać informacje do i z innych systemów przedsiębiorstwa? 5 Czy system wymaga technologii, których wcześniej w firmie nie stosowano? 6 Co system musi wspomagać, a czego nie musi?

Punkty widzenia Scenariusze Etnografia Trudności które mogą powstać podczas określania i analizy wymagań: 1 Uczestnicy systemu (osoby bezpośrednio lub pośrednio wpływające na wymagania systemowe) mogą nie do końca wiedzieć, czego oczekują od systemu komputerowego. 2 Uczestnicy systemu posługują się słownictwem z dziedziny zastosowania, z którym mogą być związane niejawne informacje. 3 Wymagania mogą pochodzić od różnych uczestników systemu i mogą być różnie sformułowane. Należy określić wszystkie źródła wymagań, usunąć sprzeczności i odkryć zbieżności. 4 Wpływ na wymagania mogą mieć czynniki polityczne. 5 Środowisko w którym prowadzi się analizę ulega zmianom, a więc wymagania również zmieniają się.

Punkty widzenia Scenariusze Etnografia Trudności które mogą powstać podczas określania i analizy wymagań: 1 Uczestnicy systemu (osoby bezpośrednio lub pośrednio wpływające na wymagania systemowe) mogą nie do końca wiedzieć, czego oczekują od systemu komputerowego. 2 Uczestnicy systemu posługują się słownictwem z dziedziny zastosowania, z którym mogą być związane niejawne informacje. 3 Wymagania mogą pochodzić od różnych uczestników systemu i mogą być różnie sformułowane. Należy określić wszystkie źródła wymagań, usunąć sprzeczności i odkryć zbieżności. 4 Wpływ na wymagania mogą mieć czynniki polityczne. 5 Środowisko w którym prowadzi się analizę ulega zmianom, a więc wymagania również zmieniają się.

Punkty widzenia Scenariusze Etnografia Trudności które mogą powstać podczas określania i analizy wymagań: 1 Uczestnicy systemu (osoby bezpośrednio lub pośrednio wpływające na wymagania systemowe) mogą nie do końca wiedzieć, czego oczekują od systemu komputerowego. 2 Uczestnicy systemu posługują się słownictwem z dziedziny zastosowania, z którym mogą być związane niejawne informacje. 3 Wymagania mogą pochodzić od różnych uczestników systemu i mogą być różnie sformułowane. Należy określić wszystkie źródła wymagań, usunąć sprzeczności i odkryć zbieżności. 4 Wpływ na wymagania mogą mieć czynniki polityczne. 5 Środowisko w którym prowadzi się analizę ulega zmianom, a więc wymagania również zmieniają się.

Punkty widzenia Scenariusze Etnografia Trudności które mogą powstać podczas określania i analizy wymagań: 1 Uczestnicy systemu (osoby bezpośrednio lub pośrednio wpływające na wymagania systemowe) mogą nie do końca wiedzieć, czego oczekują od systemu komputerowego. 2 Uczestnicy systemu posługują się słownictwem z dziedziny zastosowania, z którym mogą być związane niejawne informacje. 3 Wymagania mogą pochodzić od różnych uczestników systemu i mogą być różnie sformułowane. Należy określić wszystkie źródła wymagań, usunąć sprzeczności i odkryć zbieżności. 4 Wpływ na wymagania mogą mieć czynniki polityczne. 5 Środowisko w którym prowadzi się analizę ulega zmianom, a więc wymagania również zmieniają się.

Punkty widzenia Scenariusze Etnografia Trudności które mogą powstać podczas określania i analizy wymagań: 1 Uczestnicy systemu (osoby bezpośrednio lub pośrednio wpływające na wymagania systemowe) mogą nie do końca wiedzieć, czego oczekują od systemu komputerowego. 2 Uczestnicy systemu posługują się słownictwem z dziedziny zastosowania, z którym mogą być związane niejawne informacje. 3 Wymagania mogą pochodzić od różnych uczestników systemu i mogą być różnie sformułowane. Należy określić wszystkie źródła wymagań, usunąć sprzeczności i odkryć zbieżności. 4 Wpływ na wymagania mogą mieć czynniki polityczne. 5 Środowisko w którym prowadzi się analizę ulega zmianom, a więc wymagania również zmieniają się.

Punkty widzenia Scenariusze Etnografia Specyfikacja wymagań Sprawdzenie wymagań Początek procesu Rozpoznanie dziedziny Nadanie priorytetów Dokumentacja wymagań Zbieranie wymagań Usuwanie sprzeczności Klasyfikacja

Przykład systemu Plan wykładu Punkty widzenia Scenariusze Etnografia Uczestnicy systemu bankomatu: Obecni klienci banków Przedstawiciele innych banków Dyrektorzy oddziałów banków Pracownicy obsługi klienta Administratorzy baz danych Osoby odpowiedzialne za bezpieczeństwo w banku Dział marketingu banku Inżynierowie pielęgnacji sprzętu i oprogramowania

Punkty widzenia Plan wykładu Punkty widzenia Scenariusze Etnografia Punkty widzenia mogą być określane jako: Źródło lub przeznaczenie danych - osoba, która produkuje lub konsumuje dane. Zrąb reprezentacji - osoba związana z konkretnym typem systemu. Odbiorca usług - osoby korzystające z systemu, są zewnętrznymi punktami widzenia.

Punkty widzenia Plan wykładu Punkty widzenia Scenariusze Etnografia Punkty widzenia mogą być określane jako: Źródło lub przeznaczenie danych - osoba, która produkuje lub konsumuje dane. Zrąb reprezentacji - osoba związana z konkretnym typem systemu. Odbiorca usług - osoby korzystające z systemu, są zewnętrznymi punktami widzenia.

Punkty widzenia Plan wykładu Punkty widzenia Scenariusze Etnografia Punkty widzenia mogą być określane jako: Źródło lub przeznaczenie danych - osoba, która produkuje lub konsumuje dane. Zrąb reprezentacji - osoba związana z konkretnym typem systemu. Odbiorca usług - osoby korzystające z systemu, są zewnętrznymi punktami widzenia.

Punkty widzenia Scenariusze Etnografia Zalety zewnętrznych punktów widzenia W przypadku systemów interaktywnych najlepiej jest stosować zewnętrzne punkty widzenia, gdyż: 1 stanowią naturalny sposób strukturalizacji procesu określania wymagań, 2 łatwo jest je zidentyfikować, 3 punkty widzenia i usługi stanowią dobry sposób strukturalizacji wymagań niefunkcjonalnych.

Metoda VORD Plan wykładu Punkty widzenia Scenariusze Etnografia Identyfikacja punktów widzenia Strukturalizacja punktów widzenia Dokumentacja punktów widzenia Przyporządkowanie punktów widzenia do systemu

Punkty widzenia Scenariusze Etnografia Szablony formularzy punktów widzenia i usług Szablon do punktów widzenia Odnośnik: Nazwa punktu widzenia. Atrybuty: Atrybuty z informacją o punkcie widzenia. Zdarzenia: Odnośniki do zbioru scenariuszy zdarzeń opisujących jak system reaguje na zdarzenia w ramach tego punktu widzenia. Usługi: Odnośniki do zbioru opisów usług. Podrzędne PW: Nazwy podrzędnych punktów widzenia. Szablon do usług Odnośnik: Nazwa usługi. Uzasadnienie: Przyczyna oferowania usługi. Specyfikacja: Odnośnik do listy specyfikacji usług, które mogą być opisane za pomocą różnych notacji. Punkty widzenia: Lista nazw punktów widzenia, których reprezentanci korzystają z usług. Wymagania niefunkcjonalne: Odnośnik do zbioru wymagań niefunkcjonalnych ograniczających usługę. Dostawca: Odnośnik do listy obiektów systemu, które oferują tę usługę.

Punkty widzenia Scenariusze Etnografia Burza mózgów - identyfikacja punktów widzenia

Punkty widzenia Scenariusze Etnografia Informacja o usługach przypisanych do punktu widzenia

Punkty widzenia Scenariusze Etnografia Dane wejściowe i dane sterujące związane z punktem widzenia

Hierarchia punktów widzenia Punkty widzenia Scenariusze Etnografia

Punkty widzenia Scenariusze Etnografia Opis punktu widzenia klienta i opis usługi wypłaty gotówki

Punkty widzenia Scenariusze Etnografia Scenariusz zdarzenia Zacznij transakcję

Scenariusz zdarzenia Punkty widzenia Scenariusze Etnografia 1 Dane odbierane z i przekazywane do reprezentantów punktów widzenia są przedstawione w postaci elips. 2 Informacja sterująca wchodzi i opuszcza każdy prostokąt od góry. 3 Dane opuszczają prostokąty z prawej strony. Jeśli te dane nie są otoczone elipsą, oznacza to, że są wewnętrzne dla systemu. 4 Wyjątki są pokazywane na dole prostokątów. Jeśli tych wyjątków jest kilka, to otacza się je prostokątem. 5 Nazwa następnego zdarzenia oczekiwanego po zakończeniu scenariusza jest przedstawiana w cieniowanym prostokącie.

Punkty widzenia Scenariusze Etnografia Przypadek użycia - wypożyczanie

Przypadki użycia biblioteki Punkty widzenia Scenariusze Etnografia

Punkty widzenia Scenariusze Etnografia Diagram sekwencji zarządzania katalogiem

Etnografia Plan wykładu Punkty widzenia Scenariusze Etnografia Etnografia jest szczególnie przydatna do znajdywania dwóch następujących typów wymagań: 1 Wymagania wynikające z rzeczywistego sposobu pracy osób, a nie ze sposobu zalecanego przez formalne definicje procesów. 2 Wymagania, które wynikają z kooperacji i świadomości czynności innych osób.

Punkty widzenia Scenariusze Etnografia Etnografia i prototypowanie w analizie wymagań Analiza etnograficzna Narady Szczegółowa etnografia Ocena prototypu Ogólne tworzenie systemu Prototypowanie systemu

W trakcie zatwierdzania wymagań przeprowadza się następujące sprawdzenia: 1 Sprawdzenie ważności 2 Sprawdzenie niesprzeczności 3 Sprawdzenie kompletności 4 Sprawdzenie realności 5 Możliwość weryfikacji

W trakcie zatwierdzania wymagań przeprowadza się następujące sprawdzenia: 1 Sprawdzenie ważności 2 Sprawdzenie niesprzeczności 3 Sprawdzenie kompletności 4 Sprawdzenie realności 5 Możliwość weryfikacji

W trakcie zatwierdzania wymagań przeprowadza się następujące sprawdzenia: 1 Sprawdzenie ważności 2 Sprawdzenie niesprzeczności 3 Sprawdzenie kompletności 4 Sprawdzenie realności 5 Możliwość weryfikacji

W trakcie zatwierdzania wymagań przeprowadza się następujące sprawdzenia: 1 Sprawdzenie ważności 2 Sprawdzenie niesprzeczności 3 Sprawdzenie kompletności 4 Sprawdzenie realności 5 Możliwość weryfikacji

W trakcie zatwierdzania wymagań przeprowadza się następujące sprawdzenia: 1 Sprawdzenie ważności 2 Sprawdzenie niesprzeczności 3 Sprawdzenie kompletności 4 Sprawdzenie realności 5 Możliwość weryfikacji

Metody zatwierdzania wymagań 1 Przeglądy wymagań 2 Prototypowanie 3 Generowanie testów 4 Zautomatyzowane sprawdzanie niesprzeczności

Metody zatwierdzania wymagań 1 Przeglądy wymagań 2 Prototypowanie 3 Generowanie testów 4 Zautomatyzowane sprawdzanie niesprzeczności

Metody zatwierdzania wymagań 1 Przeglądy wymagań 2 Prototypowanie 3 Generowanie testów 4 Zautomatyzowane sprawdzanie niesprzeczności

Metody zatwierdzania wymagań 1 Przeglądy wymagań 2 Prototypowanie 3 Generowanie testów 4 Zautomatyzowane sprawdzanie niesprzeczności

Zautomatyzowane sprawdzanie niesprzeczności wymagań Wymagania zapisane w języku formalnym Raport o błędach w wymaganiach Procesor wymagań Analizator wymagań Baza danych wymagań

Przegląd wymagań W trakcie formalnego przeglądu należy powołać zespół recenzentów, który sprawdzi: 1 Możliwość weryfikacji - czy wymaganie wyrażono tak, aby można je praktycznie sprawdzić? 2 Zrozumiałość - czy klienci i użytkownicy systemu właściwie pojmują wymaganie? 3 Pochodzenie - czy jawnie zaznaczono źródło z którego pochodzi wymaganie? 4 Elastyczność - czy wymaganie może być zmienione bez znacznego wpływu na inne wymagania?

Przyczyny zmiany wymagań wobec systemu: 1 Ponieważ z dużych systemów korzysta duża liczba użytkowników, to wymagania w stosunku do tego systemu są kompromisem zapotrzebowań użytkowników. Wraz z upływem czasu i nabywaniem doświadczenia może się okazać, że należy zmienić wagi przywiązywane do wymagań poszczególnych użytkowników. 2 Dosyć często klienci i użytkownicy systemu stanowią rozłączną grupę. Klienci formułują wymagania na podstawie ograniczeń budżetowych i organizacyjnych. Te wymagania mogą być w konflikcie z wymaganiami użytkowników. 3 Zmiany mogą wynikać z rozwoju techniki, zmiany celów gospodarczych przedsiębiorstwa lub jego reorganizacji, jak również ze zmiany prawa.

Przyczyny zmiany wymagań wobec systemu: 1 Ponieważ z dużych systemów korzysta duża liczba użytkowników, to wymagania w stosunku do tego systemu są kompromisem zapotrzebowań użytkowników. Wraz z upływem czasu i nabywaniem doświadczenia może się okazać, że należy zmienić wagi przywiązywane do wymagań poszczególnych użytkowników. 2 Dosyć często klienci i użytkownicy systemu stanowią rozłączną grupę. Klienci formułują wymagania na podstawie ograniczeń budżetowych i organizacyjnych. Te wymagania mogą być w konflikcie z wymaganiami użytkowników. 3 Zmiany mogą wynikać z rozwoju techniki, zmiany celów gospodarczych przedsiębiorstwa lub jego reorganizacji, jak również ze zmiany prawa.

Przyczyny zmiany wymagań wobec systemu: 1 Ponieważ z dużych systemów korzysta duża liczba użytkowników, to wymagania w stosunku do tego systemu są kompromisem zapotrzebowań użytkowników. Wraz z upływem czasu i nabywaniem doświadczenia może się okazać, że należy zmienić wagi przywiązywane do wymagań poszczególnych użytkowników. 2 Dosyć często klienci i użytkownicy systemu stanowią rozłączną grupę. Klienci formułują wymagania na podstawie ograniczeń budżetowych i organizacyjnych. Te wymagania mogą być w konflikcie z wymaganiami użytkowników. 3 Zmiany mogą wynikać z rozwoju techniki, zmiany celów gospodarczych przedsiębiorstwa lub jego reorganizacji, jak również ze zmiany prawa.

Ewolucja wymagań ne rozumienie problemu Zmienione rozumienie problemu ne wymagania Zmienione wymagania Czas

Klasyfikacja wymagań Klasy wymagań: 1 Wymagania stałe - względnie niezmienne wymagania wynikające z podstawowej działalności firmy. 2 Wymagania niestabilne - wymagania, które mogą ulec zmianie podczas tworzenia systemu, lub po przekazaniu go do użytkownika.

Klasyfikacja wymagań niestabilnych Typ wymagania Wymagania zmienne Wymagania pojawiające się Wymagania wynikowe Wymagania zgodności Opis Wymagania, które zmieniają się na skutek zmian środowiska, w którym działa firma. Wymagania, które pojawiają się w trakcie procesu tworzenia w miarę coraz lepszego rozumienia systemu przez klienta. Proces projektowania może doprowadzić do odkrycia nowych pojawiających się wymagań. Wymagania, które wynikają z wdrożenia systemu komputerowego. Wprowadzenie takiego systemu może doprowadzić do zmiany procesów przedsiębiorstwa i do wskazania nowych sposobów pracy, które prowadzą do postawienia nowych wymagań. Wymagania, które zależą od konkretnych systemów lub procesów gospodarczych wewnątrz firmy. Jeśli się one zmieniają, to również wymagania zgodności wobec kupionego lub zbudowanego systemu mogą się zmieniać.

Planowanie zarządzania wymaganiami W trakcie planowania zarządzania wymaganiami należy podjąć decyzje co do: 1 oznakowania wymagań, 2 procesu zarządzania zmianami, 3 strategi śledzenia pochodzenia, 4 użycia narzędzi CASE.

Planowanie zarządzania wymaganiami W trakcie planowania zarządzania wymaganiami należy podjąć decyzje co do: 1 oznakowania wymagań, 2 procesu zarządzania zmianami, 3 strategi śledzenia pochodzenia, 4 użycia narzędzi CASE.

Planowanie zarządzania wymaganiami W trakcie planowania zarządzania wymaganiami należy podjąć decyzje co do: 1 oznakowania wymagań, 2 procesu zarządzania zmianami, 3 strategi śledzenia pochodzenia, 4 użycia narzędzi CASE.

Planowanie zarządzania wymaganiami W trakcie planowania zarządzania wymaganiami należy podjąć decyzje co do: 1 oznakowania wymagań, 2 procesu zarządzania zmianami, 3 strategi śledzenia pochodzenia, 4 użycia narzędzi CASE.

Śledzenie wymagań W procesie śledzenia wymagań pomocne są trzy typy informacji: 1 informacje o pochodzeniu, 2 informacje o uzależnieniu wymagań, 3 informacje o uzależnieniu projektu.

Macierz zależności Id wymagań 1.1 1.2 1.3 2.1 2.2 2.3 3.1 3.2 1.1 U R 1.2 U R U 1.3 R R 2.1 R U U 2.2 U 2.3 R U 3.1 R 3.2 R

Wspomaganie zarządzania wymaganiami W procesie zarządzania wymaganiami należy oprzeć się na narzędziach, które są niezbędne do: 1 przechowywania wymagań, 2 zarządzania zmianami, 3 zarządzania zależnościami.

Zarządzanie zmianami wymagań Rozpoznany problem Analiza problemu i specyfikacja zmian Analiza zmian i ocena kosztów Implementacja zmiany Skorygowane wymagania

Pytania Plan wykładu?

Koniec Plan wykładu Dziękuję Państwu za uwagę.