Załącznik nr 11 do Umowy Stworzenie i wdrożenie zintegrowanego Systemu informatycznego - centralnej aplikacji CBO (Centralnej Bazy Odczytowej), wraz z systemem klasy MDMS (Meter Data Management System)

Wzór Projektu FunkcjonalnegoNazwa Projektu

2018

Wzór Projektu Funkcjonalnego

1 Spis treści

1 Spis treści........................................................................................................................................22 Słownik pojęć..................................................................................................................................33 Historia zmian.................................................................................................................................34 Cel dokumentu................................................................................................................................35 Zarządzanie zmianami dokumentu.................................................................................................36 Wprowadzenie................................................................................................................................4

6.1 Cel projektu............................................................................................................................46.2 Podział ról i odpowiedzialności w projekcie...........................................................................4

7 Opis najistotniejszych elementów/komponentów Systemu...........................................................48 Wymagania funkcjonalne................................................................................................................49 Opis wymagań funkcjonalnych systemu.........................................................................................5

9.1 Nazwa grupy wymagań...........................................................................................................510 Procesy biznesowe..........................................................................................................................711 Przypadki użycia..............................................................................................................................8

11.1 Aktorzy...................................................................................................................................812 Logiczny model danych...................................................................................................................813 Role i uprawnienia..........................................................................................................................914 Reguły walidacji danych..................................................................................................................915 Rysunki i schematy........................................................................................................................1016 Słowniki.........................................................................................................................................1017 Raporty..........................................................................................................................................1018 Lista kwestii otwartych..................................................................................................................1019 Załączniki.......................................................................................................................................10

2 | S t r o n a

Wzór Projektu Funkcjonalnego

2 Słownik pojęć

Rozdział powinien zawierać listę wszystkich pojęć wymagających określenia. Pojęcia te powinny być zaprezentowane w formie tabeli tak jak pokazuje przykład poniżej. Standardowo powinny być załączane definicje z dokumentacji OPZ.

Pojęcie Opis

3 Historia zmian

Rozdział powinien zawierać pełną historię zmian, historia powinna być opisana w formie poniższej tabeli.

Wersja Status Data Kto Komentarz

0.1 Konspekt

0.2 Wersja robocza

3 | S t r o n a

Wzór Projektu Funkcjonalnego

4 Cel dokumentu

Celem dokumentu jest doprecyzowanie i zawarcie wszystkich wymagań funkcjonalnych z uwzględnieniem tego jak będą one realizowane we wdrażanym Rozwiązaniu. Bazą wymagań są wymagania z zapytania ofertowego rozbudowane i uszczegółowione o wymagania zebrane podczas analizyW ramach prac nad dokumentem Wykonawca musi zrozumieć dokładnie wymagania i opisać je w doprecyzowanej formie tak jak będą realizowane w Rozwiązaniu. Zawarte opisy muszą precyzyjnie pokrywać wymagania opisane w dokumencie OPZ.

W trakcie trwania projektu dokument powinien być aktualizowany, a w szczególności po wdrożeniu projektu.

Zawartość dokumentu może zostać dostosowana do specyfiki i metodyki projektu.

5 Zarządzanie zmianami dokumentu

W rozdziale powinny zostać opisane zasady zarządzania dokumentacją.

W celu sprawnego zarządzania dokumentem jest on numerowany wersją (np. v.1.5) oraz oznaczany datą aktualizacji na pierwszej stronie. Numerowaniem i datowaniem dokumentu zarządza Wykonawca skąd dokument jest wysyłany do pozostałych uczestników procesu wdrożenia.

Niniejszy dokument może podlegać zmianom w okresie wdrożenia projektu. Główne źródła tych zmian to:

– uzupełnienia o nowe lub oczekiwane informacje,

4 | S t r o n a

Wzór Projektu Funkcjonalnego

– powstawanie dodatkowych wymagań,– powstawanie nowych warunków.

