Specyfikacja wymagań funkcjonalnych modułu zamówień Portalu B2B Projekt współfinansowany jest ze środków POIG zgodnie z rozporządzeniem Komisji (WE) nr 1828/2006 z dnia 8 grudnia 2006 r. ustanawiające szczegółowe zasady wykonania rozporządzenia Rady (WE) nr 1083/2006 ustanawiającego przepisy ogólne dotyczące Europejskiego Funduszu Rozwoju Regionalnego, Europejskiego Funduszu Społecznego oraz Funduszu Spójności oraz rozporządzenia (WE) nr 1080/2006 Parlamentu Europejskiego i Rady w sprawie Europejskiego Funduszu Rozwoju Regionalnego (Dz. Urz. UE L 371 z 27.12.2006)
Projekt modułu zamówień 2 Spis treści Specyfikacja wymagań funkcjonalnych modułu zamówień Portalu B2B...1 1. Wprowadzenie...3 1.1. Cel dokumentu...3 1.2. Zakres modułu...3 1.3. Definicje, akronimy, skróty...3 1.4. Odwołania do materiałów zewnętrznych...4 1.5. Omówienie dokumentu...4 1.6. Ogólny opis produktu...4 1.7. Kontekst funkcjonowania...5 1.8. Charakterystyka użytkowników...5 1.9. Główne funkcje produktu...6 1.10. Ograniczenia...6 1.11. Założenia i zależności...6 2. Wymagania funkcjonalne...7 2.1. Interfejsy zewnętrzne...7 2.2 Funkcje...8 1. Administrator...8 3. Przypadki Użycia...15 3.1. Administrator...15 4. Wymagania poza-funkcjonalne...15 4.1. Użyteczność...15 4.2. Niezawodność...16 4.3. Wydajność...16 4.4. Bezpieczeństwo...16
Projekt modułu zamówień 3 1. Wprowadzenie 1.1. Cel dokumentu Niniejszy dokument prezentuje wymagania dotyczące oprogramowania, czyli opisuje funkcjonalność budowanego oprogramowania i warunki, jakie ono musi spełniać. Dokument ten został napisany z myślą o odbiorcach projektu, projektantach i programistach. 1.2. Zakres modułu Celem projektu Portal B2B jest stworzenie zaawansowanego systemu teleinformatycznego wspomagającego przesył dokumentów, podgląd stanów magazynowych, realizację zamówień, generowanie zaawansowanych raportów, co przyspieszy i ułatwi obsługę partnerów biznesowych oraz usprawni ich komunikację. Moduł zamówień posiadał będzie trzy podstawowe funkcjonalności: możliwość automatycznego składania zamówień, dokonania opłaty i pobrania dokumentów, możliwość podglądu stanów magazynowych dostawców, możliwość podglądu stanu rozliczeń między dostawcami a Administratorem. 1.3. Definicje, akronimy, skróty 1) Moduł przedmiot niniejszej dokumentacji 2) Portal portal stworzony na zlecenie Klienta 3) Administrator nadrzędny właściciel portalu 4) Partner firma z sektora MŚP (łącznie z mikroprzedsiębiorstwami); wyróżnione zostają dwa rodzaje Partnerów: a) Dostawcy podmioty zajmujące się sprzedażą hurtową gadżetów reklamowych, b) Odbiorcy podmioty zajmujące się sprzedażą towarów wszelkiego rodzaju, 5) Administrator użytkownik portalu działający z pełnomocnitwa Wnioskodawcy
Projekt modułu zamówień 4 1.4. Odwołania do materiałów zewnętrznych 1. Specyfikacja wymagań funkcjonalnych modułu sprzedaży hurtowej Platformy B2B 2. Specyfikacja wymagań funkcjonalnych modułu statystyczno-analitycznego Platformy B2B 1.5. Omówienie dokumentu W rozdziale 1. omówiono ogólnie produkt wraz z krótką charakterystyką użytkowników i funkcjonalności, jaką będzie im udostępniał budowany system. Rozdział 2. jest poświęcony szczegółowemu opisowi wymagań funkcjonalnych, które zostały podzielone na grupy wg klas użytkowników (ról). Wymagania te są punktem wyjścia do opisu wymagań poza-funkcjonalnych, które przedstawiono w rozdziale 4. 1.6. Ogólny opis produktu Portal B2B jest zaawansowanym systemem teleinformatycznym wspomagającym przesył dokumentów, podgląd stanów magazynowych, realizację zamówień oraz generowanie zaawansowanych raportów, co przyspieszy i ułatwi obsługę partnerów biznesowych oraz usprawni ich komunikację. Dzięki funkcjonalnościom portalu wiele procesów, pojawiających się podczas współpracy partnerów biznesowych, zostanie zautomatyzowanych co, po pierwsze, przyspieszy ich przeprowadzenie, a po drugie wyeliminuje błędy ludzkie, przestoje bądź pomyłki. Przełoży się to bezpośrednio na zwiększenie obrotów i przychodów partnerów korzystających z portalu. System dostępny będzie w dwóch wersjach językowych: polskiej i angielskiej. W obu wersjach językowych walutą obowiązującą jest PLN, a wszystkie informacje o cenach produktów, pojawiające się w niniejszej dokumentacji dotyczą cen netto.
Projekt modułu zamówień 5 1.7. Kontekst funkcjonowania 1.8. Charakterystyka użytkowników Odbiorca Odbiorcy potrafią obsługiwać komputer w podstawowym zakresie. Prędkość ani Dostawca charakterystyka łączy dostępowych nie jest możliwa do zdefiniowania. Dostawcy potrafią obsługiwać komputer w podstawowym zakresie. Prędkość ani charakterystyka łączy dostępowych nie jest możliwa do zdefiniowania. Administrator Nadrzędny Administrator jest zaawansowanym użytkownikiem komputera. Łączy się z serwisem WWW za pośrednictwem sieci nie wolniejszej niż 1 mbit/s. Jest to jedna osoba.
Projekt modułu zamówień 6 1.9. Główne funkcje produktu Produkt udostępnia funkcje opisane poniżej. Odbiorca Może za pomocą modułu składać zamówienia, sprawdzać stany magazynowe dostawców oraz stan swoich rozliczeń, Dostawca Za pomocą modułu może przedstawiać swoje produkty Odbiorcom Administrator Może korzystać ze wszystkich funkcjonalności udostępnionych przez platformę, Administrator Nadrzędny 1. Może blokować konta użytkowników z systemu. 2. Może logować się na konta wybranych użytkowników, by w ich imieniu dokonywać zmian w systemie. 3. Może dodawać konta użytkowników w systemie. 4. Może korzystać ze wszystkich funkcjonalności portalu. 1.10. Ograniczenia Brak 1.11. Założenia i zależności 1. Serwer WWW Witryna WWW do poprawnego działania wymaga serwera WWW, na którym będzie uruchomiona i który zapewnia ciągły dostęp do witryny. Serwer musi udostępniać 1. Serwer Apache w wersji 2.0 lub nowszej. 2. Interpreter języka PHP w wersji 5.3 oraz biblioteką GD, APC, 3. Serwer baz danych MySQL z obsługą silnika InnoDB 4. Dostęp do oprogramowania zapewniającego okresowe wyzwalanie programów 5. (tzw. Cron) 6. Dostęp do plików na serwerze z pośrednictwem protokołu SCP 7. Dostęp do systemu kontroli wersji Subversion
Projekt modułu zamówień 7 Jednocześnie serwer musi być gotowy do dalszego rozszerzania funkcjonalności tak, aby nie ograniczać rozwoju serwisu WWW. Planowane na przyszłość usługi wymagane przez serwer to możliwość definiowania połączeń szyfrowanych (SSL). 2. Program od przeglądania stron internetowych WWW Odbiorcy, Dostawcy. Administratora, powinien: Być zgodny z Google Chrome, Być zgodny z Mozilla Firefox, Być zgodny z Internet Explorer 10 i nowszy, Mieć włączoną obsługę JavaScript, Być uruchomiony w rozdzielczości nie mniejszej niż 1366x768 pikseli W przypadku niespełnienia warunków dotyczących przeglądarki stron internetowych: 1) W przypadku Odbiorcy lub Dostawcy a) Niektóre funkcje modułu mogą być niedostępne 2) W przypadku Administratora a) Niektóre funkcje administracyjne mogą stać się niedostępne 2. Wymagania funkcjonalne 2.1. Interfejsy zewnętrzne Odbiorcy, Dostawcy, Administrator Są to osoby z różnych powodów aplikujące do serwisu WWW. Komunikacja pomiędzy internautą a serwisem WWW będzie się odbywać za pośrednictwem przeglądarki stron WWW. Serwis WWW musi być dostępny 24 godziny na dobę
Projekt modułu zamówień 8 2.2 Funkcje 1. Administrator 1.1. Dashboard. Po otrzymaniu dostępu do panelu, nadanego przez Administratora Nadrzędnego, Administrator będzie mógł zalogować się do systemu, poprzez podanie loginu i hasła. Po zalogowaniu zostanie przeniesiony do ekranu Dashboard. Administrator na ekranie dashboard będzie widział: aktualne saldo swoich rozliczeń będące różnicą sum przychodów i rozchodów (czyli sumą wpłat Odbiorców i sumą należną do zapłaty Dostawcom dane pobierane będą z zakładki Rozliczenia ), skrót do zamówień zrealizowanych opis historii zamówień w punkcie Zamówienia, ostatnie zamówień w toku szczegółowy opis ekranu, do którego prowadzi skrót w punkcie Zamówienia, skrót do ekranu zarządzania rabatami, ostatnie zamówienia Odbiorców widoczny będzie przedmiot zamówienia, nazwa odbiorcy oraz wartość zamówienia, wyświetlanych będzie 5 zamówień z najnowszą datą złożenia zamówienia, podgląd aktywności w polu wyświetlany będzie log aktywności, takich jak: złożenie zamówienia przez Odbiorcę (data, godzina, nazwa Odbiorcy, przedmiot, wartość zamówienia), zmiana statusu zamówienia (data, godzina, nazwa Administratora zmieniającego status, numer zgłoszenia), dodanie plików do zamówienia (data, godzina, nazwa Administratora dodającego pliki, numer zgłoszenia), dodanie/zablokowanie użytkownika (data, godzina, nazwa Administratora dokonującego zmiany, rodzaj dokonywania zmiany, nazwa edytowanego konta
Projekt modułu zamówień 9 użytkownika). W górnej części ekranu Administrator będzie miał dostęp do rozwijanej listy z opcjami konta, takimi jak zmiana hasła oraz wylogowanie (funkcjonalności analogiczne do opisanych w Specyfikacji Wymagań funkcjonalnych modułu sprzedaży hurtowej Platformy B2B punkt 2.2 Zmiana hasła oraz 2.3 Wylogowanie). W bocznym pasku ekranu administracyjnego użytkownik będzie miał do wyboru zakładki pozwalające na szczegółowe zarządzanie kontem, takie jak: Zamówienia szczegółowy opis ekranu w podpunkcie Zamówienia, Rozliczenia szczegółowy opis ekranu w Podgląd stanu rozliczeń, Reklamacje szczegółowy opis funkcjonalności w dokumencie Specyfikacja Wymagań funkcjonalnych modułu sprzedaży hurtowej Platformy B2B, Raporty szczegółowy opis funkcjonalności w dokumencie Specyfikacja Wymagań funkcjonalnych modułu statystyczno-analitycznego Platformy B2B, Rabaty - szczegółowy opis funkcjonalności w dokumencie Specyfikacja Wymagań funkcjonalnych modułu sprzedaży hurtowej Platformy B2B punkt 3.4 Zarządzanie Rabatami.
Projekt modułu zamówień 10 Szkic 2. Dashboard Administratora. Zamówienia Administrator z ekranu Dashboard będzie mógł sprawdzić listę wszyskich zamówień złożonych przez Odbiorców. Zamówienia będą mogły być filtrowane w zależności od statusu (Statusy zamówienia opisane zostały w dokumencie Specyfikacja wymagań funkcjonalnych modułu sprzedaży hurtowej Platformy B2B punkt 3.1 Obsługa zamówień Odbiorcy). W zakładce Zamówienia zrealizowane będą się znajdowały zamówienia posiadające status Zrealizowane, w zakładce Zamówienia anulowane znajdowały się będą wszystkie zamówienia ze statusem anulowane, a w zakładce Zamówienia w toku znajdowały się będą zamówienia ze wszystkimi pozostałymi statusami.
Projekt modułu zamówień 11 Widoczne dane każdego zamówienia to: Szkic 3. Lista zamówień - widok Administratora. nazwa Odbiorcy, numer zamówienia, nazwa produktu, ostateczny koszt zamówienia po kliknięciu pola koszt pokazana zostanie historia zmian kosztu zamówienia (nazwa Administratora wprowadzjącego zmianę, data, koszt przed zmianą, koszt po zmianie), status zamówienia (z możliwością jego edycji z rozwijanej listy), szczegóły zamówienia po kliknięciu pola szczegóły zamówienia, rozwinięta zostanie lista: podsumowanie wyświetlone zostanie podsumowanie zamówienia opis w
Projekt modułu zamówień 12 Specyfikacja wymagań funkcjonalnych modułu sprzedaży hurtowej Platformy B2B punkt 3.1 Obsługa zamówień Odbiorcy, edycja umożliwia wprowadzenie zmian w zamówieniu takich jak: zmiana ostatecznego kosztu zamówienia, zmiana statusu zamówienia, dodawania/usuwanie plików, zmiana adresu dostawy, zmiana wolumenu zamówienia, zmiana przedmiotu zamówienia, zmiana przypisanego podwykonawcym komentarz dla przypisanego podwykonawcy edycja powyższych danych jest możliwa do momentu zmiany statusu zamówienia na Zaakceptowane w realizacji, po ustawieniu tego statusu powyższe dane są widoczne tylko do odczytu. Wyświetlone zamówienia będą mogły zostać przefiltrowane za pomocą następujących filtrów: nazwa Odbiorcy może zostać wprowadzona ręcznie system wyświetli wszystkich Odbiorców, którzy mają w nazwie podaną frazę, nazwa produktu może zostać wprowadzona ręcznie system wyświetli wszystkie produkty, które mają w nazwie wpisaną frazę, status zamówienia może zostać wybrany z rozwijanej listy. Możliwe będzie filtrowanie wyników wyszukiwania po więcej niż jednym parametrze. W przypadku zdefiniowania więcej niż jednego filtru wyświetlone zostaną wyniki spełniające koniunkcję wszystkich zdefiniowanych parametrów. Przy każdym zamówieniu widoczny będzie także checkbox, dzięki czemu możliwe będzie zaznaczenie kilku dokumentów jednocześnie. 1.2. Złożenie zamówienia Złożenie zamówienia u Dostawcy składane będzie automatycznie poprzez system w zależności od zgłoszonego zapotrzebowania Odbiorców. Czynnością inicjującą wysłanie zamówienia do Dostawcy będzie zmiana statusu zamówienia Odbiorcy na Zaakceptowane w realizacji. Status może zostać zaktualizowany przez Administratora obsługującego zgłoszenie. Po zmianie statusu zamówienia na Zaakceptowane w realizacji wygenerowane zostanie zlecenie, zawierające: nazwę produktu wraz z ewentualnym kodem produktu bądź innym oznaczeniem
Projekt modułu zamówień 13 pozwalajacych na jego identyfikację przez Dostawcę, ilość sztuk zamawianego produktu, adres dostawy w przypadku zamówienia, w którym produkt zostaje poddany personalizacji jest to adres wybranego wcześniej podwykonawcy, (ekran opisany w dokumencie Specyfikacja Wymagań funkcjonalnych modułu sprzedaży hurtowej Platformy B2B, rozdział 2. Funkcje punkt 1.2 Definiowanie danych podwykonawcy), W przypadku zamówienia, które wymaga personalizacji przez firmę brandingową po zmianie statusu zamówienia na Zaakceptowane w realizacji wysyłana jest także informacja mailowa do wybranego podwykonawcy, w której znajdują się następujące dane: nazwa przedmiotu zamówienia, zamówiona ilość, zaakceptowana przez Odbiorcę wizualizacja, komentarz dla podwykonawcy (dodawany przez Adminsitratora w oknie edycji zamówienia Odbiorcy). 1.3. Podgląd stanów magazynowych. Wykonanie modułu zakłada udostępnienie Dostawcom Wnioskodawcy API, za pomocą którego systemy partnerów będą mogły komunikować się z Portalem. Podstawowym celem integracji systemów Wnioskodawcy i Dostawców poprzez portal będzie możliwość uzyskania informacji na temat stanów magazynowych Dostawców. Serwer Wnioskodawcy w regularnych odstępach czasu będzie otrzymywał informacje o aktualnych stanach magazynowych od zintegrowanych z portalem Dostawców. Pobrane dane będą natychmiast wykorzystywane do zaktualizowania informacji o dostępności poszczególnych produktów. Dane dotyczące ilości dostępnych do sprzedania produktów będą widoczne w szczegółach danego produktu. Dzięki temu Odbiorca przeglądający ofertę będzie miał aktualne informacje na temat tego, do ilu sztuk danego produktu w danej chwili ma dostęp Wnioskodawca.
Projekt modułu zamówień 14 1.4. Podgląd stanu rozliczeń. Po kliknięciu zakładki Rozliczenia wyświetlona zostanie lista wszystkich faktur wystawionych Wnioskodawcy z informacjami o tym, czy dokonano płatności, terminie płatności oraz krótkim podsumowaniem zamówienia. Dane niezbędne do wystawienia faktury przesyłane będą do Wnioskodawcy przez Dostawców za pośrednictwem API. W szczegółach faktury wyświetlona zostanie lista zamówień, do której jest ona przypisana z możliwością przejścia do szczegółów konkretnych zamówień. W przypadku dokonania opłaty Administrator ma możliwość ręcznego oznaczenia danego zamówienia jako Opłacone. Szkic 4. Podgląd stanu rozliczeń widok Administratora.
Projekt modułu zamówień 15 3. Przypadki Użycia Poniżej przedstawione są najważniejsze scenariusze użycia modułu zamówień. 3.1. Administrator 1. Przypadek użycia: edycja stanu rozliczeń. Przypadek użycia umożliwia oznaczenie faktury jako opłaconej. Zakres: Moduł Aktor główny: Administrator Warunek: Administrator jest zalogowany Wyzwalacz: Administrator chce przypisać fakturze status opłacona. Scenariusz podstawowy: 1) Użytkownik wciska przycisk Rozliczenia. 2) System wyświetla listę wszystkich wygenerowanych dla użytkownika faktur. 3) Użytkownik odszukuje interesującą go fakturę wpisując za pośrednictwem jednego z poniższych sposobów: 1. wpisanie w pole wyszukiwania pełnej bądź częściowej nazwy dostawcy, 2. wpisanie w pole wyszukiwania pełnego bądź częściowego numeru faktury, 3. wpisanie w pole wyszukiwania pełnej bądź częściowej nazwy produktu, 4. wybranie z rozwijanej listy statusu faktury: opłacona lub nieopłacona. 4) Użytkownik wciska przycisk Opłacona. 5) System przelicza aktualny stan rozliczeń Użytkownika uwzględniając opłacenie faktury. 6) System aktualizuje Saldo użytkownika. 7) System przenosi użytkownika do ekranu Dashboard. 4. Wymagania poza-funkcjonalne 4.1. Użyteczność Serwis internetowy powinien być intuicyjny w obsłudze. Internauci powinni móc korzystać z serwisu bez żadnych dodatkowych szkoleń. Administrator również powinien być w stanie korzystać z systemu bez dodatkowych szkoleń.
Projekt modułu zamówień 16 4.2. Niezawodność Niezawodność w przypadku serwisu WWW głównie opiera się na niezawodności serwera, na którym jest uruchomiony. Zakładając jednak, że serwer WWW jest całkowicie stabilny, średnia ilość czasu pracy bez awarii samego serwisu (tzw. MTBF) powinien wynosić minimum 90 dni. Maksymalny czas, na jaki serwis będzie musiał być wyłączony w celach pielęgnacyjnych to łącznie 24 godziny w ciągu 6 miesięcy. 4.3. Wydajność Wydajność serwisu WWW zależy głównie od Serwera, na którym został uruchomiony. Serwis będzie wyposażony w systemy wspomagające pracę pod dużymi obciążeniami. W szczególności w warstwę wspierającą load-balancing przy zastosowaniu struktury master-slave serwera MySQL. e-usługa będzie w stanie zapisywać dane do jednego serwera MySQL (master), a odczytywać dane z innego serwera MySQL (slave). 4.4. Bezpieczeństwo Wszelkie dane zapisywane przez serwis WWW w formie bazy danych muszą być odpowiednio zabezpieczone. Baza, w której znajdują się wrażliwe dane powinna być zabezpieczona hasłem oraz wszystkie dane, które nie muszą być odczytywane wprost (np. hasła) powinny być zaszyfrowane szyfrem jednostronnym. Osoba, której przydzielony jest dany poziom dostępu do serwisu (Internauta, Użytkownik), nie powinna móc samodzielnie zmienić swoich uprawnień.