1))

Oprogramowanie-Są to programy komputerowe, cała związana z nimi dokumentacja i dane konfiguracyjne,Rodzaje produktów oprogramowania:: Powszechne; Dostosowane(na zamówienie)*inżynieria oprogramowania-Jest to dziedzina inżynierii, która obejmuje wszystkie aspekty tworzenia oprogramowania od fazy początkowej do jego pielęgnacji. Inżynierowie oprogramowania pracują w sposób systematyczny i uporządkowany ponieważ jest to najskuteczniejszy sposób tworzenia oprogramowania wysokiej jakości różnica pomiędzy inżynierią oprogramowania a informatyka - Zasadniczo informatyka obejmuje teorie i podstawowe zasady działania komputerów. Inżynieria oprogramowania obejmuje praktyczne problemy związane z tworzeniem oprogramowania .Byłoby dobrze gdyby inżynier programowania znał teorie informatyczne, z drugiej strony nie zawsze przystają one do rzeczywistości różnica pomiędzy inżynierią oprogramowania a inżynierią systemów Inżynieria systemów komputerowych obejmuje wszystkie aspekty tworzenia i ewolucji systemów komputerowych, w których oprogramowanie odgrywa zasadniczą rolę. Inżynierowie systemów biorą udział w specyfikacji systemu i definiowania jego ogólnej architektury *proces tworzenia oprogramowania Jest to zbiór czynności i związanych z nimi wyników, które zmierzają do opracowania produktu programowego. Zasadnicze czynności wspólne dla wszystkich procesów Specyfikacja oprogramowania , Tworzenie oprogramowania , Zatwierdzenie oprogramowania , Ewolucja oprogramowania. model procesu tworzenia oprogramowania Jest to uproszczona prezentacja procesu tworzenia oprogramowania. Modele ze swej natury są uproszczeniami .Przykłady takich modeli: Model przepływu prac, Model przepływu danych (lub model czynności), Model rola-akcja Przykłady ogólnych modeli (paradygmatów) tworzenia oprogramowania Model kaskadowy, Tworzenie ewolucyjne, Formalne przekształcenia, Składanie systemu z komponentów ponownego użycia. *metody inżynierii oprogramowania To jest uporządkowane podejście do tworzenia oprogramowania, które obejmuje:: Opisy modeli systemu Np. Modele obiektów, modele przepływu itp.///Reguły Ograniczenia, którym podlegają modele systemu/// Zalecenia Heurystyki, które określają dobre zwyczaje projektantów ///Poradnictwo Opisy czynności, które należy wykonać *CASE (Computer-Aided Software Engineering) CASE obejmuje rożne programy wykorzystane do wspomagania czynności procesu tworzenia oprogramowania (np. edytory notacji, generatory kodów) Upper-CASE Związane z początkowymi fazami tworzenia oprogramowania;; Lower-CASE Wspomagają implementowanie i testowanie *Właściwości dobrego oprogramowania- Zdolność do pielęgnacji(Zdolność do ewolucji zgodnie z potrzebami klientów);;; Niezawodność(Nie powinno powodować fizycznych lub ekonomicznych katastrof w przypadku awarii) ;;; Efektywność(Nie powinno marnotrawić zasobów systemu takich jak pamięć czy czas procesora);;; Użyteczność(Powinno być użyteczne, bez zbędnego wysiłku ze strony użytkownika (np. interfejsy)) *Zasady zawodowej odpowiedzialności Zachowywanie tajemnicy Inżynierowie powinni zawsze dochowywać tajemnic powierzonych przez pracodawców i klientów, niezależnie od tego czy podpisano formalną umowę o ochronie tajemnicy/// Kompetencje Inżynierowie nie powinni zawyżać poziomu swoich kompetencji. Nie powinni świadomie przyjmować prac, które przekraczają ich możliwości/// Prawo własności intelektualnej Inżynierowie powinni znać miejscowe prawo regulujące korzystanie z własności intelektualnej. Powinni szczególnie dbać o poszanowanie intelektualnej własności swoich pracodawców i klientów /// Niewłaściwe użycie komputera Inżynierowie oprogramowania nie powinni używać swoich umiejętności do niewłaściwego używania cudzych komputerów. Niewłaściwe użycie może być dość banalne (np. granie na maszynie pracodawcy) lub skrajnie poważne (rozsiewanie wirusów).