Wprowadzanie w dokumencie funkcjonalnym zmian będzie realizowane przy pomocy funkcji śledzenia zmian dostępnej w aplikacji Microsoft Office Word. Wszystkie wprowadzone zmiany (nowe wersje dokumentu) będą każdorazowo przedkładane Zamawiającemu w celu ich akceptacji. Zatwierdzenie zmian w trybie śledzenia wykonywane będzie poprzez podmiot zarządzający dokumentem tylko po wcześniejszym uzgodnieniu danego zagadnienia i w komentarzach do dokumentu w wersji wcześniejszej.

Do weryfikacja zmian wprowadzanych w kolejnych wersjach dokumentu uprawnione będą obie strony i każda niejasność wynikająca ze zmian będzie wyjaśniana na poziomie kierownictwa projektu.

6 Wprowadzenie

Rozdział powinien zawierać wprowadzenie obejmujące opis celu projektu poprzez realizowane poprzez Rozwiązanie Wykonawcy. Dodatkowo rozdział musi zawierać informacje opisujące role i odpowiedzialności członków zespołu projektowego.

6.1 Cel projektu

Opis celu projektu.

6.2 Podział ról i odpowiedzialności w projekcie

Lista osób realizujących projekt wraz z opisem ról pełnionych w projekcie.

LP Zadanie/Zakres kompetencji WykonawcaZatwierdzający

i konsultant

5 | S t r o n a

Wzór Projektu Funkcjonalnego

7 Opis najistotniejszych elementów/komponentów Systemu

Rozdział powinien zawierać opis wdrażanego Rozwiązania z uwzględnieniem charakterystyki podstawowych elementów Systemu jego obiektów i realizowanych procesów. Opis powinien przedstawiać sposób realizacji wymagań funkcjonalnych oczekiwanych przez Zamawiającego (w szczególnych przypadkach powinien mieć odnośniki do opisu realizacji wymagań zawartych w rozdziale Opis wymagań funkcjonalnych systemu).

8 Wymagania funkcjonalne

Rozdział powinien zawierać opis wymagań funkcjonalnych, które Wykonawca przedstawił w ofercie. Opisy powinny być przedstawione tabelarycznie wszystkie wymagania zawarte w OPZ z uwzględnieniem numeru wymagania, opisu wymagania z OPZ oraz sposobu realizacji przedstawionej w ofercie. Wymagania muszą mieć odnośniki do opisów zawartych w Rozdziale 9.

W rozdziale 8 wymienione zostały wszystkie wymagania funkcjonalne wraz z opisem sposobu realizacji w formie i treści złożonej w ofercie. Sposób realizacji doprecyzowany o ustalenia poczynione podczas analizy został umieszczony w rozdziale 9.

9 Opis wymagań funkcjonalnych systemu

Sposób realizacji wymagań ujętych tabelą w OPZ - Rozdziale 8 został zmodyfikowany i uzupełniony o ustalenia poczynione na etapie analizy. Zawartość kolumny „Sposób realizacji” dla poszczególnych wymagań zawiera w tym rozdziale ogólny opis realizacji wymaganej funkcjonalności, przy czym opisy te zostały doprecyzowane względem analogicznych, zawartych w rozdziale 8.

Rozdział powinien zawierać szczegółowy opis sposobu realizacji wymagań funkcjonalnych przedstawionych w Rozdziale 8. Opisy powinny posiadać ustandaryzowane tabele dla opisu poszczególnych funkcjonalności (przykładowe tabele i rozdziały poniżej). Zamawiający dopuszcza grupowanie funkcjonalności jeżeli ma to uzasadnienie (każde grupowanie wymaga odrębnej zgody Zmawiającego).

9.1 Nazwa grupy wymagań

9.1.1 Nazwa podgrupy wymagań (Atrybuty)Opis cechy wspólnej danej grupy wymagań w odniesieniu do Systemu.

9.1.1.1 Kod funkcjonalności z OPZ Tabela z rozdziału 8 z funkcjonalnościami opisywanymi w danym rozdziale (w przypadku grupowania funkcjonalności w statusie powinno zostać podane uzasadnienie)

