dokumentacja - przykład, WAT, SEMESTR VII, PZ


System Zarządzania Ruchem Miejskim

Dokument Specyfikacji Wymagań

Wersja 0.1


Historia Zmian

Data

Wersja

Opis zmiany

Autor

06/05/2005

0.1

Powstanie dokumentu :-)

M.Gutowski

Spis treści

1. Wprowadzenie

Dokument Specyfikacji Wymagań

  1. Wprowadzenie

    Dokument Specyfikacji wymagań jest wynikiem, podsumowaniem fazy analizy, która ma za zadanie przełożyć cele klienta na wymagania zapewniające realizację tych celów. Na tym etapie anlityk ma odpowiedziec na pytanie co dany system ma robić.

    Cel dokumentu

    Celem tego dokumentu jest określenie sposobu działania projektowanego systemu informatycznego.

    Zakres dokumentu

    Dokument swoim zakresem obejmuje wymagane środki i nakłady na stworzenie systemu, całkowite koszty związane z wdrożeniem projektowanego systemu, określa niezbędny czas realizacji systemu oraz zawiera opis platform sprzętowych niezbędnych do prawidłowego dzialnia systemu.

    1. Cel

      System ma wprowadzać nowe standardy w komunikacji miejskiej. Głównym jego zadaniem jest zwiększenie wygody użytkowników publicznego transportu miejskiego poprzez udostępnienie wszelkich informacji na temat realizowanych przewozów

    2. Zakres

      Zakresem systemu jest zarządzanie relacjami z klientem oraz zasobami ludzkimi.

    3. Definicje, akronimy i skróty

      1. System - program komputerowy ułatwiający pracę, dostarczający potrzebnych informacji

      2. Baza danych - program przechowujący informacje, pozwala na łatwe ich wyszukiwanie po zadanych kryteriach

      3. Aktor - osoba, która korzysta z systemu

      4. Przeglądarka internetowa (WWW) - program komputerowy umożliwiający oglądanie stron internetowych

      5. Przeglądarka WAP - program w telefonach komórkowych umożliwiający oglądanie stron internetowych

      6. Strona WWW - strona internetowa

      7. Nośnik danych - oprócz twardego dysku może to być płyta CD lub DVD

    4. Dokumenty powiązane

[Tutaj należy umieścić kompletną listę dokumentów, do których występują odwołania gdziekolwiek w obrębie Dokumentu Specyfikacji Wymagań. Dla każdego dokumentu podaj: tytuł, datę publikacji oraz organizację publikującą. Przedstaw także źródła, skąd można go uzyskać.]

    1. Organizacja dokumentu

[W tym miejscu należy umieścić informację o tym, co zawiera pozostała część Dokumentu Specyfikacji Wymagań oraz krótkie wyjaśnienie tego, jak dalszy materiał jest zorganizowany.]

  1. Opis ogólny

System ma obejmować wszystkie środki transportu komunikacji miejskiej tj. Autobusy, Tramwaje, Metro, Trolejbusy.
Z systemu będą korzystać zarówno pracownicy ZTM (za pomocą intranetu) jak i użytkownicy komunikacji miejskiej (za pomocą WWW, SMS)

    1. Diagram przypadków użycia - wnioski

[W tym miejscu powinien znaleźć się ogólny opis diagramu przypadków użycia lub jego fragmentu odpowiedniego dla opisywanego podsystemu lub funkcji. W skład tego opisu musi wejść lista nazw i krótki ich opis dla wszystkich przypadków użycia oraz aktorów, załączając odpowiednie diagramy i relacje pomiędzy nimi.]

    1. Założenia i zależności

[Ta sekcja opisuje środki technologiczne mające wpływ na analizę funkcjonalną, dostępność gotowych podsystemów lub komponentów lub inne założenia, które są istotne z punktu widzenia budowy Dokumentu Specyfikacji Wymagań.]

  1. Wymagania systemowe

[Ta sekcja Dokumentu Specyfikacji Wymagań zawiera wszystkie wymagania systemowe na takim poziomie szczegółowości, aby projektanci mogli zbudować rozwiązanie zgodne z tymi wymaganiami a testerzy mogli stworzyć plan testów sprawdzających realizację tych wymagań.]

    1. Wymagania funkcjonalne

[Diagram przypadków użycia zawiera większość wymagań funkcjonalnych na system wraz z niektórymi wymaganiami niefunkcjonalnymi. Dla każdego zidentyfikowanego przypadku użycia załącz szczegółowy opis w tej secji. Upewnij się, że każde wymaganie jest jasno nazwane.]

      1. System taryfowy

        1. Definiowanie systemu tartyfowego