*Kodeks etyki i zawodowej praktyki 1. Społeczeństwo-Inżynierowie oprogramowania powinni postępować dla dobra społeczeństwa 2. Klient i pracodawca Inżynierowie oprogramowania powinni postępować zgodnie z interesami swojego klienta lub pracodawcy zgodnymi z dobrem społeczeństwa 3. Produkt Inżynierowie oprogramowania powinni zapewnić, że ich produkty i związane z nimi zmiany spełniają najwyższe standardy profesjonalizmu 4. Rozsądek Inżynierowie oprogramowania powinni zachowywać rozsądek i niezależność swoich sądów 5. Zarządzanie Zarządzający inżynierami oprogramowania i zwierzchnicy powinni przyjąć i promować etykę w zarządzaniu tworzeniem i pielęgnacją oprogramowania 6. Profesja Inżynierowie oprogramowania powinni podnosić wiarygodność i reputację profesji zgodnie z dobrem społeczeństwa 7. Koleżeństwo Inżynierowie oprogramowania powinni być uczciwi i chętni do pomocy swoim kolegom 8. Ja sam Inżynierowie oprogramowania powinni brać udział w długofalowej nauce praktyki swojego zawodu. Powinni także promować etyczne działania w praktyce swojej profesji

2))

Inżynieria systemów to czynność specyfikowania, projektowania, implementowania, weryfikowania, wdrażania i pielęgnacji systemów postrzegana jako całość. Inżynieria systemowa wymaga dużego wysiłku koordynacyjnego(wzajemne związki pomiędzy komponentami, wymóg zrozumienia innych dziedzin inżynierii)Właściwości systemów -Systemy charakteryzują się tym, że właściwości i zachowania ich komponentów są nierozerwalnie ze sobą splecione. -Poprawne działanie każdego z komponentów systemu zależy od funkcjonowania kilku innych komponentów-Złożone zależności między komponentami systemu oznaczają, że system jest czymś więcej niż tylko sumą swoich części. Te pojawiające się właściwości (Checkland, 1981) nie mogą być przypisane żadnej części systemu.///przykłady:Całkowity ciężar systemu- jest przykładem pojawiającej się właściwości, którą można wyznaczyć z właściwości poszczególnych komponentów ;;; Niezawodność systemu -zależy od niezawodności komponentów systemu i związków między nimi;;; Użyteczność systemu- jest bardzo złożoną właściwością, która nie zależy jedynie od oprogramowania i sprzętu, ale także od operatorów systemu i środowiska, w którym się go używa

