Szczegółowa specyfikacja funkcjonalności zamawianego oprogramowania. Założenia projektowe systemu NETDOC. część 1: założenia ogólne i funkcjonalność rdzenia systemu Założenia ogólne Celem projektu jest stworzenie systemu klasy DMS (Document Management System), czyli systemu przeznaczonego do pracy grupowej z dokumentami. System winen umożliwiać: przechowywanie dokumentów w strukturze oddającej logiczną strukturę organizacji wewnętrznej firmy, dostęp do dokumentów za pomocą przeglądarki internetowej dla pracowników firmy (jak system intranetowy) oraz współpracowników zewnętrznych (system ekstranetowy), przepływy dokumentów pomiędzy kooperantami, skanowanie dokumentów i automatyczne umieszczanie ich w strukturze systemu, tworzenie wersji dokumentów oraz praca na nich, zarządzanie projektami złożonymi z wielu dokumentów, zarządzanie kontaktami z klientami poprzez powiązanie klientów ze zbiorami dokumentów. Struktura systemu System winien być wytworzony w postaci modularnej z jądrem spajającym różne funkcjonalności. Jądro systemu powinno zawierać główne funkcjonalności związane ze sposobem opisu dokumentów oraz zarządzaniem użytkownikami. Pozostałe funkcjonalności winny być zamknięte w modułach. Funkcjonalności systemu objęte niniejszą umową 1. Repozytorium dokumentów 2. Zarządzania użytkownikami 3. Audyt 4. Powiadamianie o zmianach Założenia odnośnie oprogramowania po stronie serwera Oprogramowanie po stronie serwera winno być wykonane z wykorzystaniem technologii PHP. Generowane treści winny być zgodne ze standardem XHTML. Generacja treści winna być możliwa z wykorzystaniem narzędzi z projektu PHP w wersji 5 pracujących w środowisku systemu operacyjnego Linux. Wywoływanie PHP winno być możliwe z wykorzystaniem protokołu FastCGI. 1/6
Założenia odnośnie oprogramowania po stronie klienta Obsługiwany poprzez przeglądarkę internetową, w tym: Internet Explorer 7 i nowsze, Mozilla Firefox 2.0 i nowsze. Dla części funkcjonalności wymagana jest obsługa Java w wersji 1.6 lub nowszej oraz Adobe Flash. Założenia odnośnie modelu licencjonowania System winien umożliwiać pracę w następujących modelach licencjonowania: wdrożenie na serwerze dostarczonym przez klienta, utrzymywanie na serwerach własnych z ograniczeniem liczby aktywnych kont w systemie. Winna być ponadto możliwość ograniczania: przestrzeni dyskowej całkowitej oraz dla pojedynczego użytkownika, liczby obiektów w systemie. 2/6
Założenia szczegółowe - funkcjonalności ad 1) Repozytorium dokumentów Obiekty w systemie repozytorium winny tworzyć strukturę drzewiastą. Poprawnymi obiektami podstawowymi w systemie są foldery, dokumenty, obiekty systemowe. Każdy obiekt podstawowy w systemie winien posiadać: nazwę, opis, właściciela, datę utworzenia. Obiekty podstawowe powinny mieć możliwość rozszerzania ich o dodatkowe funkcjonalności przez dodatkowe dziedziczenie. Obiekt dokumentu winien posiadać: nazwę pliku, opis, listę słów kluczowych, sygnaturę. Do każdego obiektu dokumentu winna być możliwość przypisana pojedynczego pliku. Plik winien być dołączany poprzez załadowanie do systemu. Ładowanie pliku do systemu winno być możliwe poprzez: wykorzystanie akcji PUT/POST protokołu HTTP wprost z poziomu przeglądarki, dedykowany moduł napisany w języku Java. Moduł w języku Java winien umożliwiać załadowanie całej serii plików (wraz z automatycznym tworzeniem w drzewie dokumentów). Winno być możliwe ściągnięcie na lokalny komputer plików związanych z obiektami i zapisanie ich. Obiekt folderu winien mieć możliwość przechowywania dowolnych innych obiektów. Możliwe winno być zagłębianie folderów. 3/6
Obiekty systemowe to specjalne dokumenty umożliwiające wykonywanie określonych akcji w systemie, np.: modyfikację profilu użytkownika, ustawień systemowych. Wersjonowanie obiektów w systemie Każdy obiekt systemu winien mieć możliwość wersjonowania. rozumiane jest to jako zdolność do istnienia wielu wersji jednego dokumentu w systemie. Każda z wersji winna charakteryzować się: numerem rewizji, nazwą pliku w rewizji, opisem pliku w rewizji, danymi inforującymi o autorze zmian (identyfikator w systemie), dacie dokonania zminy, komentarzem do rewizji. Winna istnieć możliwość: pobrania obiektu z każdej rewizji, przywrócenia obiektu do konkretnej rewizji. System winien być zaimplementowany jako ekstranetowy system zainstalowany na serwerach i obsługiwany z poziomu przeglądarki internetowej. ad 2) Zarządzanie użytkownikami Zarządzanie użytkownikami: informacje o użytkowniku System winien posiadać następujące informacje o każdym użytkowniku (koncie): nazwę użytkownika (login), imię i nazwisko, adresy email, datę utworzenia z informacjami o uzytkowniku tworzącym konto, nazwę firmy, numery telefonów, opisowe pole na dodatkowe informacje, hasło, flagę: konto aktywne, flagę: konto superużytkownika, flagę: wymuś zmianę hasła po zalogowaniu, flagę: dostęp do logów i statystyk systemu, 4/6
flagę: automatyczne powiadamianie o zmianach. W panelu administracyjnym winna być możliwa zmiana wszystkich parametrów dotyczących użytkownika. Każdy użytkownik winien mieć możliwość zmiany wybranych pól. Zarządzanie użytkownikami: grupy W systemie winna być możliwość grupowanie uzytkowników. Każda grupa może zawierać dowolną liczbę użytkowników, a każdy użytkownik może należeć do wielu grup. Informacje dotyczące grupy: identyfikator numeryczny, nazwa grupy, opis. W panelu administracyjnym winna być możliwość podgladu członków grupy. Zarządzanie użytkownikami: autentykacja Autentykacja użytkownika winna odbywać się poprzez parę: identyfikator i hasło. Hasła winny być przechowywane w centralnej bazie danych w postaci utrudniającej ich odtworzenie w przypadku utraty bazy użytkowników. Winien zostać stworzony moduł sprawdzający siłę hasła. Zarządzanie użytkownikami: autoryzacja System autoryzacji winien umożliwiać na utworzenie reguł dostępu dla każdego użytkownika oraz grupy użytkowników. Każda reguła winna umożliwiać ustawienie praw: odczytu paramterów obiektów, zapisu parametrów obiektów, tworzenia nowych obiektów, usuwania obiektów, modyfikacji obiektów, stosowania do obiektów potemnych, blokowania dziedziczenia. Reguła winna mieć możliwość stosowania na dowolnym poziomie drzewa obiektów. 5/6
Efektywnie winna być możliwość ograniczenia dostępu użytkownika do pewnego fragmentu drzewa dokumentów. ad 3) Audyt Moduł audytu winien umożliwiać śledzenie wykorzystania obiektów oraz pracę użytkowników w systemie. Audyt obiektów winien być realizowany na poziomie wersji pojedynczego dokumentu i obejmować: pobrania, zmiany. Audyt użytkowników winien na poziomie pojedynczego użytkownika oraz grupy użytkowników obejmować: logowanie oraz wylogowywanie się użytkownika do systemu z zachowaniem informacji niezbędnych do odtworzenia miejsca logowania użytkownika (IP klienta), wszelkie zmiany w stanie obiektów w systemie dokonanych przez użytkownika, listę aktualnie zalogowanych w systemie uzytkowników, listę ostatnio zalogowanych użytkowników. ad 4) Powiadamianie o zmianach System powiadamiania o zmianach winien umożliwiać wysłanie powiadomień pocztą email do wybranych użytkowników systemu oraz do ich grup zewnętrznych w przypadku zmiany stanu obiektu. Na poziomie panelu administracyjnego systemu winna być możliwość ustawienia domyślnych częstotliwości dla systemu powiadomień oraz umożliwiać łączenie powiadomień w paczki. 6/6