Konteks użycia

Przypadek opisuje w jaki sposób do systemu zostanie wprowadzony nowy system taryfowy.

Zakres

System taryfikacji

Poziom

Cel uzytkownika

Aktor główny

Operator danych

Uczestnicy i interesy

Uczestnikiem przypadku użycia jest:

- Dział Taryfikacji : wprowadza nowe dane definujące system taryfowy.

Warunek początkowy

Operator Danych jest zalogowany w systemie i posiada uprawnienia do zapisu danych w bazie danych.

Minimalna gwarancja

Brak.

Gwarancja powodzenia

Nowe dane są poprawnie wprowadzone do bazy danych.

Wyzwalacz

Zapotrzebowanie na wprowadzenie, modyfikacje danych dotyczacych taryfikacji.

Główny scenariusz powodzenia

1. Aktor wybiera funkcję „definiuj system taryfowy”.

2. System wyświetla formularz do wprowadzenia danych.

3. Aktor wprowadza dane i zatwierdza wprowadzone informacje

4. System stwierdza, że wymagane pola są wypełnione i wprowadzone wartości pól są poprawne, i:

- zapisuje (uaktualnia) dane do bazy danych

5. Zakończenie akcji przypadku użycia

Rozszerzenia

4a. System stwierdza że wymagane pola nie zostały wypełnione i wyświetla komunikat informujący o tym.

4a1. powrót do pkt 3. „głównego scenariusza”

4b. System stwierdza że wprowadzone dane są niepoprawne i wyświetla komunikat informujący o tym.

4b1. powrót do pkt 3. „głównego scenariusza”

Lista wariantów technologii i danych

Brak.

Dodatkowe informacje

System umożliwia na każdym etapie przerwanie akcji realizacji przypadku użycia. Przerwanie akcji zarówno w głównym scenariuszu powodzenia jak i w jego rozszerzeniach nie powoduje zmiany stanu danych w bazie danych.

Formularz zawiera następujące pola:

- Cena biletu jednorazowego (wymagane)

- Cena biletu dobowego (wymagane)

- Cena biletu 3-dobowego (wymagane)

- Cena biletu 1-tygodniowego (wymagane)

- Cena biletu 30 dniowego na okaziciela (wymagane)

- Cena biletu 30 dniowego na dokument (wymagane)

- Cena biletu 90-dniowego na okaziciela (wymagane)

- Cena biletu 90-dniowego na dokument (wymagane)

- Procent zniżki na legitymację studencką (wymagane)

- Procent zniżki na legitymację uczniowską (wymagane)

        1. Wyświetlanie analizy dotyczącej systemu taryfowego

Konteks użycia

Przypadek opisuje w jaki sposób system dostarcza dane potrzebne do przeprowadzenia analizy systemu taryfowego.

Zakres

System taryfikacji

Poziom

Cel uzytkownika

Aktor główny

Analityk

Uczestnicy i interesy

Uczestnikiem przypadku użycia jest:

- Dział Taryfikacji : analizuje dane dotyczące systemu taryfowego.

Warunek początkowy

Analityk jest zalogowany w systemie.

Minimalna gwarancja

Brak.

Gwarancja powodzenia

Dane są poprawnie wyświetlone na wykresie.

Wyzwalacz

Zapotrzebowanie na przeprowadzenie analizy taryfikacji.

Główny scenariusz powodzenia

1. Aktor wybiera funkcję „analizuj system taryfowy”.

2. Aktor wybiera jeden przedział czasowy z dwóch kategorii:

Przeglądanie miesiącami

Przeglądanie latami

3. Aktor wybiera z listy interesujące go miesiące bądź lata

4. System wyświetla wykres przedstawiający stosunek ceny biletów do uzyskanych przychodów z tytułu sprzedaży biletów w zadanym okresie czasowym.

5. Zakończenie akcji przypadku użycia

Rozszerzenia

Brak

Lista wariantów technologii i danych

Brak.

Dodatkowe informacje

System umożliwia na każdym etapie przerwanie akcji realizacji przypadku użycia. Przerwanie akcji zarówno w głównym scenariuszu powodzenia jak i w jego rozszerzeniach nie powoduje zmiany stanu danych w bazie danych.

Formatka zawiera następujące pola:

- Pole wyboru „przegladanie miesiacami”

- Pole wyboru „przegladanie latami”

- Liste wyboru miesiąca początkowego

- Liste wyboru miesiąca końcowego

- Liste wyboru roku początkowego

- Liste wyboru roku końcowego

      1. Raportowanie i analiza

        1. Raportowanie pracy kierowców i kontrolerów