Właściwości niefunkcjonalne-takie jak niezawodność, efektywność, bezpieczeństwo i zabezpieczenia. Są związane z zachowaniem systemu w jego środowisku pracy. Często są zasadnicze dla systemów komputerowych, ponieważ niepowodzenie w osiągnięciu pewnego zdefiniowanego minimalnego ich poziomu może sprawić, że system będzie bezużyteczny. Właściwości funkcjonalne- które są widoczne, gdy wszystkie części systemu współpracują, aby osiągnąć pewien cel. Rower ma na przykład cechę funkcjonalną bycia środkiem transportu, gdy scali się go z jego części Niezawodność systemu--Niezawodność jest złożonym pojęciem, które zawsze należy badać na poziomie systemu, a nie jego poszczególnych komponentów. --Komponenty w systemie są od siebie zależne, a zatem awarie w jednym z nich mogą przenosić się na cały system i mieć wpływ na operacje innych systemów --Często projektanci systemu nie są w stanie przewidzieć, jak konsekwencje awarii przenoszą się na cały system --Nie mogą zatem podać wiarygodnych oszacowań niezawodności systemu Czynniki wpływające na niezawodność całego systemu-Niezawodność sprzętu, Niezawodność oprogramowania, Niezawodność operatora Efektywność i użyteczność-Efektywność i użyteczność są trudne do oceny, można je jednak zmierzyć po uruchomieniu systemu Bezpieczeństwo i zabezpieczenia-Bezpieczeństwo i zabezpieczenia: mamy tutaj do czynienia nie z atrybutem ogólnego zachowania systemu, ale z zachowania systemu, które nie powinno mieć miejsca. Np. system zabezpieczony to taki, który nie dopuszcza nieuprawnionego dostępu do swoich danych. Modelowanie systemu--W trakcie czynności spisywania wymagań i projektowania musi powstać model systemu jako zbioru komponentów i związków między nimi --Architektura systemu jest zwykle prezentowana jako diagram blokowy, obrazujący najważniejsze podsystemy i połączenia między nimi --Każdy podsystem jest rysowany w postaci prostokąta na diagramie blokowym

( 1 )

Komponenty funkcjonalne systemu-Komponenty detektorowe-Zbierają informacje ze środowiska systemu. Przykładami takich komponentów są radary w systemie kontroli lotów Komponenty efektorowe (uruchamiające)-Powodują zmiany w środowisku systemu. Przykładami takich komponentów są zawory, które otwierają się i zamykają, aby zwiększyć lub zmniejszyć przepływ cieczy w rurze Komponenty obliczeniowe- Pobierają dane wejściowe, wykonują na nich pewne obliczenia i wytwarzają wyniki. Przykładem takiego komponentu jest procesor zmiennopozycyjny Komponenty komunikacyjne-Umożliwiają komunikację innym komponentom systemu. Przykładem takiego komponentu jest sieć łącząca różne komputery wewnątrz budynku. Komponenty koordynujące -Koordynują operacje innych komponentów. Np. w układach czasu rzeczywistego jest to komponent szeregujący zadania Komponenty interfejsu- Przetwarzają dane w reprezentacji używanej przez jedne komponenty na reprezentacje używane przez inne komponenty. Przykładem może być komponent interfejsu do komunikacji z człowiekiem, który pobiera pewien model systemu i wyświetla go operatorowi Rodzaje wymagań systemowych-abstrakcyjne wymagania funkcjonalne: podstawowe funkcje, które system ma wypełniać są definiowane na wysokim poziomie abstrakcji właściwości systemu: są to niefunkcjonalne, pojawiające się właściwości systemu

cechy, których system ma nie mieć: czasem wyspecyfikowanie tego, czego systemowi nie wolno robić, jest tak samo ważne, jak określenie tego, co system powinien robić. Proces projektowania systemu -Podziel wymagania-> Zidentyfikuj podsystemy-> Przypisz wymagania podsystemom-> Określ funkcjonalność podsystemów-> Zdefiniuj interfejsy podsystemów Tworzenie podsystemów--W czasie tworzenia podsystemów implementuje się podsystemy zidentyfikowane w trakcie projektowania--Proces tworzenia rzadko będzie polegał na budowie wszystkich podsystemów od zera. Na ogół część podsystemów będzie jednak komercyjnymi systemami z półki (Commercial, Off-The-Shelf, COTS) zakupionymi w celu integracji z naszym systemem.