Nr Opis wymagania i referencja do SIWZ Opis wymagania szczegółowy Sposób realizacji

Kod z OPZ

9.1.1.1.1 Status

Funkcjonalność status Uwagi

Kod z OPZPropozycja/Uzgodniona

Np. kwestie otwarte, wprowadzone zmiany

6 | S t r o n a

Wzór Projektu Funkcjonalnego

9.1.1.1.2 Charakterystyka Atrybutu

Cecha Charakterystyka/opis AtrybutuNazwa Atrybutu w systemie Nazwa Atrybutu jaka będzie stosowana w Systemie.

Źródło pochodzeniaNazwa Systemu, procesu oraz zasady jeżeli dane mogą pochodzić z różnych źródeł.

WymagalnośćInformacja czy Atrybut musi mieć wartość oraz jak będzie System traktował brak wartości.

Typ atrybutu (A/B) Informacja o sposobie zarządzania zmianą wartości Atrybutu.Typ wartości Np. Słownikowa, oraz typ danejEdytowalny TAK/NIE (nie dotyczy SuperUżytkownika)Sposób wprowadzania Np. Wybór z listy rozwijanej

Przykładowa wartość AtrybutuPrzykładowa wartość Atrybutu dostępna w Systemie dla każdego parametru jeżeli Atrybut posiada więcej niż jeden parametr.

Tryb rejestracji zdarzeń dla Atrybutu

Informacje na jakich zasadach rejestrowane są zdarzenia dla danego Atrybutu oraz miejsce prezentacji historii zdarzeń.

Miejsce prezentacji w Systemie Opis lokalizacji Atrybutu w Systemie np. link/ścieżka.

Podlega filtrowaniuOpis cech szczególnych sposobu Filtrowania wartości Atrybutu i jego parametrów.

Kontrola uprawnieńTAK/NIE (czy System umożliwia kontrolę dostępu do danego Atrybutu: widoczność/edytowanie)

Widoczność Atrybutu Informacja w jaki sposób prezentowany jest Atrybut.Walidacja TAK/NIEPrzeznaczenie Atrybutu Opis roli jaką pełni Atrybut w Systemie.Procesy w systemie powiązane z Atrybutem

Lista procesów które wykorzystują wartość danego Atrybutu.

Parametry AtrybutuJeżeli Atrybut posiada więcej jak jeden parametr to powinna zostać dodane dodatkowa tabela opisująca parametry.

Wartość domyślna Atrybutu Wartość Atrybutu która będzie wprowadzana przez System domyślnie.

7 | S t r o n a

Wzór Projektu Funkcjonalnego

9.1.1.1.3 Źródło pochodzenia AtrybutuDokładny opis źródła pochodzenie danej, zasady zarządzania wartościami, stosowane wartości domyślne.

9.1.1.1.4 Definicja AtrybutuUzgodniony słownik wartości dla tego Atrybutu.

9.1.1.1.5 Reguły walidacyjne Jeżeli dla Atrybutu stosowane są reguły walidacyjne to szczegółowy opis tych reguł.

9.1.1.1.6 Scenariusze testoweLista scenariuszy i przypadków testowych jakie zostaną przypisane do opisywanej funkcjonalności.

9.1.1.1.7 Uwagi dodatkoweInformacje istotne które są specyficzne przy danej funkcjonalności a nie można ich opisać w tabelarycznie oraz uzgodnienia i uwagi, które dla danej funkcjonalności zostały zgłoszone.

9.1.2 Nazwa podgrupy wymagań (funkcjonalności)Opis cechy wspólnej danej grupy wymagań w odniesieniu do Systemu.

9.1.2.1 Kod funkcjonalności z OPZ Tabela z rozdziału 8 z funkcjonalnościami opisywanymi w danym rozdziale (w przypadku grupowania funkcjonalności w statusie powinno zostać podane uzasadnienie)

Nr Opis wymagania i referencja do OPZ Opis wymagania szczegółowy Sposób realizacji

Kod z OPZ

9.1.2.1.1 Status

Funkcjonalność status Uwagi