Konteks użycia

Przypadek opisuje w jaki system wyświetla raport na temat pracownika z grupy kierowców lub kontrolerów.

Zakres

System raportowania

Poziom

Cel uzytkownika

Aktor główny

Analityk

Uczestnicy i interesy

Uczestnikiem przypadku użycia jest:

- Dział Kadr : przegląda statystki pracowników

Warunek początkowy

Analityk jest zalogowany w systemie.

Minimalna gwarancja

Brak.

Gwarancja powodzenia

Dane są poprawnie wyświetlone w formie raportu.

Wyzwalacz

Zapotrzebowanie na przeanalizowanie jakości, wydajności pracy pracownika.

Główny scenariusz powodzenia

1. Aktor wybiera funkcję „pokaż raport o pracowniku”.

2. Aktor wybiera grupe pracowników:
- albo kierowcy
- albo kontrolerzy

3. Aktor wybiera pracownika poprzez wskazanie nazwiska i imienia na liście

4. System stwierdza, że wymagane pola są wypełnione i wyświetla raport o pracowniku.

5. Zakończenie akcji przypadku użycia

Rozszerzenia

4a. System stwierdza że wymagane pola nie zostały wypełnione (pracownik nie został wybrany z listy) i wyświetla komunikat informujący o tym.

4a1. powrót do pkt 3. „głównego scenariusza”

Lista wariantów technologii i danych

Brak.

Dodatkowe informacje

System umożliwia na każdym etapie przerwanie akcji realizacji przypadku użycia. Przerwanie akcji zarówno w głównym scenariuszu powodzenia jak i w jego rozszerzeniach nie powoduje zmiany stanu danych w bazie danych.

Formatka zawiera następujące pola:

- Pole wyboru kierowcy

- Pole wyboru kontrolera

- Lista jednokrotnego wyboru pracownika po nazwisku i imieniu (posortowana rosnąco po nazwiskach)

Raport zawiera następujące informacje:

- terminowość pracownika

- efektywność (obliczaną przez system na podstawie zużytego paliwa podanego w litrach podczas przejechanej trasy podanej w kilometrach) (tylko kierowcy)

- liczbę wypadków (tylko kierowcy)

- opinie pasażerów (wyrażane w przeprowadzonych ankietach)

- ilość wypisanych mandatów za jazde bez ważnego biletu (tylko kontrolerzy)

- ilość złożonych skarg przez użytkowników komunikacji miejskiej

        1. Raportowanie obciążenia linii komunikacyjnej

Konteks użycia

Przypadek opisuje w jaki system wyświetla raport na temat obciążenia linii komunikacji miejskej

Zakres

System raportowania

Poziom

Cel uzytkownika

Aktor główny

Analityk

Uczestnicy i interesy

Uczestnikiem przypadku użycia jest:

- Dział Koordynacji Transportu : przegląda statystki poszczególnych linii komunikacji miejskiej

Warunek początkowy

Analityk jest zalogowany w systemie.

Minimalna gwarancja

Brak.

Gwarancja powodzenia

Dane są poprawnie wyświetlone w formie raportu.

Wyzwalacz

Zapotrzebowanie na przeanalizowanie obciążenia linii komunikacji miejskiej.

Główny scenariusz powodzenia

1. Aktor wybiera funkcję „pokaż raport o obciążeniu linii”.

2. Aktor wybiera numer linii, typ transportu, przedział czasowy

3. System stwierdza, że wymagane pola są wypełnione i wyświetla raport o linii.

5. Zakończenie akcji przypadku użycia

Rozszerzenia

3a. System stwierdza że wymagane pola nie zostały wypełnione i wyświetla komunikat informujący o tym.

3a1. powrót do pkt 2. „głównego scenariusza”

Lista wariantów technologii i danych

Brak.

Dodatkowe informacje

System umożliwia na każdym etapie przerwanie akcji realizacji przypadku użycia. Przerwanie akcji zarówno w głównym scenariuszu powodzenia jak i w jego rozszerzeniach nie powoduje zmiany stanu danych w bazie danych.

Formularz wyboru zawiera następujące pola:

- Wybór typu transportu

- Wybór numeru linii

- Wybór przedziału czasowego wyrażonego w godzinach

Raport zawiera następujące informacje:

- wykres obciążenia linii komunikacji pasażerami (oparte na ilości skasowanych biletów w zadanym przedziale czasowym)

        1. Raportowanie ogólny o ruchu i wydajności miejskiego systemu komunikacji

Konteks użycia

