20-26(1).doc

20. Omów główne klasy wymagań na system informatyczny. Podaj przykłady
       takich wymagań.

Główne klasy wymagań to Funkcjonalne, Niefunkcjonalne i Dziedzinowe

   Funkcjonalne (jakie usługi oferuje, jak ma reagować, jakie dane przyjmować) :
-system wymaga logowania użytkownika
-możliwość sprawdzania postępów pracy w każdym momencie

    Niefunkcjonalne( ograniczenia czasowe, standardy) :
-system powinien odszukiwać dane każdego użytkownika poniżej 10 sekund
-system nie powinien zajmować więcej niż 10GB

    Dziedzinowe (odzwierciedlają charakterystykę dziedziny systemu, mogą być
    funkcjonalne lub niefunkcjonalne):
-Wszystkie bazy danych powinny być dostępne przez jednolity interfejs użytkownika,
  którego podstawą jest standard Z39.50

21. Omów i podaj przykłady wymagań funkcjonalnych dla systemu
       informatycznego.
Wymagania funkcjonalne określają jakie usługi ma oferować system, jak ma reagować na otrzymywane dane wejściowe oraz w określonych sytuacjach. Określają one użytkowników korzystających z systemu oraz możliwości każdego z nich. Określają również wykorzystanie systemów zewnętrznych. Mogą one również określać czego system nie powinien robić. Wymagania funkcjonalne mogą być realizowane przez systemy zewnętrzne.
Przykłady:
-wprowadzenie nie pełnych danych system powinien komunikować błędem
-system powinien przydzielać odpowiednie zlecenia pracownikom

22. Omów i podaj przykłady wymagań niefunkcjonalnych dla systemu
        informatycznego.
Wymagania niefunkcjonalne są to ograniczenia systemu, które obejmują ograniczenia czasowe, ograniczenia dotyczące procesu tworzenia, standardy itd.
Wynikają one z potrzeb użytkownika, budżetu, potrzeby współpracy z innym systemem, strategii firmy i czynników zewnętrznych. Wymagania niefunkcjonalne można podzielić na trzy podklasy:
    Produktowe (określają zachowanie produktu) :
-system powinien być łatwy w użyciu dla doświadczonych kontrolerów

    Organizacyjne (wynikają ze strategii w firmie wytwórczej i firmie klienta)
-proces tworzenia systemu i końcowe dokumenty powinny być zgodne z procesem i
produktami zdefiniowanymi w standardzie XYZCo-SP-STAN-95.
    Zewnętrzne
-system nie powinien ujawniać operatorom żadnych danych osobowych klientów
  oprócz nazwisk i numerów identyfikacyjnych.

23. Omów metody specyfikacji wymagań dla systemów informatycznych.
W zależności od potrzeb stosuje się różne metody specyfikacji wymagań:
-Język naturalny - najczęściej stosowany. Wady: niejednoznaczność powodująca różne rozumienie tego samego tekstu; elastyczność, powodująca wyrazić te same treści na wiele sposobów. Utrudnia to wykrycie powiązanych wymagań i powoduje trudności w wykryciu sprzeczności.
-Formalizm matematyczny. Stosuje się rzadko (dla specyficznych celów).
-Język naturalny strukturalny. Język naturalny z ograniczonym słownictwem i składnią. Tematy i zagadnienia wyspecyfikowane w punktach i podpunktach.
-Tablice, formularze. Wyspecyfikowanie wymagań w postaci  tablic, kojarzących różne aspekty.
-Diagramy blokowe: forma graficzna pokazująca cykl przetwarzania.
-Diagramy kontekstowe: ukazują system w postaci jednego bloku oraz jego powiązania z otoczeniem, wejściem i wyjściem.
-Diagramy przypadków użycia: poglądowy sposób przedstawienia aktorów i funkcji systemu.

24. Omów przykładowy zakres treści dokumentu opisującego wymagania na system
       informatyczny.