Kod z OPZ Propozycja/Uzgodniona Np. kwestie otwarte, wprowadzone zmiany

8 | S t r o n a

Wzór Projektu Funkcjonalnego

9.1.2.1.2 Charakterystyka sposobu realizacji

Zakres realizacji Opis

Charakterystyka sposobu realizacji

Opis szczegółowy realizacji danej funkcjonalności w Systemie. Opis musi zapewniać Zamawiającemu jednoznaczne zrozumienie sposobu realizacji wymaganej funkcjonalności w Systemie. W przypadku gdy do opisu niezbędne są rysunki to powinny zostać podane linki do rozdziału z rysunkami. Dopuszczalne jest wykorzystanie linków do opisów zawartych w rozdziale 7 zawierającym opis Systemu.

Wspierany proces

Spis procesów (linki do rozdziału z opisami procesów) w których dana funkcjonalność jest wykorzystywana.

Zakres wsparcia procesu Opis roli jaką dana funkcja pełni w procesach.

Wykorzystywane obiekty

Lista obiektów w Systemie które powiązane są z daną funkcjonalnością (linki do obiektów jeżeli zostały opisane w rozdziale 7 – opis Systemu).

Tryb procesu Automatyczny/Ręczny – wraz z opisem na jakich zasadach i jakie reguły.

Cechy szczególne procesu

Opis elementów istotnych dla danej funkcjonalności jaką pełni w realizacji procesów Systemu.

Elementy Automatyczne Systemu

Opis zakresu funkcjonalności realizowanej automatycznie przez System (bez udziału Użytkownika)

Elementy wymagające udziału Użytkownika

Opis roli Użytkownika oraz zakresu jego udziału w realizacji funkcjonalności.

Wymagane uprawnienia Użytkownika

Nazwa roli jaka jest przypisana do danej funkcjonalności oraz zasady zarządzania uprawnieniami do funkcjonalności jeżeli występują.

Reguły Walidacyjne

Lista reguł Walidacyjnych wykorzystywanych do realizacji funkcjonalności wraz z opisem szczególnych cech dla tej funkcjonalności.

Sytuacje Szczególne Opis wyjątków.

9 | S t r o n a

Wzór Projektu Funkcjonalnego

9.1.2.1.3 Scenariusze testoweLista scenariuszy i przypadków testowych jakie zostaną przypisane do opisywanej funkcjonalności.

9.1.2.1.4 Uwagi dodatkoweInformacje istotne, które są specyficzne przy danej funkcjonalności a nie można ich opisać w tabelarycznie oraz uzgodnienia i uwagi, które dla danej funkcjonalności zostały zgłoszone.

10 Procesy biznesowe

Rozdział powinien zawierać opis wszystkich procesów przedstawiony w formie diagramów BPMN wraz z opisem poszczególnych kroków. Zamodelowane powinny być całe procesy biznesowe, nie tylko części realizowane przez system. Poszczególne kroki w procesie powinny być oznaczone jako realizowane w systemie lub poza nim (manualnie, w innym narzędziu).

11 Przypadki użycia

Rozdział może zawierać przypadki użycia (wszystkie lub wybrane). Przypadki użycia należy opisać jeśli poprzednie rozdziały niewystarczająco precyzyjnie opisują Rozwiązanie.

Rozdział powinien zawierać diagram(y) obrazujące przypadki użycia powiązane relacjami zawierania i rozszerzania.

Następnie w podrozdziałach powinny znaleźć się poszczególne przypadki użycia.

Przypadek użycia powinien posiadać atrybuty:

Identyfikator Nazwa Opis wraz z ekranami, których dotyczy Aktorzy, Aktor inicjujący Przebieg główny Przebiegi alternatywne

Dodatkowo jeśli wnoszą istotne informacje powinny umieszczone być:

Przeprowadzane walidacje Warunki wejściowe Warunki wyjściowe Powiązania z innymi przypadkami użycia Używane obiekty biznesowe Szacowana częstość wywoływania

11.1 Aktorzy

