Wymagania funkcjonalne I niefunkcjonalne



Pobieranie 0.56 Mb.
Strona5/14
Data28.04.2016
Rozmiar0.56 Mb.
1   2   3   4   5   6   7   8   9   ...   14

1.7Dostosowywanie systemu

1.7.1 Projektowanie szablonów dokumentów i spraw


  1. System musi umożliwiać definiowanie różnych typów pism, z właściwym dla danego typu zestawem metadanych.

  2.  System musi umożliwiać tworzenie różnych szablonów pism, poprzez określenie listy pól metadanych i pól treści pisma, z możliwością określenia formatu tych pól, reguł poprawności danych, wartości domyślnych, wartości predefiniowanych itd.

  3.  System musi umożliwiać definiowanie różnych typów spraw z właściwym dla danego typu zestawem metadanych.

  4.  Metadane (atrybuty), które mogą być skojarzone z pismem lub sprawą, oraz pola szablonu treści pisma, muszą obejmować co najmniej następujące typy: tekst (czysty i formatowany), liczba, data i godzina, lista wyboru (jedno- i wielokrotnego wyboru) otwarta i zamknięta, osoba (użytkownik lub grupy), odnośnik (link) do jednego lub wielu dokumentów, obliczeniowa.

  5.  System musi mieć możliwość tworzenia definicji typów metadanych (atrybutów), jako elementów do wielokrotnego wykorzystania w definicjach typów pism lub spraw.

  6.  System musi umożliwiać definiowanie wartości domyślnych dla metadanych (atrybutów) pisma lub sprawy oraz pól i sekcji szablonu treści pisma.

  7.  System musi umożliwiać ustawianie wartości predefiniowanych (tzn. przypisywanych ręcznie lub automatycznie i nie podlegających dalszej edycji) dla metadanych (atrybutów) pisma lub sprawy oraz pól i sekcji szablonu treści pisma.

  8.  System musi umożliwiać zdefiniowanie obowiązkowych elementów metadanych (atrybutów) pisma lub sprawy,

  9.  System musi zapewnić co najmniej automatycznie wypełniane następujące wartości: bieżąca data, bieżący czas, bieżący użytkownik oraz podstawowe informacje o atrybutach plików: data utworzenia, data modyfikacji, autor utworzenia, autor modyfikacji.

  10.  W momencie dostarczenia systemu podstawowy zestaw atrybutów dla wszystkich pism powinien obejmować co najmniej takie elementy jak:

    1. data wpływu,

    2. typ pisma (wybór ze słownika),

    3. komórka, która zajmie się przetworzeniem pisma (wybór ze słownika),

    4. sygnatura nadawcy,

    5. numer nadawczy,

    6. nadawca (wybór ze słownika),

    7. adresat - w przypadku korespondencji imiennej,

    8. data pisma,

    9. odnośniki do dokumentów powiązanych,

    10. data odpowiedzi (dla pism wpływających jest to data, do której jednostka statystyki musi udzielić odpowiedzi, dla pism wychodzących data, do której oczekujemy odpowiedzi).

  1. Upoważniony użytkownik musi mieć możliwość definiowania nowego typu pisma, który automatycznie zostanie dodany do listy typów pism.

  2. Upoważniony użytkownik musi mieć możliwość modyfikowania szablonu pisma określonego typu.

  3. Musi istnieć możliwość określenia dla typu pisma terminu (np. 30 dni), w jakim wymagane jest sporządzenie odpowiedzi na pisma tego typu. Przy rejestracji takiego dokumentu system powinien uzupełnić pole "data odpowiedzi" na podstawie zdefiniowanego terminu i daty wpływu dokumentu.

  4. W momencie dostarczenia systemu podstawowy zestaw atrybutów dla wszystkich spraw musi obejmować:

  1. datę wszczęcia, datę zakończenia, opis sprawy,

  2. odnośnik do pisma wszczynającego sprawę,

  3. opis sprawy,

  4. uwagi,

  5. znak sprawy (identyfikator komórki organizacyjnej, symbol z JRWA, numer sprawy w ramach danego symbolu, rok wszczęcia sprawy),

  6. pole deklaracji, czy komórka rejestrująca sprawę jest komórka macierzystą.

  1.  System musi posiadać konfigurowalny pod względem formatu numeru mechanizm do nadawania unikalnych numerów pism/spraw wspólny dla całego Systemu, zależny od typu pisma, któremu numer jest nadawany. Numer referencyjny musi zawierać co najmniej: rok, miesiąc, numer kolejny oraz oznaczenia tekstowe i znaki rozdzielające.

  2. System musi dawać możliwość zapisania szablonu pisma lub sprawy z możliwością ponownego użycia.

  3. System musi umożliwiać generowanie na podstawie szablonów pism w formacie XML.

