Przypadki u\ycia
Na podstawie
G.Schneider, J.P.Winters Stosowanie
przypadków u\ycia
A.Cockburn Jak pisać efektywne
przypadki u\ycia
D.Leffingwell, D.Widrig Zarządzanie
wymaganiami
G. Booch, J.Rumbaugh, I.Jacobson
UML przewodnik uzytkownika
Leszek Siwik
Co to jest?
Przypadek u\ycia to opis zbioru
ciągów akcji (i ich wariantów)
wykonywanych przez system w celu
dostarczenia określonemu aktorowi
godnego uwagi wyniku
Interakcje
Przypadek u\ycia obejmuje
interakcje aktorów (człowieka lub
innych automatów) i systemu
pokazuje jakie zadania będzie
system realizował dla aktora nie
mówiąc w jaki sposób te zadania
będą realizowane ( co? a nie
jak? )
Warianty
Kredyt hipoteczny o wielkiej
wartości a niewielki kredyt handlowy
ró\nice oczywiste
Podobieństwa przeprowadzenie oceny
zdolności kredytowej klienta
A zatem mamy do czynienia z
wariantami przypadku u\ycia udziel
kredytu
Zastosowanie
Analiza systemów (podsystemów, klas, interfejsów)
Podstawa do opracowania przypadków testowych
yródło testów regresywnych (dla podsystemów) oraz
testów integracyjnych i systemowych dla systemu
Pomagają w skrośnym łączeniu informacji z profilu
u\ytkownika, reguł gospodarczych i wymagań wobec
formatu danych
Pomagają w opracowaniu dokumentacji wymagań a tak\e
planu przedsięwzięcia (daty wersji, priorytety, stan
wytwarzania etc.)
Pomagają w projektowaniu interfejsu u\ytkownika
Notacja
Aktorzy - definicja
Aktor reprezentuje spójny zbiór ról
odgrywanych przez u\ytkowników
przypadku u\ycia w czasie interakcji z
tym przypadkiem u\ycia
Aktor coś co ma zachowanie (jest
zdolne do wykonania instrukcji jeśli).
Mo\e być systemem mechanicznym,
systemem komputerowym, osobą, firmą
albo jakimś ich połączeniem
Aktorzy - uwagi
Aktorem mo\e być człowiek, urządzenie
lub inny system słowem wszystko to co
wchodzi w interakcje z systemem aby
zrealizować jakieś zadanie
Aktorzy występują w modelu ale nie są
częścią systemu. Istnieją POZA systemem
Aktorzy - uwagi
Związki pomiędzy aktorami mogą być
związkami typu generalizacja
Związki pomiędzy aktorami a
przypadkami u\ycia mogą być wyłącznie
typu powiązanie co oznacza \e aktor i
przypadek u\ycia porozumiewają się
wysyłając i odbierając komunikaty
Przypadki u\ycia a ciągi
zdarzeń
Przypadek u\ycia mo\e być
wyspecyfikowany przez opisanie ciągu
zdarzeń
Zapisując ten ciąg zdarzeń nale\y
uwzględnić informacje o tym jak i kiedy
przypadek u\ycia zaczyna się i kończy,
kiedy dochodzi do jego interakcji z
aktorami. Nale\y tak\e wyspecyfikować
ciąg główny oraz nadzwyczajne
(alternatywne)
Oprogramowanie bankomatu
przypadek WeryfikujU\ytkownika
Główny ciąg zdarzeń: Przypadek u\ycia zaczyna
się gdy system pyta Klienta o PIN. Klient mo\e
teraz wprowadzić hasło z klawiatury. Klient
potwierdza wprowadzone dane za pomocą
klawisza Wykonaj. System sprawdza poprawność
PINu. Jeśli PIN jest poprawny system informuje
o tym. Na tym kończy się przypadek u\ycia
Nadzwyczajny ciąg zdarzeń. Klient mo\e w
ka\dej chwili anulować transakcję naciskając
klawisz Stop. Przypadek u\ycia wraca teraz do
punktu początkowego
Oprogramowanie bankomatu
przypadek WeryfikujU\ytkownika
Nadzwyczajny ciąg zdarzeń: Przed
potwierdzeniem PINu Klient mo\e w
ka\dej chwili wprowadzić go jeszcze raz.
Nadzwyczajny ciąg zdarzeń: Gdy klient
wprowadzi błędny PIN przypadek u\ycia
wraca do punktu początkowego. Gdy
zdarzy się to trzy razy z rzędu system
anuluje całą transakcję i przez 60 sekund
nie reaguje na \adne działania Klienta
Przypadki u\ycia a
scenariusze
Przypadek u\ycia zatrudnij i jego
mo\liwe warianty
Zatrudnienie osoby z zewnątrz
Zatrudnienie osoby z innego działu
Zatrudnienie obcokrajowca
Ka\dy taki wariant mo\e być
wyra\ony za pomocą innego ciągu
zdarzeń innego scenariusza
Organizacja przypadków
u\ycia
Pakiety
Generalizacja
Związek Zawierania
Związek rozszerzania
Uogólnianie
Generalizacja między przypadkami u\ycia oznacza,
\e:
Szczególny przypadek u\ycia dziedziczy całe
zachowanie i znaczenie po ogólnym przypadku
u\ycia
Szczególny przypadek u\ycia mo\e dodać do
odziedziczonego zachowania nowe elementy a
mo\e tez to zachowanie zupełnie zmienić
Przypadek szczególny mo\e zawsze zastąpić
swego przodka
Związek zawierania
Związek zawierania pomiędzy
przypadkami u\ycia polega na tym,
\e bazowy przypadek u\ycia jawnie
włącza zachowanie innego
przypadku u\ycia w miejscu przez
siebie określonym.
Związku tego u\ywa się w celu
uniknięcia wielokrotnego opisywania
tego samego ciągu zdarzeń
Związek zawierania
Śledz realizację zamówienia:
Główny ciąg zdarzeń: Pobierz i zweryfikuj
numer zamówienia
Include (Weryfikuj u\ytkownika)
Ustal stan ka\dej pozycji i złó\ raport
u\ytkownikowi
Związek rozszerzania
Związek rozszerzania między
przypadkami u\ycia polega na tym \e
bazowy przypadek u\ycia w sposób
domniemany włącza zachowanie innego
przypadku u\ycia w miejscu określonym
pośrednio przez rozszerzający przypadek
u\ycia (bazowy przypadek u\ycia mo\e
wystąpić samodzielnie ale pod pewnymi
warunkami jego zachowanie mo\e być
rozszerzone przez zachowanie innego
przypadku u\ycia)
Związek rozszerzania
Związek ten wykorzystywany jest do:
Modelowania fragmentów przypadku u\ycia
postrzeganych przez u\ytkownika jako
opcjonalne zachowanie systemu
Wyodrębniania podciągu zdarzeń które
zachodzą tylko pod pewnymi warunkami
Modelowania kilku ciągów zdarzeń które mogą
być dołączone w konkretnym miejscu zale\nie
od jawnej interakcji z aktorem
Związek rozszerzania
Przypadek u\ycia Złó\ zamówienie
Główny ciąg zdarzeń: include(weryfikuj u\ytkownika)
Pobierz od u\ytkownika listę pozycji jego zamówienia
(określ priorytet). Przeka\ zamówienie do realizacji
Diagram przypadków u\ycia
Diagram ten przedstawia zbiór
przypadków u\ycia i aktorów oraz związki
pomiędzy nimi
Zawartość
Przypadki u\ycia
Aktorzy
Zale\ności, uogólnienia, powiązania
Notatki, ograniczenia
Pakiety
Zastosowanie
Modelowanie otoczenia systemu(wyznaczanie
granicy wokół całego systemu oraz wskazanie
le\ących poza nim aktorów którzy wchodzą w
interakcję z systemem. Zdefiniowanie aktorów i
znaczenia ich ról)
Modelowanie wymagań stawianych systemowi
(określenie co system powinien robić z punktu
widzenia jego otoczenia niezale\nie od tego jak
ma to robić. Zdefiniowanie oczekiwanego
działania systemu rozumianego jako czarna
skrzynka )
Modelowanie otoczenia
Otoczenie systemu to wszystkie byty
istniejące poza systemem a będące z nim
w interakcji uwzględniamy tylko tych
aktorów którzy są niezbędni do
właściwego działania systemu
Postępowanie:
Identyfikacja aktorów działających wokół
systemu
Uporządkowanie aktorów za pomocą
generalizacji
W razie potrzeby dodanie stereotypów
Modelowanie otoczenia
przykład
Modelowanie wymagań
Wymaganie to element projektu. To
właściwość lub zachowanie systemu.
To swoisty kontrakt między bytami z
otoczenia a samym systemem
określający co system ma robić (bez
zwracania uwagi jak system ma to
robić)
Zasady modelowania
Określ otoczenie systemu
Dla ka\dego aktora rozwa\ działania których on oczekuje
lub wymaga od systemu zapisz je w postaci przypadków
u\ycia
Wyłącz powtarzające się fragmenty działań i utwórz z nich
nowe przypadki które będą włączane przez inne
przypadki
Wydziel warianty działań i umieść je w nowych
przypadkach u\ycia które będą rozszerzać ciągi zdarzeń
innych przypadków u\ycia
Uwzględnij na diagramie związki pomiędzy aktorami a
przypadkami u\ycia
Dodaj notatki uwzględniające wymagania niefunkcjonalne
Niebezpieczeństwa
generalizacji
Zale\ności czasowe
System obsługi zamówień co kwartał
automatycznie wysyła katalogi do
klientów
Czas jako aktor
Czas jako część systemu
CRUD i parametryzowane
przypadki u\ycia
Poszukiwanie rzeczy musi mieć tę samą logikę:
U\ytkownik określa rzecz do znalezienia
System poszukuje jej i przedstawia listę mo\liwych trafień
U\ytkownik wybiera, być mo\e ponownie sortuje listę i
zmienia kryteria
System znajduje tę rzecz (albo nie znajduje)
To co odró\nia poszczególne przypadki to:
Nazwa rzeczy do znalezienia
Poszukiwane właściwości (pola wyszukiwania) rzeczy do
znalezienia
Jakie aspekty rzeczy do znalezienia wyświetlić
Jak posortować wybory
CRUD i parametryzowane
przypadki u\ycia - uwagi
PPU są dobrym rozwiązaniem jeśli nie ma problemów z
uprawnieniami do wykonywania operacji CRUD (w
przeciwnym przypadku nale\y zdefiniować odrębne
przypadki u\ycia)
Operacje CRUD na poziomie uzgadniania wymagań
modelujemy WYACZNIE jeśli wynika to z logiki
biznesowej systemu. Np. modelowany system to aplikacja
dla administratorów baz danych wspomagająca
zarządzanie danymi
W przeciwnym przypadku zamodelujemy raczej przypadek
u\ycia Zarejestruj u\ytkownika ni\ Dodaj u\ytkownika,
raczej Złó\/Przyjmij zamówienie ni\ Dodaj zamówienie
CRUD i parametryzowane
przypadki u\ycia
Rozwiązanie: parametryzowane przypadki
u\ycia np. Urzędnik znajduje klienta to
wywołanie przypadku Znajdz coś z
parametrem klient
Przypadek u\ycia Znajdz coś
U\ytkownik wskazuje wyszukiwane
właściwości czegoś
System znajduje wszystkie pasujące trafienia i
pokazuje ich wyświetlane wartości na liście
U\ytkownik mo\e je ponownie posortować
zgodnie z kryteriami sortowania
U\ytkownik wybiera trafienie którego szukał
Rysunki to nie wszystko
Aktor główny: Nabywca
Zakres: pakiet Osobisty doradca finansowy
Poziom Cel u\ytkownika
Uczestnicy i interesy:
Nabywca chce kupić akcje i mieć je automatycznie w
elektronicznym portfelu
Biuro maklerskie chce otrzymać pełną informacje o zakupie
Warunek początkowy: U\ytkownik uruchomił ju\ ODF
Minimalna gwarancja: W dziennikach będzie istnieć informacja
wystarczająca aby ODF mógł wykryć, \e cos jest nie w porządku i
poprosić u\ytkownika o szczegóły
Gwarancja powodzenia: Zdalny serwis WWW potwierdził
zakup; zaktualizowano dzienniki i portfel u\ytkownika
Główny scenariusz powodzenia:
1. Nabywca postanawia kupić akcje przez WWW
2. ODF pobiera od u\ytkownika informacje o serwisie WWW z
którego ma skorzystać
3. ODF uruchamia połączenie WWW z tym serwisem i zachowuje
sterowanie
4. Nabywca przegląda i kupuje akcje z serwisu WWW
5. ODF przechwytuje reakcje serwisu WWW i aktualizuje portfel
nabywcy
6. ODF wyświetla u\ytkownikowi nowy stan portfela
2a. Nabywca chce skorzystać z serwisu WWW którego ODF
nie obsługuje
2a1System pyta u\ytkownika o nową sugestię z
mo\liwością przerwania przypadku u\ycia
3a Dowolna awaria WWW w czasie uruchamiania
3a1 System informuje nabywcę o awarii i wyświetla
podpowiedz, po czym cofa się do poprzedniego kroku
3a2 Nabywca rezygnuje - kończy przypadek u\ycia albo
próbuje ponownie
4a Komputer ulega awarii lub jest wyłączany w trakcie
transakcji
4a1 ???
4b Serwis WWW nie potwierdza zakupu, ale odkłada go na
pózniej
4b1 ODF zapisuje opóznienie do dziennika, ustawia zegar aby
zapytać nabywcę o wynik
5a Serwis WWW nie przekazuje potrzebnych informacji o
zakupie
5a1 ODF umieszcza w dzienniku zapis o braku informacji,
klient musi zaktualizować wątpliwy zakup
Aktor główny: Zgłaszający szkodę
Zakres: Firma ubezpieczeniowa
Poziom: streszczenie
Uczestnicy i interesy:
Zgłaszający szkodę otrzymać jak najwy\sze odszkodowanie
FU wypłacić jak najni\sze odszkodowanie
Urząd nadzoru dopilnować aby wszystkie przepisy były
przestrzegane
Warunek początkowy brak
Minimalna gwarancja: FU rejestruje zgłoszenie szkody i
wszystkie czynności
Gwarancja powodzenia: Zgłaszający szkodę i FU
uzgadniają kwotę do wypłaty. Zgłaszający przedstawia
szkodę
Główny scenariusz powodzenia
1. Zgłaszający szkodę przedstawia roszczenie i podaje
wszystkie istotne dane
2. FU stwierdza \e zgłaszający ma wa\ną polisę
3. FU wyznacza likwidatora, który zajmie się szkodą
4. FU stwierdza, \e wszystko jest zgodne z
postanowieniami polisy
5. FU wypłaca odszkodowanie i zamyka sprawę
1a. Przekazane dane są niepełne:
1a1 FU prosi o brakujące informacje
1a2 Zgłaszający dostarcza brakujących informacji
2a Zgłaszający szkodę nie ma wa\nej polisy:
2a1 FU odrzuca zgłoszenie, informuje o tym zgłaszającego,
wszystko to rejestruje i kończy przypadek u\ycia
3a W tej chwili nie ma wolnych likwidatorów
3a1 ???
4a Okoliczności wypadku naruszają podstawowe
postanowienia polisy:
4a1 FU odrzuca zgłoszenie, informuje o tym zgłaszającego,
wszystko to rejestruje i kończy przypadek u\ycia
4b Okoliczności wypadku naruszają pewne mniej istotne
postanowienia polisy:
4b1 FU rozpoczyna negocjacje ze zgłaszającym szkodę w
sprawie ustalenia kwoty wypłaty
Oznaczenia i definicje
Zakres wskazuje system który analizujemy
Warunki początkowe i gwarancje: co musi być prawdą
przed i po wykonaniu przypadku u\ycia
Główny scenariusz powodzenia ciąg zdarzeń w sytuacji
gdy wszystko idzie dobrze
Rozszerzenia co mo\e pójść inaczej w trakcie tego
scenariusza
Liczby w rozszerzeniach odnoszą się do numerów kroków
w głównym scenariuszu powodzenia w których wykrywane
są odmienne warunki
Gdy przypadek u\ycia obejmuje (włącza) inny przypadek
przywoływany przypadek u\ycia jest podkreślany
Kup coś wersja
nieformalna
Zamawiający przygotowuje zlecenie i wysyła je do swojego
Akceptującego. Akceptujący sprawdza czy w bud\ecie są jeszcze
środki, sprawdza cenę towarów, wypełnia \ądanie dostawy i
wysyła je do Kupującego. Kupujący sprawdza stan magazynu i
znajduje najlepszego dostawcę towarów. Kontroler weryfikuje
podpis Akceptującego. Kupujący wypełnia \ądanie zamówienia i
rozpoczyna PO z Dostawcą. Dostawca dostarcza towary do
Odbioru, odbiera pokwitowanie dostawy (poza zakresem
projektowanego systemu). Odbiorca rejestruje dostawę i wysyła
towary do Zamawiającego. Zamawiający oznacza zlecenie jako
zrealizowane.
Przed odbiorem towarów Zamawiający w ka\dej chwili mo\e
zmienić lub anulować zlecenie. Anulowanie zlecenia powoduje
zaprzestanie jakiegokolwiek aktywnego przetwarzania (usunięcie
z systemu??). Zmniejszenie ceny nie wpływa na przetwarzanie.
Wzrost ceny powoduje wysłanie zlecenia z powrotem do
Akceptującego
Kup coś wersja formalna
Aktor główny zamawiający
Zakres Przedsiębiorstwo całościowy system zakupów,
elektroniczny i nieelektroniczny postrzegany przez pracowników
Poziom: streszczenie
Uczestnicy i interesy:
Zamawiający: Chce tego co zamówił, łatwego otrzymania tego co
zamówił
Firma: Chce kontrolować wydatki, ale chce umo\liwić potrzebne
zakupy
Dostawca: Chce otrzymać zapłatę za dostarczone towary
Warunek początkowy: Brak
Minimalna gwarancja: Ka\de wysłane na zewnątrz zamówienie
jest zaakceptowane przez uprawnionego Akceptującego.
Zamówienie jest tak kontrolowane aby firma mogła być
obcią\ona jedynie za towary dostarczone zgodnie z zamówieniem
Gwarancja powodzenia: Zamawiający ma towary i prawidłowy
bud\et, który mo\na obcią\yć
Wyzwalacz: zamawiający postanawia coś kupić
Główny scenariusz powodzenia
1. Zamawiający przygotowuje zlecenie
2. Akceptujący sprawdza środki w bud\ecie, sprawdza cenę towarów,
wypełnia \ądanie dostawy
3. Kupujący sprawdza stan magazynu i znajduje najlepszego
dostawcę towarów
4. Kontroler weryfikuje podpis Akceptującego
Kupujący wypełnia \ądanie zamówienia, rozpoczyna PO z dostawcą
Dostawca dostarcza towar do odbiorcy, odbiera pokwitowanie
dostawy (poza zakresem projektowanego systemu)
Odbiorca rejestruje dostawę, wysyła towary do zamawiającego
Zamawiający oznacza zlecenie jako zrealizowane
1a Zamawiający nie zna dostawcy lub ceny: pozostaw te części
puste i kontynuuj
1b Przed odbiorem towarów zamawiający w ka\dej chwili mo\e
zmienić lub anulować zlecenie
Anulowanie zlecenia powoduje zaprzestanie jakiegokolwiek
aktywnego przetwarzania
Zmniejszenie ceny nie ma wpływu na przetwarzanie
Zwiększenie ceny powoduje wysłanie zlecenia z powrotem do
Akceptującego
2a Akceptujący nie zna dostawcy lub ceny: pozostaw te części
puste i kontynuuj
2b Akceptujący nie jest szefem zamawiającego: w porządku, pod
warunkiem \e podpisze to kontroler
2c Akceptujący odmawia: wyślij zlecenie z powrotem do
Zamawiającego, by je zmienił lub cofnął
3a Kupujący znajduje towary w magazynie: wyślij je,
zmniejsz zlecenie o ich liczbę i kontynuuj
4a Kontroler odmawia Akceptującemu: wyślij z powrotem
do zamawiającego i wycofaj to z aktywnego przetwarzania
5a Zlecenie obejmuje kilku Dostawców: Kupujący generuje
kilka PO
5b Kupujący łączy kilka zleceń: zastosuj taki sam proces,
ale oznacz PO numerami połączonych zleceń
6a Dostawca nie dostarcza na czas: System alarmuje o
niedostarczeniu
7a Częściowa dostawa: Odbiorca zaznacza na PO
częściową dostawę i kontynuuje
7b Częściowa dostawa z wielu PO: Odbiorca
przyporządkowuje wielkości do zleceń i kontynuuje
8a Nie te towary lub nie tej jakości: Zamawiający odrzuca
dostarczone towary
8b Zamawiający zwolnił się z firmy: Kupujący kontaktuje
się z szefem Zamawiającego: zmień Zamawiającego,
zwróć towary lub anuluj zlecenie
Lista wariantów technologii i danych: Brak
Priorytet: Zmienny
Wersje: Kilka
Czas reakcji: Zmienny
Częstotliwość u\ycia: 3 razy dziennie
Kanał aktora głównego: przeglądarka WWW, system
pocztowy lub inny równowa\ny
Aktorzy drugoplanowi: Dostawca
Otwarte zagadnienia:
Kiedy usunąć z systemu anulowane zamówienie
Jakie uprawnienia są potrzebne do anulowania zlecenia
Kto mo\e zmienić treść zlecenia
Jaka historia zmian musi być przechowywana i
dostępna na \ądanie
Co się dzieje gdy Zamawiający odrzuca dostarczone
towary
W jaki sposób przy zamawianiu spytać o stan i
skorzystać z wewnętrznego magazynu
Szkic wymagań
Rozdział 1: Przeznaczenie i zakres
1a Jaki jest ogólny zakres i przeznaczenie
1b Uczestnicy (dla kogo to jest wa\ne)
1c Co le\y w zakresie a co poza nim?
Rozdział 2: U\yte terminy/Słownik
Rozdział 3: Przypadki u\ycia
3a Aktorzy główni i ich ogólne cele
3b Biznesowe przypadki u\ycia
3c Systemowe przypadki u\ycia
Rozdział 4: U\yta technologia
4a Jakie są wymagania technologiczne w stosunku do samego
systemu?
4b Z jakimi systemami ten system będzie miał interfejsy?
Jakie są wobec nich wymagania?
Rozdział 5: Inne wymagania
5a Proces wytwórczy:
" P1 Kto bierze udział w przedsięwzięciu
" P2 Jakie wartości będą odzwierciedlone (prosty,
wkrótce, szybki, elastyczny)
" P3 Jakich informacji zwrotnych i przejrzystości
przedsięwzięcia chcą u\ytkownicy i sponsorzy
" P4 Co mo\emy kupić, co musi być zbudowane, co
jest naszą konkurencją?
" P5 Jakie są inne wymagania procesowe (testowanie
instalacja etc.)
" Od jakich wpływów zale\y przedsięwzięcie?
5b Reguły gospodarcze
5c Efektywność
5d Operacje, zabezpieczenia i dokumentacje
5e U\ycie i u\yteczność
5f Pielęgnacja i przenośność
Szkic wymagań - cd
Rozdział 6 Zastąpienie przez ludzi,
zagadnienia prawne, polityczne i
organizacyjne
6a Jak zastąpić system pracą ludzi w
przypadku jego awarii
6b Jakie są wymagania prawne i polityczne
Jakie konsekwencje dla ludzi niesie
ukończenie systemu?
Jakie są wymagania dotyczące szkoleń
Potrzebne dane i ich formaty
Wymagania efektywnościowe
Wymagania dotyczące GUI
Przypadki u\ycia
...........
...........
Protokoły I/O
Projekt GUI
Reguły biznesowe
Tabela w-poza
Temat W Poza
Fakturowanie w dowolnej postaci Poza
Generowanie raportów o zleceniach W
Aączenie zleceń w jedno PO W
Częściowe dostawy, spóznione dostawy, błędne W
dostawy
Dowolne części systemu nie będące Poza
oprogramowaniem
Poszukiwanie istniejącego oprogramowania w
które mo\na by u\yć
Definiowanie zakresu funkcjonalnego i projektowego
dla przedsięwzięcia typu śledzenie zleceń zakupów
Lista aktor-cel
Aktor Cel Priorytet
Ka\dy Sprawdz zlecenia 1
Kontroler Zmień zatwierdzenia 2
Kupujący Sprawdz kontakty z dostawcami 3
Zamawiający Przygotuj zlecenie 1
Akceptujący Przygotuj \ądanie dostawy 2
Kupujący Przygotuj \ądanie zamówienia 1
Opcjonalne kolumny: wyzwalacz,
priorytet gospodarczy, zło\oność wytwarzania
priorytet wytwarzania etc.
Wyszukiwarka
Podobne podstrony:
Elementy wymagan organizacyjneKomunikacja w świetle wymagań normy ISO 9001(1)MicrosoftWord WymaganiatechniczneorazzasadykształtowaniaprofilupodłużnegoipoprzecznegobudowlipodziemRola laboratoriów w świetle wymagań systemów zarządzania jakoscią,Modelowanie i symulacja systemów, Model dynamicznyWymagania agregat prądotwórczyMicheasza 6 w 8 WYMAGANIA JEHOWYBaum Wajszczuk Wawrzynowicz Modelowe rozwiazanie logistyczneMetody modelowania procesow 12 cz I (1)Wymagania zasadnicze i procedura oceny zgodności sprzętu elektrycznegoWYMAGANIA BHP DOTYCZACE OBIEKTOW BUDOWLANYCH I TERENU ZAKLADU czesc II drogijadospisy bez specjalnych wymagan zywieniowychZPT 03 Specyfikacja wymagan odblokowanyPOLITYKA SPOECZNA WYMAGANIAwięcej podobnych podstron