Rozdział powinien zawierać listę i opis wszystkich aktorów wykorzystujących system (wewnętrznych i zewnętrznych). Każdy aktor występujący na diagramach/w opisach przypadków użycia powinien być tutaj opisany. Należy także odzwierciedlić relacje istniejące między aktorami.

12 Logiczny model danych

10 | S t r o n a

Wzór Projektu Funkcjonalnego

Rozdział powinien zawierać logiczny model danych, lub jego fragmenty. Logiczny model danych należy opisać, jeśli opisane w dokumencie zbiory atrybutów obiektów niewystarczająco precyzyjnie opisują Rozwiązanie.

Logiczny model danych musi być zamodelowany w narzędziu Enterprise Architect.

Poniżej podstawowe wytyczne nazewnictwa.class Zasady zarządzania modelem danych

Ogólne

+ Do tworzenia nazw obiektów, atrybutów i relacji wykorzystujemy jedynie pełne wyrazy języka polskiego, skróty są dozwolone jedynie w przypadku dlugich nazw własnych, które są ogólnie rozumiane (np. Składnik Majątku Trwałego - SMT).+ Nie ma żadnych ograniczeń na długość nazw obiektow, atrybutów i relacji.+ Wieloczłonowe nazwy muszą składać się z wyrazów oddzielonych spacjami, tylko pierwszy wyraz rozpoczyna się od wielkiej litery, pozostałe wyrazy rozpoczynają się od małych li ter, wyjątek stanowią nazwy własne.+ Do tworzenia nazw obiektów, atrybutów i relacji wykorzystujemy język polski.+ Do tworzenia nazw obiektów, atrybutów i relacji korzystamy jedynie z: małych i dużych li ter oraz spacj i, pozostałe znaki są niedozwolone.

(from Standardy nazewnictwa)

Poniżej przykład logicznego modelu danych.class Model logiczny IS-U, KE

Umowa

+ Numer umowy :long+ Dziedzina :Łańcuch krótki+ Status przetwarzania :Łańcuch krótki+ Grupa statystyczna dla umowy :Łańcuch krótki+ Jednostka gospodarcza :int+ Przyczyna blokowania rozliczenia :Łańcuch krótki+ Blokada faktury :Łańcuch krótki+ Data utworzenia :Data/Czas+ Data ostatniej zmiany :Data/Czas+ Data zawarcia umowy :Data/Czas+ Data rozwiązania umowy :Data/Czas+ Początek umowy :Data/Czas+ Koniec umowy :Data/Czas+ Liczba jednostek wypowiedzenia :int+ Czas wypowiedzenia :Łańcuch krótki+ Data złożenia wypowiedzenia :Data/Czas+ Data zgody RWE na odejście :Data/Czas+ Typ zużycia :Łańcuch krótki+ Typ umowy :Łańcuch krótki+ Przyczyna rozwiązania :Łańcuch krótki+ Zewnętrzny numer umowy :Łańcuch krótki

Konto umowy

+ Numer konta umowy :long+ Typ konta umowy :Łańcuch krótki+ Typ rozliczenia :Łańcuch krótki+ Klucz odsetek :Łańcuch krótki+ Cecha wyszukiwania konta :Łańcuch krótki+ Klasa konta :Łańcuch krótki+ Grupa rozliczeniowa :Łańcuch krótki+ Data utworzenia :Data/Czas+ Oznaczenie :Łańcuch krótki

«enumeration»Opiekun

Partner Handlowy

+ Numer PH :long+ Nazwa :Łańcuch średni+ Typ partnera handlowego :Łańcuch krótki+ NIP :long+ REGON :long+ PESEL :long+ Identyfikator VIP :Łańcuch krótki+ Forma prawna :Łańcuch krótki+ Płeć :Łańcuch krótki+ Data utworzenia :Data/Czas+ Segment :Łańcuch krótki+ Branża :Łańcuch krótki

Pozycja faktury