1.7.2 Projektowanie rejestrów





  1. System musi umożliwiać definiowanie i prowadzenie rejestrów, w tym rejestrów kancelaryjnych.

  2. Podczas definiowania rejestru musi istnieć możliwość określenia, czy rejestr będzie gromadził dokumenty dobrane automatycznie przez system na podstawie zdefiniowanej kombinacji wartości wskazanych atrybutów, czy dokumenty ręcznie wybrane przez użytkownika.

  3. Musi istnieć możliwość zdefiniowania formatu identyfikatora, który system nadawał będzie dokumentom należącym do rejestru, a który będzie umożliwiał lokalizację dokumentu w ramach rejestru.

  4. Podczas definiowania rejestru musi być możliwość ustalenia, jakie dodatkowe metadane związane z przynależnością do danego rejestru będą posiadały zgromadzone w nim pisma. Do metadanych związanych z przynależnością dokumentu do rejestru stosuje się te same wymagania, co do metadanych określanych w czasie definiowania szablonu pisma (format, wartości domyślne, walidacja itp.).

  5. Musi istnieć możliwość prowadzenia rejestru na dowolnym poziomie struktury organizacyjnej, czyli zarówno dla całej jednostki lub grupy jednostek, jak i komórki dowolnego szczebla lub grupy komórek.

  6. Musi istnieć możliwość zdefiniowania uprawnień do rejestru co najmniej następującego rodzaju:

a) prowadzenie rejestru,

b) wgląd do rejestru,

c) tworzenie/modyfikacja schematu rejestru.


  1. Podczas definiowania rejestru musi istnieć możliwość utworzenia szablonu wydruku tego rejestru.

  2. W momencie oddania do użytkowania system powinien mieć zdefiniowane następujące rejestry:

a) spisów zdawczo-odbiorczych,

b) rejestr protokołów oceny dokumentacji niearchiwalnej przeznaczonej do zniszczenia,

c) zbiór aktów normatywnych i innych Prezesa GUS,

d) zbiór aktów normatywnych Dyrektora Generalnego GUS,

e) rejestry korespondencji wchodzącej i wychodzącej (na poziomie poszczególnych komórek organizacyjnych),

f) książka pocztowa (przesyłek wysłanych jako polecone),



  1. zestawienie przesyłek wysłanych w formie papierowej,

  2. zestawienie przesyłek wysłanych w formie elektronicznej,

  3. dokumenty nieprzypisane do spraw,

  4. dokumenty w trakcie dekretacji,

  5. dokumenty rozpatrywane,

  6. dokumenty, na które oczekiwana jest odpowiedź,

  7. spis spraw w podziale na teczki spraw,

  8. spis dokumentów dotyczących sprawy.