--Różne systemy są zwykle tworzone równolegle Integracja systemu--Z powodów technicznych i menedżerskich najlepiej jest jednak integrować przyrostowo, tzn. w jednym kroku jest integrowany jeden system. --Zwykle nie da się ustalić harmonogramów budowania wszystkich podsystemów tak, aby kończyły się w tym samym czasie --Integracja przyrostowa zmniejsza koszty wykrywania błędów --Awarie podsystemów , które są konsekwencjami niewłaściwych założeń o innych podsystemach, są zwykle wykrywane w trakcie integracji systemu Ewolucja systemu--Czas życia wielkich złożonych systemów jest bardzo długi. W trakcie swego działania systemy te musza ewoluować--Ewolucja oprogramowania jest ze swej natury kosztowna: Likwidacja systemu-Likwidacja systemu oznacza wycofanie go po okresie jego pożytecznego użytkowania --Utylizacja substancji systemu --W wypadku samego oprogramowania, w odróżnieniu od całego systemu, nie ma mowy o żadnych fizycznych problemach z likwidacją --Zaopatrywanie w system--Klientami kupującymi złożone systemy komputerowe są zwykle duże przedsiębiorstwa, np. instytucje wojskowe, rządowe i służby ratownicze --System może być kupiony jako całość, a także jako zestaw oddzielnych części, które potem się integruje, specyficznie projektuje i wytwarza --W wypadku wielkich systemów podjęcie decyzji, którą z tych opcji wybrać, może trwać miesiące, a nawet lata Problemy zaopatrywania-Komponenty z półki zwykle nie spełniają wymagań idealnie, chyba że napisano te wymagania z myślą o tych właśnie komponentach --Gdy system będzie budowany na zamówienie, specyfikacja wymagań jest podstawą kontraktu na zamówienie w system --Po wybraniu wykonawcy systemu następuje okres negocjacji kontraktu, w trakcie którego uzgadnia się dalsze zmiany wymagań i omawia różne sprawy, np. koszt zmian

Proces inżynierii systemów-Proces inżynierii systemów obejmuje specyfikację, projektowanie, tworzenie, integrację i testowanie

3)) Proces tworzenia oprogramowania jest zbiorem czynności i związanych z nimi wyników, które prowadzą do powstania produktu programowego. Może to być tworzenie oprogramowania od zera, ale coraz częściej nowe oprogramowanie powstaje przez rozszerzanie i modyfikowanie istniejących systemów

Wszystkie procesy tworzenia oprogramowania obejmują specyfikowanie, projektowanie, implementację, zatwierdzanie i ewolucje oprogramowania.

*Model kaskadowy-W tym modelu podstawowe czynności specyfikowania, tworzenia, zatwierdzania i ewolucji są odrębnymi fazami procesu

( 2 )

*Tworzenie formalne systemów--Tworzenie formalne systemów jest podejściem, które ma wiele wspólnego z modelem kaskadowym. Proces tworzenia jest tu jednak oparty na matematycznych przekształceniach specyfikacji systemu w program wykonywalny --W procesie przekształcania formalna matematyczna reprezentacja systemu jest metodycznie przekształcana w bardziej szczegółowe, ale wciąż matematycznie poprawne reprezentacje systemu --Podejście z przekształceniem złożone z ciągu małych kroków jest łatwiejsze w użyciu. Wybór, które przekształcenie zastosować, wymaga jednak dużych umiejętności --Najlepiej znanym przykładem takiego formalnego procesu tworzenia jest Cleanroom, pierwotnie opracowany przez IBM (Proces Cleanroom jest oparty na przyrostowym tworzeniu oprogramowania, gdy formalnie wykonuje się każdy krok i dowodzi jego poprawności.)

( 3 )

*Tworzenie ewolucyjne-Tworzenie ewolucyjne polega na opracowaniu wstępnej implementacji, pokazaniu jej użytkownikowi z prośbą o komentarze i udoskonalaniu jej w wielu wersjach aż do powstania odpowiedniego systemu

Typu tworzenia:--tworzenie badawcze -prototypowanie z porzuceniem

( 4 )

*Tworzenie z użyciem wielokrotnym-W większości przedsięwzięć programistycznych występuje wielokrotne użycie oprogramowania -Etapy procesu(analiza komponentów,modyfikacja wymagań,projektowanie systemu z użyciem wielokrotnym, tworzenie i integracja)