+ Numer pozycji :long+ Dziedzina :Łańcuch krótki+ Jednostka gospodarcza :Łańcuch krótki+ Operacja główna :Łańcuch krótki+ Rodzaj dokumentu :Łańcuch krótki+ Ważne od :Data/Czas+ Ważne do :Data/Czas+ Grupa statystyczna - i lość :Łańcuch krótki+ Grupa statystyczna - kwota :Łańcuch krótki+ Ilośc rozliczenia :double+ Jednostka miary rozliczenia :Łańcuch krótki+ Cena - kwota :double+ Kwota netto :double+ Udział czasu :int+ Typ czasu dla pozycji faktury :Łańcuch krótki

Adres

+ Typ adresu :Łańcuch krótki+ Ulica :Łańcuch krótki+ Numer domu :Łańcuch krótki+ Numer lokalu :Łańcuch krótki+ Dzielnica :Łańcuch krótki+ Kod pocztowy :Łańcuch krótki+ Miasto :Łańcuch krótki+ Województwo :Łańcuch krótki+ Kraj :Łańcuch krótki+ Telefon :Łańcuch krótki+ E-mail :Łańcuch krótki

Blokada (konta umowy)

+ Proces :Łańcuch krótki+ Typ blokady :Łańcuch krótki+ Ważna od :Data/Czas+ Ważna do :Data/Czas

Relacja PH

+ Typ relacji :Łańcuch krótki+ Ważna od :Data/Czas+ Ważna do :Data/Czas

+jest obsługiwany przez 0..1

+zajmuje się 1..*

+należy do

1

+posiada

1..*

+opisuje relacje PH

2

+występuje wrolach

0..*

+określona w

0..* +wskazuje na 1

+należy do 1

+posiada0..*

+składa się z0..*

+należy do 1

+posiada blokady

0..*

+zakłada blokadę na

1

13 Role i uprawnienia

11 | S t r o n a

Wzór Projektu Funkcjonalnego

Rozdział zawierający opis Ról i Uprawnień w Systemie. W szczególności lista uzgodnionych ról wraz z przypisanymi uprawnieniami, narzędzia do zarządzania rolami wraz z procedurami.

14 Reguły walidacji danych

Rozdział zawierający opis reguł Szacowania i Walidacje w Systemie w celu kontroli wartości Danych Pomiarowych oraz wartości Atrybutów związanych z obiektami rejestrowanymi w systemie. Opisy powinny zawierać sposoby konfiguracji reguł w Systemie w zakresie obejmującym wymagania opisane w OPZ.

15 Rysunki i schematy

Rozdział zawierający zestawienie zrzutów ekranu, rysunków i schematów związanych z poszczególnymi funkcjonalnościami opisanymi w niniejszym dokumencie. Rozdział powinien zawierać wszystkie rysunki i schematy do których dokumentacja się odwołuje, rysunki powinny być powiązane z treścią zawartą w dokumentacji.

16 Słowniki

Rozdział zawierający zestawienie słowników wartości m.in. dla Atrybutów i Danych Pomiarowych opisanych w niniejszym dokumencie.

17 Raporty

Rozdział powinien zawierać zestawienie raportów dostępnych w Systemie wraz z uzgodnionymi wzorami raportów które będą realizowały wymagania Zamawiającego. Rozdział powinien zawierać kompletną listę raportów opisanych w Rozdziale 9.

18 Lista kwestii otwartych

Rozdział powinien zawierać zebraną listę kwestii otwartych, które wymagają wyjaśnienia lub akceptacji ze strony kierownictwa projektu. Opisy powinny mieć link do szczegółowego opisu zawartego w dokumencie którego dotyczy zgłoszona kwestia otwarta.

Lp. Autor Opis Priorytet (Niski, Średni, Wysoki)

Status (Proponowane, Zatwierdzone, Odrzucone)

… …. …. …. ….

12 | S t r o n a

Wzór Projektu Funkcjonalnego

19 Załączniki

Rozdział powinien zawierać pełną listę załączników powiązanych z dokumentem, lista powinna być opisana w formie poniższej tabeli.

LP Dokument Opis

1 ……. ………

13 | S t r o n a