1.7.3 Projektowanie szablonów stron





  1.  Szablony serwisu (wygląd i nawigacja) będą mogły być zmieniane bez ingerencji w treści, tj. zmiana wyglądu nie będzie pociągała za sobą konieczności odtwarzania treści serwisu.

  2.  System obsługiwał będzie szablony stron określające sposób wyświetlania wszystkich elementów składowych strony.

  3.  Uprawnienia do modyfikacji oraz tworzenia nowych szablonów należeć będą do zdefiniowanej grupy użytkowników.

  4.  System musi oferować możliwość zapisywania utworzonych stron jako standardowych szablonów stron do poźniejszego wykorzystania.

  5.  Przygotowanie standardowego szablonu nie może wymagać od użytkownika znajomości specjalistycznych technologii informatycznych związanych z projektowaniem stron, powinno być wykonywane automatyczne przez system i bez potrzeby wykorzystania narzędzi programistycznych.

  6.  Strony utworzone na podstawie standardowego szablonu muszą być całkowicie niezależne od strony będącej wzorcem.

  7.  System musi dawać możliwość wykorzystywania, do tworzenia stron, zaawansowanych szablonów, przygotowanych przy użyciu zewnętrznych narzędzi przez projektantów.

  8.  Przygotowanie zaawansowanego szablonu musi być możliwe przy wsparciu graficznego narzędzia do projektowania stron.

  9.  System musi umieć zapamiętać w szablonie co najmniej:

    1. układ graficzny strony (schemat kolorystyki, ikony, czcionki, itp.),

    2. układ elementów funkcjonalnych umieszczonych na stronie (ilość, umiejscowienie, status widoczności),

    3. konfigurację elementów funkcjonalnych, w szczególności ustawienia ich wyglądu – tzw. widoki.

  1.  System musi umożliwiać dodanie do szablonu strony dodatkowych atrybutów - w tym co najmniej nazwy i opisu szablonu.

  2.  System musi udostępniać mechanizm publikowania i zarządzania szablonami stron analogiczny do mechanizmów publikowania i zarządzania pozostałą treścią, w szczególności powinien zapewniać co najmniej wersjonowanie.