-- Zakłada się istnienie wielkiego zbioru dostępnych komponentów programowych użycia wielokrotnego oraz integrującej je struktury

( 5)

PROCES INŻYNIERII WYMAGAŃ

( 6 )

Charakterystyczne czynności procesu projektowania-Projektowanie architektury, Specyfikowanie abstrakcyjne, Projektowanie interfejsów, Projektowanie komponentów, Projektowanie struktur danych, Projektowanie algorytmówProces projektowania i implementowania polega na przekształceniu specyfikacji wymagań w działający system oprogramowania. Metody systematycznego projektowania mogą być elementem tego przekształceniaZatwierdzenie oprogramowania to proces sprawdzania, czy system jest zgodny ze swoją specyfikacją oraz czy spełnia rzeczywiste potrzeby użytkowników

Ewolucja oprogramowania polega na modyfikowaniu istniejącego systemu oprogramowania, tak aby spełniał nowe wymagania. Takie podejście staje się standardem tworzenia oprogramowania w wypadku małych i średnich przedsięwzięćTechnologia CASE zapewnia zautomatyzowane wspomaganie procesu tworzenia oprogramowania. Narzędzia CASE wspomagają poszczególne czynności procesu. Warsztaty CASE wspomagają zbiory powiązanych czynności. Środowiska CASE wspomagają większość lub nawet wszystkie czynności procesu tworzenia oprogramowania. W modelach iteracyjnych procesów tworzenie oprogramowania przedstawia się w postaci cyklu czynności. Zaletą tego podejścia jest uniknięcie zbyt wczesnego zatwierdzenia specyfikacji lub projektu. Przykładami modeli iteracyjnych są tworzenie przyrostowe i model spiralny

4))

Dobre zarządzanie przedsięwzięciami programistycznymi jest niezbędne, jeśli przedsięwzięcia inżynierii oprogramowania mają być ukończone zgodnie z harmonogramem i w ramach budżetu

Zarządzanie programowaniem istotnie różni się od zarządzania w innych dziedzinach inżynierii. Oprogramowanie jest nieuchwytne. Przedsięwzięcia mogą być nowatorskie lub innowacyjne, nie ma więc odpowiedniego zasobu doświadczeń pomagających w zarządzaniu nimi.

Zarządzający oprogramowaniem mają do odegrania wiele różnych ról. Najbardziej znaczącymi są planowanie przedsięwzięcia, szacowanie i tworzenie harmonogramu. Planowanie i tworzenie harmonogramu są procesami iteracyjnymi; są wykonywane przez cały czas trwania przedsięwzięcia. W miarę napływu coraz dokładniejszych informacji, plany i harmonogramy muszą być korygowane.

Etap w przedsięwzięciu jest przewidywalnym rezultatem czynności, który oznacza przedstawienie kierownictwu pewnego formalnego raportu. Etapy powinny odbywać się regularnie przez całe przedsięwzięcie programistyczne. Produkt jest związany z odbiorem i przekazaniem go klientowi przedsięwzięcia.

Tworzenie harmonogramu przedsięwzięcia polega na opracowaniu rozmaitych graficznych przedstawień fragmentów planu przedsięwzięcia. Są nimi m.in. Wykresy czynności, na których obrazuje się zależności między czynnościami przedsięwzięcia, oraz wykresy paskowe ukazujące czas rwania czynności

Należy zidentyfikować i ocenić prawdopodobieństwo oraz konsekwencje głównych zagrożeń przedsięwzięcia. W wypadku zagrożeń prawdopodobnych i potencjalnie poważnych należy opracować plany unikania, opanowania lub przeciwdziałania tym zagrożeniom. Zagrożenia należy otwarcie omawiać na każdym menedżerskim spotkaniu w sprawie postępów przedsięwzięcia