Dokument opisujący wymagania na system informatyczny ma pewien schemat:
Informacje organizacyjne:
Streszczenie (około 200 słów),  Spis treści, Statut dokumentu(autorzy, firmy, podpisy),
Zmiany w stosunku do poprzedniej wersji.
Zasadnicza zawartość dokumentu:
1. Wstęp
(1.1 Cel 1.2 Zakres 1.3 Definicje akronimy i skróty 1.4 Referencje, odsyłacze do innych
  dokumentów 1.5 Krótki przegląd )
2. Ogólny opis
(2.1 Walory użytkowe i przydatność projektowanego systemu 2.2 Ogólne możliwości
  projektowanego systemu 2.3 Ogólne ograniczenia 2.4 Charakterystyka 
  użytkowników 2.5 Środowisko operacyjne 2.6 Założenia i zależności )

3. Specyficzne wymagania
( 3.1 Wymagania funkcjonalne 3.2 Wymagania niefunkcjonalne )
Dodatki

Kolejność i numeracja punktów w przedstawionym spisie treści powinna być zachowana. W przypadku gdy pewien punkt nie zawiera żadnej informacji należy wyraźnie to zasygnalizować przez umieszczenie napisu „Nie dotyczy”.
Dla każdego wymagania powinien być podany powód jego wprowadzenia: cele przedsięwzięcia, których osiągnięcie jest uwarunkowane danym wymaganiem.

25. Omów zakres fazy analizy w cyklu wytwórczym systemów informatycznych.
Celem fazy analizy jest ustalenie wszystkich tych czynników, które mogą wpłynąć na decyzje projektowe, na przebieg procesu projektowego i na realizację wymagań. Wynikiem jest logiczny model systemu, opisujący sposób realizacji przez system postawionych wymagań, lecz abstrahujących od szczegółów implementacyjnych.
Zakres fazy analizy:
--Wykracza poza zakres odpowiedzialności systemu -> kontekst użycia i współpracy;
--Ujęcie w modelu pewnych elementów nie będących częścią systemu -> model jest
    bardziej zrozumiały;
--Abstrakcja modelowania -> podczas modelowania może nie być jasne,
    które elementy modelu będą realizowane przez oprogramowanie a które w sposób
    sprzętowy lub ręcznie;
--Dostępne środki mogą nie pozwolić na realizację systemu w całości -> analiza może
   wykryć fragmenty, które mogą być szczególnie ważne;
26. Omów główne cechy modelu analitycznego i podstawowe czynności w fazie
       analizy systemu informatycznego.
Cechy modelu analitycznego:
--Uproszczony opis systemu;
--Hierarchiczna dekompozycja funkcji systemu;
--Model logiczny jest opisany przy pomocy notacji zgodnej z pewną konwencją;
--Jest on zbudowany przy użyciu dobrze rozpoznanych metod i narzędzi;
--Jest on używany do wnioskowania o przyszłym oprogramowaniu;
Model oprogramowania powinien być jego uproszonym opisem, opisującym wszystkie istotne cechy oprogramowania na wysokim poziomie abstrakcji.
Model ten jednakże  nie zastępuje doświadczenia i wnikliwości projektantów, lecz pomaga projektantom w zastosowaniu tych walorów.
Czynności w fazie analizy:
--Rozpoznanie, wyjaśnianie, modelowanie, specyfikowanie i dokumentowanie
   rzeczywistości lub problemu będącego przedmiotem projektu;
--Ustalenie kontekstu projektu;
--Ustalenie wymagań użytkowników;
--Ustalenie wymagań organizacyjnych;
--Inne ustalenia, np. dotyczące preferencji sprzętowych, preferencji w zakresie
   oprogramowania, ograniczeń finansowych, ograniczeń czasowych, itd.

Analiza nie powinna stawiać nacisku na zmianę rzeczywistości poprzez wprowadzenie tam nowych elementów, jej celem jest rozpoznanie wszystkich tych aspektów rzeczywistości, które mogłyby mieć wpływ na postać, organizację lub wynik projektu.