1.7.4 Projektowanie formularzy elektronicznych





  1.  W ramach systemu dostarczony zostanie moduł projektowania i publikowania formularzy elektronicznych. Moduł może być dostępny z poziomu SII albo dostarczony w formie aplikacji instalowanych na komputerach projektantów. W przypadku licencjonowania rozwiązania Zamawiającemu zostaną przekazane prawa do nieograniczonego czasowo użytkowania dziesięciu licencji niezbędnych dla projektowania formularzy.

  2.  Moduł formularzy musi zapewnić możliwość projektowania formularzy, które będą mogły być wypełniane, przez użytkowników, z poziomu przeglądarki internetowej. Pełna funkcjonalność formularzy webowych powinna być dostępna co najmniej z poziomu przeglądarki Internet Explorer (wersja 7.0 i nowsze). Podstawowa funkcjonalność rozwiązania (nie powodująca jednak braku możliwości wypełnienia i przekazania zaprojektowanego formularza) powinna być dostępna z poziomu co najmniej przeglądarki Mozilla Firefox (wersja 2.0 i nowsze). Specyficzne funkcjonalności mogą działać z poziomu innych przeglądarek niż Internet Explorer w ograniczonym zakresie.

  3.  Moduł formularzy musi zapewnić zapisywanie/wysyłanie danych, wprowadzonych na formularzu, w formacie XML.

  4.  Moduł formularzy musi zapewnić możliwość wskazania miejsca docelowego przechowywania dla zapisywanych/wysyłanych danych.

  5.  Moduł formularzy musi zapewnić możliwość testowego sprawdzenia działania formularza (wypełnienia) bez konieczności publikowania go w środowisku intranetowym.

  6.  Moduł formularzy musi mieć możliwość automatycznego publikowania formularza w Portalu Korporacyjnym GUS, w bibliotece formularzy wskazanej przez projektanta oraz zapewniać możliwość wypełnienia go przez użytkownika z poziomu Portalu Korporacyjnego GUS.

  7. Moduł formularzy musi dodatkowo zapewniać możliwość publikowania formularzy w lokalizacji sieciowej w tym na ESP oraz wysłania go do listy adresatów e-mail.

  8.  Moduł formularzy musi pozwolić na automatyczne tworzenie formularza na podstawie dokumentu XML lub schematu xsd.

  9.  Moduł formularzy musi pozwolić na automatyczne tworzenie formularza na podstawie bazy danych MS SQL, bądź MS Access jako źródła danych dla formularza.

  10.  Moduł formularzy musi pozwalać na generowanie różnych widoków danych, w tym widoku do wydruku.

  11.  Moduł formularzy musi dawać możliwość wydrukowania wypełnionego formularza zgodnie z przygotowanym widokiem wydruku.

  12.  Moduł formularzy musi być wyposażony w prosty w obsłudze edytor typu WYSIWYG (What You See Is What You Get) do tworzenia, publikowania i udostępniania formularzy elektronicznych pozwalający co najmniej na:

    1. zdefiniowanie układu formularza,

    2. określenie wielkości, rodzaju i koloru czcionki oraz koloru wyróżnienia,

    3. pogrubienie, zastosowanie kursywy i podkreślenie tekstu,

    4. wyrównanie tekstu do lewej, prawej, do środka lub wyjustowanie,

    5. numerowanie i wstawianie punktorów,

    6. wstawienia nagłówka i stopki,

    7. wstawianie symboli.

  1.  Edytor formularzy musi umożliwiać definiowanie reguł walidacyjnych dla wprowadzanych danych np. dopuszczalna ilość znaków.

  2.  Edytor formularzy musi pozwalać na wykorzystanie przy tworzeniu formularza co najmniej następujących typów pól:

  1. pole tekstowe,

  2. pole tekstu sformatowanego posiadające edytor umożliwiający formatowanie wpisywanej treści,

  3. lista rozwijana,

  4. pole zaznaczenia (checkbox),

  5. pole wyboru (radio),

  6. przycisk do generowania zdarzeń,

  7. pole przesyłania pliku (załącznik),

  8. link umożliwiający umieszczenie adresu URL,

  9. wybór daty w formie kalendarza,

  10. pole tabeli danych umożliwiające dodawanie, usuwanie, edycję danych,

  11. pole sekcji,

  12. pole sekcji powtarzalnej,

  13.  wyrażenie XPath.

  1.  Pole tekstowe musi mieć możliwość prostego ograniczenia wprowadzanych wartości co najmniej do następującego typu danych:

    1. tekst (string),

    2. liczba całkowita (integer),

    3. prawda/fałsz (boolean),

    4. ułamek dziesiętny (double),

    5. hiperłącze,

    6. data,

    7. data i godzina.

  1.  Pole tekstu sformatowanego musi zapewnić:

    1. możliwość zawijania tekstu,

    2. pokazywania pasków przewijania jeśli jest to konieczne,

    3. rozszerzenia wielkości pola, aby widoczny był cały tekst.

  1. Edytor formularzy musi umożliwiać oprogramowanie zdarzeń, przycisków, wprowadzania reguł, wstawiania wartości domyślnej i formatowania warunkowego bez znajomości języków programowania.

  2. Edytor formularzy musi posiadać łatwo dostępne przyciski narzędziowe, które pozwolą wykonać następujące czynności:

    1. dodaj obrazek tła formularza,

    2. ustaw kolor tła formularza,

    3. wytnij/kopiuj/wklej – osobne przyciski pozwalające na wykonanie określonych czynności na pojedynczych elementach formularza, bądź grupach elementów,

    4. zmień rozmiar i rodzaj czcionki – osobne przyciski do zwiększania i zmniejszania rozmiaru oraz menu rozwijalne z możliwością wyboru czcionki.

  1.  Moduł musi umożliwiać podłączenie formularza, zarówno w celu przesłania danych, jak i odebrania danych, pod zewnętrzne źródło danych w postaci co najmniej takich obiektów jak: dokument XML, baza danych MS SQL (w celu pobrania danych), usługa sieci web (web service), repozytorium Portalu Korporacyjnego (tylko wysłanie danych), lista Portalu Korporacyjnego (tylko pobranie danych), wiadomość e-mail.

  2.  Edytor formularzy musi umożliwiać walidowanie poprawności konstrukcji formularza. W przypadku wystąpienia błędów moduł musi zapewnić wyświetlenie odpowiednich, zrozumiałych komunikatów o błędach.

  3. Edytor formularzy musi umożliwiać utworzenie powiązanego z szablonem formularza schematu widoku formularza w wersji do wydruku.


1   2   3   4   5   6   7   8   9   ...   14


©absta.pl 2016
wyślij wiadomość

    Strona główna