Typy Planów:Plan jakości- Obejmuje procedury zapewnienia jakości i standardy obowiązujące w przedsięwzięciu. Plan zatwierdzania- Obejmuje podejście, zasoby i harmonogram zatwierdzania systemu. Plan zarządzania konfiguracjami- Obejmuje procedury zarządzania konfiguracjami i używane struktury.

Plan pielęgnacji- Przewiduje się w nim wymagania stawiane pielęgnacji, jej koszty i niezbędne nakłady. Plan rozwoju umiejętności personelu- Opisuje się w nim jak będą wzrastały umiejętności i doświadczenie personelu. ZAGROŻENIA I ICH TYPY: TECHNOLOGIA--baza danych w systemie może nie być w stanie przetworzyc tyle transakcji na sekunde, ile przewidziano. Komponenty programowe, których należy uzyc wielokrotnie, maja defekty ograniczające ich funkcjonalność LUDZIE- Nie można zatrudnic personelu o odpowiednich umiejętnościach, Najważniejsi pracownicy SA chorzy lub niedostępni w krytycznym okresie. Nie SA możliwe niezbędne szkolenia dla personelu ORGANIZACJE-Firma jest reorganizowana tak, ze inni członkowie zarządu SA teraz odpowiedzialni za przedsięwzięcie. Problemy finansowe firmy powoduja redukcje budżetu przedsewziecia NARZEDZIA-Kod generowany przez narzędzia CASE jest nieefektywny, nie da się zintegrowac narzedzi CASE WYMAGANIA-Zaproponowano zmiany wymagan, które prowadza do powaznej korekty projektu. Klienci nie SA w stanie zrozumiec wpływu zmian wymagan. SZACOWANIE-Nie oszacowano: czasu niezbędnego do tworzenia oprogramowania, częstości napraw usterek, rozmiaru oprogramowania

Typy planów: Zagrożenia w wytwarzaniu oprogramowania:

5)) TYPY WYMAGAŃ- Wymagania użytkownika-To wyrażenia w języku naturalnym oraz diagramy o usługach oczekiwanych od systemu oraz o ograniczeniach, w których system ma działać. są przeznaczone dla osób, które mają używać i zaopatrywać się w system. Należy spisać je za pomocą języka naturalnego, tabel i diagramów tak, aby były zrozumiałe Wymagania systemowe Szczegółowo ustalają usługi systemu i ograniczenia. Dokumentacja wymagań systemowych, zwana czasem specyfikacją funkcjonalną, powinna być precyzyjna. służą do poinformowania w precyzyjny sposób o funkcjach, które system ma spełniać. Aby uniknąć niejednoznaczności, można je zapisać za pomocą jakiegoś języka strukturalnego Wymagania funkcjonalne 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órych wypadkach wymagania funkcjonalne określają, czego system nie powinien robić Wymagania niefunkcjonalne To ograniczenia usług i funkcji systemu. Obejmują ograniczenia czasowe, ograniczenia dotyczące procesu tworzenia, standardy itd. Dzielimy na: a) Wymagania produktowe-Określają zachowanie produktu. Przykładami są wymagania efektywnościowe dotyczące szybkości działania systemu i jego zapotrzebowania na pamięć, wymagania niezawodności. b) Wymagania organizacyjne-Wynikają ze strategii i procedur w firmie klienta i w firmie wytwórcy c) Wymagania zewnętrzne-Ta szeroka kategoria mieści wszystkie wymagania wynikające z czynników zewnętrznych. Obejmują m.in. wymagania współpracy, które definiują interakcje systemu z systemami innych firm i wymagania prawne

Wymagania dziedzinowe Pochodzą z dziedziny zastosowania systemu odzwierciedlają jej charakterystykę. Mogą być funkcjonalne lub niefunkcjonalne.

//////// Dokumentacja wymagań stawianych oprogramowaniu jest uzgodnionym zapisem wymagań systemowych. Należy nadać jej odpowiednią strukturę,

aby mogła być używana zarówno przez klientów systemu, jak i twórców oprogramowania.