Przypadek opisuje w jaki system wyświetla ogólny raport opisującyruch i wydajność całego miejskiego systemu komunikacji.

Zakres

System raportowania

Poziom

Cel uzytkownika

Aktor główny

Analityk

Uczestnicy i interesy

Uczestnikiem przypadku użycia jest:

- Dział Koordynacji Transportu : przegląda statystki dotyczace całego systemu komunikacji

Warunek początkowy

Analityk jest zalogowany w systemie.

Minimalna gwarancja

Brak.

Gwarancja powodzenia

Dane są poprawnie wyświetlone w formie raportu.

Wyzwalacz

Zapotrzebowanie na przeanalizowanie obciążenia linii komunikacji miejskiej.

Główny scenariusz powodzenia

1. Aktor wybiera funkcję „pokaż raport ogólny”.

2. Aktor wybiera numer linii, typ transportu, przedział czasowy

3. System stwierdza, że wymagane pola są wypełnione i wyświetla raport o linii.

5. Zakończenie akcji przypadku użycia

Rozszerzenia

3a. System stwierdza że wymagane pola nie zostały wypełnione i wyświetla komunikat informujący o tym.

3a1. powrót do pkt 2. „głównego scenariusza”

Lista wariantów technologii i danych

Brak.

Dodatkowe informacje

System umożliwia na każdym etapie przerwanie akcji realizacji przypadku użycia. Przerwanie akcji zarówno w głównym scenariuszu powodzenia jak i w jego rozszerzeniach nie powoduje zmiany stanu danych w bazie danych.

Formularz wyboru zawiera następujące pola:

- Wybór typu transportu

- Wybór numeru linii

- Wybór przedziału czasowego wyrażonego w godzinach

Raport zawiera następujące informacje:

- wykres obciążenia linii komunikacji pasażerami (oparte na ilości skasowanych biletów w zadanym przedziale czasowym)

    1. Wymagania niefunkcjonalne

[Wymagania niefunkcjonalne powinny zawierać te ograniczenia systemowe, które nie są bezpośrednio związane z funkcjonalnością produktu. Każde wymaganie niefunkcjonalne powinno być w prosty i czytelny sposób opisane. Ważne jest, żeby poziom szczegółowości opisu pozwalał na zweryfikowanie, czy finalny produkt spełnia postawione wymagania. W tym celu dobrze jest, żeby przy opisie ograniczenia podać miarę, pozwalającą na przetestowanie systemu pod jego kątem.]

  1. Informacje pomocnicze

[Informacje pomocnicze mają na celu ułatwienie korzytania z Dokumentu Specyfikacji Wymagań. Mogą zawierać:

Spis treści

Indeks

Aneksy

W szczególności można tutaj zarzeć scenariusze dla przypadków użycia lub prototyp GUI. Gdy dołączymy w tym miejscu aneksy, należy jasno stwierdzić czy są one częścią Dokumentu Specyfikacji Wymagań czy też nie.]

522-1

System Zarządzania Ruchem Miejskim

Wersja: 0.1

Dokument Specyfikacji Wymagań

Data: 06/01/2005

<identyfikator dokumentu>

Poufne

©522-1, 2005

Strona 14



Wyszukiwarka

Podobne podstrony:
Wymagania udziałowców, WAT, SEMESTR VII, PZ
grupy rzeczownikowe, WAT, SEMESTR VII, PZ
dzialajacy portal, WAT, SEMESTR VII, PZ
wymagania, WAT, SEMESTR VII, PZ
Przedstawienie problemu1.1, WAT, SEMESTR VII, PZ
Historyjki (dobry), WAT, SEMESTR VII, PZ
Zaległości na dzień 23-03-2012, WAT, SEMESTR VII, PZ
wymagania2, WAT, SEMESTR VII, PZ
Przypadki użycia (tekst), WAT, SEMESTR VII, PZ
Zaległości z dnia 18-03-2012, WAT, SEMESTR VII, PZ
grupy czasownikowe, WAT, SEMESTR VII, PZ
Przedstawienie problemu, WAT, SEMESTR VII, PZ
Historyjki(radek), WAT, SEMESTR VII, PZ
Wizja Projektu, WAT, SEMESTR VII, PZ
Historyjki, WAT, SEMESTR VII, PZ
Styl RUP, WAT, SEMESTR VII, PZ
Przyjęcie na praktyki (scenariusz), WAT, SEMESTR VII, PZ
Wymagania udziałowców, WAT, SEMESTR VII, PZ
W2K3-15-raport, WAT, SEMESTR VII, Systemy operacyjne windows, Systemy operacyjne windows, sow, W2K3-

więcej podobnych podstron