6)) Proces inżynierii wymagań:

( 7 )

Obejmuje wszystkie czynności niezbędne do opracowania i aktualizacji dokumentacji wymagań systemowych.Istnieją cztery ogólne czynności wysokiego poziomu w procesie inżynierii wymagań:-studium wykonalności -określenie i analizowanie wymagań -specyfikowanie i dokumentowanie wymagań -zatwierdzanie wymagań

Analizowanie wymagań to proces iteracyjny, który obejmuje rozpoznanie dziedziny, zbieranie wymagań, klasyfikację, strukturalizację, nadawanie priorytetów i zatwierdzanie Czynniki procesu określania i analizowania wymagań -Rozpoznanie dziedziny -Zbieranie wymagań -Klasyfikacja -Usuwanie sprzeczności -Nadawanie priorytetów -Sprawdzanie wymagań Cechy scenariusza -Opis stanu systemu na początku scenariusza. -Opis normalnego następstwa zdarzeń scenariusza. -Opis tego, co może pójść źle, i jak to jest obsługiwane. -Informacje o innych czynnościach, które można wykonywać w tym samym czasie. -Opis stanu systemu po zakończeniu scenariusza Etnografia

( 8 )

-To metoda obserwacji, która może służyć do rozpoznawania wymagań społecznych i organizacyjnych. -Analityk pogrąża się w środowisku pracy, w którym system będzie używany. -Obserwuje codzienną pracę i odnotowuje podstawowe zadania wykonywane przez pracowników. -Zaleta etnografii jest to, że pomaga odkrywać niejawne wymagania systemowe odzwierciedlające rzeczywiste, a nie formalne procesy, w których biorą udział ludzie

Cele Etnografii-Opis wymagań wynikających z rzeczywistego sposobu pracy osób, a nie ze sposobu zalecanego formalne definicje procesów.

-Opis wymagań, które wynikają z kooperacji i świadomości czynności innych osób Wymagania stałe Względnie stabilne wymagania, które wynikają z podstawowej działalności firmy i bezpośrednio odnoszą się do dziedziny systemu. W szpitalu zawsze będą wymagania dotyczące pacjentów, lekarzy, pielęgniarek, terapii, itp. Wymagania zmienne Wymagania, które prawdopodobnie ulegną zmianie w trakcie tworzenia systemu albo po przekazaniu go do użytkowania. Takimi wymaganiami są na przykład wymagania, które wynikają z polityki zdrowotnej rządu Klasyfikacja wymagań zmiennych -Wymagania zmienne

-Wymagania pojawiające się -Wymagania wynikowe -Wymagania zgodności

Zagrożenie	Typ zagrożenia	Opis
Rotacja personelu	Przedsięwzięcie	Doświadczony personel opuści przedsięwzięcie przed jego ukończeniem.
Zmiana zarządzania	Przedsięwzięcie	Nastąpi zmiana w organizacji zarządzania i priorytetów.
Niedostępność sprzętu	Przedsięwzięcie	Podstawowy sprzęt dla przedsięwzięcia nie będzie dostarczony na czas.
Zmiana wymagań	Przedsięwzięcie i produkt	Liczba zmian wymagań będzie większa, niż przewidywano.
Opóźnienia specyfikacji	Przedsięwzięcie i produkt	Specyfikacja podstawowych interfejsów nie będzie dostępna na czas.
Niedoszacowanie rozmiaru	Przedsięwzięcie i produkt	Zbyt nisko oszacowano rozmiar systemu.
Mniejsza efektywność CASE	Produkt	Narzędzia CASE użyte do wspomagania przedsięwzięcia nie działają tak, jak oczekiwano.
Zmiany technologii	Przedsiębiorstwo	Technologia, w której buduje się system, będzie zmieniona na nową.
Konkurencja dla produktu	Przedsiębiorstwo	Przed ukończeniem naszego produktu na rynku pojawi się konkurencyjny produkt.

---