SPECYFIKACJA WYMAGAŃ

Transkrypt

1 SPECYFIKACJA WYMAGAŃ SWOP S PECYFIKAC JA W YM AGAŃ DLA SYSTEMU WSPOMAGANIA OPIEKI PRZEWLEKŁEJ WERSJ A 1.0 HISTORIA ZMIA N DOKUM ENT U Osoba Data Komentarz Wersja Mateusz Dudkowski r. Na podstawie znanej mi dokumentacji przybliżony wzorzec wygląd i jakość dokumentacji jakiej oczekujemy

2 SPECYFIKACJA WYMAGAŃ SWOP 1 SPIS T REŚCI 1. Wprowadzenie Cel dokumentu Przyjęte zasady w dokumencie Zakres produktu Literatura Opis ogólny Perspektywa produktu Funkcje produktu Ograniczenia... 9 Zgodność z aktami prawnymi... 9 Zgodność ze standardami i normami... 9 System zarządzania bazą danych... 9 Ograniczenia sprzętowe... 9 Protokoły komunikacyjne instalacja oprogramowania Interfejsy programistyczne Dokumentacja użytkownika Założenia i zależności Założenia Zależności Model procesów biznesowych Aktorzy i charakterystyka użytkowników Obiekty MEDYCZNE i BIZnesowe Procesy medyczne i biznesowe Wymagania funkcjonalne Wprowadzanie danych do systemu Opis i priorytet Przypadki użycia Reakcja lekarza na wyniki pacjenta Opis i priorytet Przypadki użycia Charakterystyka interfejsów Interfejs użytkownika... 27

3 SPECYFIKACJA WYMAGAŃ SWOP 2 6. Inne wymagania Dodatek A: Słownik pojęć i terminów... 30

4 SPECYFIKACJA WYMAGAŃ SWOP 3 1. WPROWADZENIE 1.1. CEL DOKUMENTU W dokumencie, który stanowi załącznik do dokumentacji przetargowej, przedstawiono wymagania dla systemu wspomagania opieki przewlekłej. Dokument przeznaczony jest głównie dla przedstawicieli wytwórców oprogramowania (uczestników procesu przetargowego), oraz dla pracowników szpitali miejskich PRZYJĘTE ZASADY W DOKUMENCIE Śledzenie zmian dokumentu: Historia zmian dokumentu znajduje się w tabeli na 2 stronie specyfikacji. Historia zmian przedstawiona jest w odwrotnym do chronologicznego porządku (ostatnie zmiany, góra tabelki). Odnośniki w tekście: W tekście wymagań zostaną umieszczone odwołania do opisu struktur danych, innych wymagań, przypadków użycia itd. Tekst odwołania zostanie wyróżnione kursywą np. teczka, PSK_UC1. W wersji elektroniczne istnieje możliwość bezpośredniego przejścia do wskazywanego elementu. Opis modułu funkcjonalnego: Opis poszczególnych modułów funkcjonalnych będzie składał się z trzech podrozdziałów: Opis i priorytet modułu, Przypadki użycia lista przypadków użycia poprzedzona diagramem przypadków użycia prezentującym zależności pomiędzy przypadkami użycia danego modułu (oraz ich powiązania z przypadkami użycia pochodzącymi z innych modułów), Specyficzne wymagania funkcjonalne wymagania w postaci tekstowej uzupełniające wymagania w postaci przypadków użycia. Opis wymagań dokumentacji użytkownika: Wymagania odnośnie dokumentacji użytkownika (rozdział 2.4), będą prezentowane według wzoru umieszczonego poniżej. Nazwa: Opis zawartości: Standard: Format: Język: <nazwa dokumentu> <opis zawartości dokumentu (np. spis treści)> <lista standardów, z którymi ma być zgodna dokumentacja> <format na przykład elektroniczny oraz tekstowy> <język, w jakim ma zostać przygotowana dokumentacja> Opis aktorów: Charakterystyka poszczególnych aktorów przedstawiona w rozdziale 3.1, będzie umieszczona w następującej tabeli: <identyfikator> Nazwa: <nazwa aktora> <opis aktora>

5 SPECYFIKACJA WYMAGAŃ SWOP 4 Obiekty medyczne i biznesowe: Charakterystyka poszczególnych obiektów biznesowych przedstawionych w rozdziale 3.2, będzie umieszczona w następującej tabeli: Nazwa: <nazwa obiektu medyczne i biznesowego> <opis obiektu medycznego i biznesowego> Reguły biznesowe: Reguły biznesowe (rozdział 3.4) będą opisywane według następującego wzoru: ID Definicja reguły Typ Zmienność Źródło <fakt, ograniczenie, <id> <treść reguły> <na jakiej pod- <dynamiczna, wyzwalacz, stawie zdefiniowano regułę> statyczna> wniosek, obliczenia> Przypadki użycia: Do opisu przypadków użycia będą wykorzystywane trzy rodzaje tabel przedstawionych poniżej. <identyfikator> Nazwa: <nazwa przypadku biznesowego> Aktorzy główni: <lista aktorów> Aktorzy pomocniczy: <lista aktorów> Poziom: <Biznesowy, Użytkownika, Podfunkcji> <opis przypadku użycia> Wyzwalacze: 1. <lista wyzwalaczy powodujących rozpoczęcie realizacji przypadku użycia> Warunki początkowe: 1. <lista warunków, które powinny być spełnione podczas uruchomiania przypadku użycia> Warunki końcowe: 1. <lista warunków, które powinny być prawdziwe po zakończeniu realizacji przypadku użycia> Dokumenty wejściowe: 1. <lista dokumentów, które są dostępne przed rozpoczęciem procesu> Dokumenty wyjściowe: 1. <lista dokumentów, które powstają w wyniku realizacji procesu> Prolog: 1. <sekwencja kroków obrazująca czynności poprzedzające wykonanie procesu biznesowego> Scenariusz Główny: 1. <najbardziej typowy scenariusza osiągnięcia celu> Scenariusze alternatywne i rozszerzenia: <alternatywne scenariusze osiągnięcia celu> Wyjątki: <opis sytuacji wyjątkowych i ich obsługi>

6 SPECYFIKACJA WYMAGAŃ SWOP 5 Dodatkowe wymagania: <dodatkowe wymagania dotyczące przypadku użycia> <identyfikator> Nazwa: <nazwa przypadku użycia> Aktorzy główni: <lista aktorów> Aktorzy pomocniczy: <lista aktorów> Poziom: <Biznesowy, Użytkownika, Podfunkcji> Priorytet: <priorytet> <opis przypadku użycia> Wyzwalacze: 1. <lista wyzwalaczy powodujących rozpoczęcie realizacji przypadku użycia> Warunki początkowe: 1. <lista warunków, które powinny być spełnione podczas uruchomiania przypadku użycia> Warunki końcowe: 1. <lista warunków, które powinny być prawdziwe po zakończeniu realizacji przypadku użycia> Scenariusz Główny: 1. <najbardziej typowy scenariusza osiągnięcia celu> Scenariusze alternatywne i rozszerzenia: <alternatywne scenariusze osiągnięcia celu> Wyjątki: <opis sytuacji wyjątkowych i ich obsługi> Dodatkowe wymagania: <dodatkowe wymagania dotyczące przypadku użycia> <identyfikator> Nazwa: <nazwa przypadku użycia> Aktorzy główni: <lista aktorów> Aktorzy pomocniczy: <lista aktorów> Poziom: <Biznesowy, Użytkownika, Podfunkcji> Priorytet: <priorytet> <opis przypadku użycia> Wyzwalacze: 1. <lista wyzwalaczy powodujących rozpoczęcie realizacji przypadku użycia> Warunki początkowe: 1. <lista warunków, które powinny być spełnione podczas uruchomiania przypadku użycia> Warunki końcowe: 1. <lista warunków, które powinny być prawdziwe po zakończeniu realizacji przypadku użycia> Scenariusz Główny: 1. <najbardziej typowy scenariusza osiągnięcia celu> Scenariusze alternatywne: <alternatywne scenariusze osiągnięcia celu>

7 SPECYFIKACJA WYMAGAŃ SWOP 6 Rozszerzenia: <scenariusze rozszerzające> Wyjątki: <opis sytuacji wyjątkowych i ich obsługi> Dodatkowe wymagania: <dodatkowe wymagania dotyczące przypadku użycia> <identyfikator> Nazwa: <nazwa przypadku użycia> Aktorzy główni: <lista aktorów> Aktorzy pomocniczy: <lista aktorów> Poziom: <Biznesowy, Użytkownika, Podfunkcji> Poziom: <opis przypadku użycia> Dodatkowe wymagania: <dodatkowe wymagania dotyczące przypadku użycia> <Biznesowy, Podfunkcji> Użytkownika, Specyficzne wymagania funkcjonalne Dodatkowe wymagania funkcjonalne zostaną opisane z wykorzystaniem tabeli przedstawionej poniżej. ID Wymaganie Priorytet <id> <treść reguły> <priorytet> Wymagania pozafunkcjonale: Poszczególne wymagania pozafunkcjonalne będą zapisane przy użycia wzorca umieszczonego poniżej. <identyfikator> Nazwa: Priorytet: <nazwa wymagania pozafunkcjonalnego> <priorytet wymagania> <pełna treść wymagania> 1.3. ZAKRES PRODUKTU Celem przedsięwzięcia jest zbudowanie informatycznego Systemu Wspomagającego Opieki Przewlekłej, służącego do monitorowania przebiegu chorób przewlekłych pacjentów. Aplikacja końcowa jest przeznaczona dla pacjentów ze schorzeniami przewlekłymi, u których wskazane jest regularne monitorowanie nasilenia dolegliwości i samodzielne wykonanie podstawowych pomiarów diagnostycznych w celu określenia stopnia opanowania objawów choroby i dostosowania intensywności leczenia. Tworzony system ma za zadanie ułatwić diagnozę i leczenie pacjentów z przewlekłymi chorobami.

8 SPECYFIKACJA WYMAGAŃ SWOP LITERATURA 1. Ustawa z dnia 17 lutego 2005 r. o informatyzacji działalności podmiotów realizujących zadania publiczne (Dz.U nr 64 poz. 565). 2. Rozporządzenie Prezesa Rady Ministrów z dnia 11 października 2005 r. w sprawie minimalnych wymagań dla systemów informatycznych (Dz. U. z dnia 28 października 2005 r.). 3. Rozporządzenie Prezesa Rady Ministrów z dnia 29 września 2005 r. w sprawie warunków organizacyjno - technicznych dostarczania dokumentów elektronicznych podmiotom publicznym (Dz. U ). 4. Rozporządzenie Prezesa Rady Ministrów z dnia 22 grudnia 1999 r. w sprawie instrukcji kancelaryjnej dla organów gmin i związków międzygminnych, (Dz. U. Nr 112, poz. 1319) 5. Ustawa z dnia 29 sierpnia 1997 o ochronie danych osobowych (Dz. U nr 133 poz. 883 z późn. zm.). 6. IEEE Standard for Software User Documentation, IEEE Std , ISO/IEC 9126: Information technology - Software Product Evaluation - Quality characteristics and guidelines for their use. International Organization for Standardization,

9 SPECYFIKACJA WYMAGAŃ SWOP 8 2. OPIS OGÓLNY 2.1. PERSPEKTYWA PRODUKTU System SWOP funkcjonował będzie, jako niezależne oprogramowanie służące do nadzorowania stanu zdrowia pacjentów. Diagram kontekstu przedstawiony na rysunku 1, przedstawia podstawowych aktorów prowadzących interakcję z system SWOP oraz zestaw danych, które są przez nich przetwarzane. Aplikacja końcowa powinna udostępnić pacjentowi interfejs umożliwiający wprowadzanie wyników samodzielnie prowadzonych obserwacji i pomiarów. Jeśli to będzie uzasadnione aplikacja powinna się opierać na wykorzystaniu mobilnych urządzeń pomiarowych i dostępowych, aby jak najmniej ograniczać swobodę pacjenta. Dla pacjentów przebywających głównie w domu aplikacja powinna pracować w oparciu o urządzenie zbierającego dane z urządzeń pomiarowych i sensorycznych właściwych dla konkretnego pacjenta. Jeśli pacjent będzie widział taką potrzebę, jego dane gromadzone w systemie będą mogły być udostępnione lekarzowi sprawującemu nad nim przewlekłą opiekę lub też lekarzowi udzielającemu mu pomocy doraźnej lub krótkoterminowej. Dokładny opis funkcji i użytkowników aplikacji końcowej zależy od wymagań użytkownika końcowego oraz od podmiotu oferującego usługę telemonitorowanie docelowej populacji chorych. RYSUNEK 1 DIAGRAM KONTEKSTU DLA SWOP

10 SPECYFIKACJA WYMAGAŃ SWOP FUNKCJE PRODUKTU Podstawowy zakres funkcjonalności Systemu obejmował będzie monitorowanie stanu zdrowia pacjentów. Dane o stanie zdrowia pacjenta będą wprowadzane bezpośrednio przez pacjenta lub importowane z urządzeń pomiarowych będących zawsze w pobliżu pacjenta komunikujących się za pośrednictwem protokołów Bluetooth. Stan zdrowia pacjenta będzie monitorowany i w razie konieczności system wyśle odpowiednie komunikaty do lekarza, Call Center, rodziny pacjenta. System będzie umożliwiał przesyłanie informacji o stanie zdrowia pacjenta oraz wskazówek do postępowania w celu leczenia OGRANICZENIA ZGODNOŚĆ Z AKTAMI PRAWNYMI Tworzony system SWOP musi być zgodny z zapisami zawartymi w ustawach i rozporządzeniach [1, 2, 3, 4, 5, 6, 7]. ZGODNOŚĆ ZE STANDARDAMI I NORMAMI Dokumentacja użytkownika powinna być zgodna ze standardem IEEE [8]. SYSTEM ZARZĄDZANIA BAZĄ DANYCH SWOP musi wykorzystywać posiadany przez Zamawiającego SZBD Oracle Enterprise Edition, zainstalowany na tej samej macierzy dyskowej, na której będzie zainstalowany SWOP. Możliwie do wykorzystania wersje SZBD Oracle to: 8.1.7, 9i oraz 10g. Zamawiający posiada wykupioną aktualną usługę ATiK. SZBD posiadany przez zamawiającego nie zawiera żadnej z opcji dodatkowych tj. partycjonowanie, RAC, serwer aplikacji. Jest on licencjonowany w modelu procesorowym (pozwala to korzystać z niego nieograniczonej liczbie użytkowników). Uzasadnienie: Zamawiający posiada licencje na wymienione wersje SZBD Oracle, których wykorzystanie pozwoli obniżyć koszt Systemu. OGRANICZENIA SPRZĘTOWE Macierz dyskowa: Oprogramowanie tworzące SWOP musi zostać zainstalowane na macierzy dyskowej SAN IBM DS4300 z możliwością uruchomienia na dowolnym z dwóch serwerów (na wypadek awarii jednego z nich) firmy IBM pseries p5 570 pracujących pod kontrolą systemu operacyjnego AIX v.5.3. i połączonych z w/w macierzą dyskową. Uzasadnienie: Zamawiający posiada przedstawioną macierz, co pozwoli obniżyć koszt Systemu. Infrastruktura sieciowa: SWOP musi poprawnie funkcjonować w ramach istniejącej infrastruktury sieciowej Zamawiającego zlokalizowanej w wielu budynkach, połączonych łączami o przepustowości min. 10Mb/s i funkcjonujących w oparciu o sieć POZMAN Poznańskiego Centrum Superkomputerowo- Sieciowego. Kręgosłup sieci w ramach poszczególnych budynków jest zrealizowany w technologii gigabitowego Ethernetu w topologii gwiazdy z wykorzystaniem przełączników firmy 3COM. Medium transmisyjne stanowi skrętka nieekranowana zapewniająca parametry transmisyjne

11 SPECYFIKACJA WYMAGAŃ SWOP 10 min. 5 kategorii. W każdym budynku zlokalizowany jest minimum jeden serwer plików (Novell Netware 5.1). Odseparowanie od sieci Internet Posiadana przez Zamawiającego sieć, w obrębie której będzie funkcjonowało SWOP, jest fizycznie odseparowana od sieci Internet. W efekcie oprogramowanie tworzące SWOP musi poprawnie funkcjonować pomimo odseparowania od sieci Internet (m.in. obsługiwać wszystkie czynności związane z procesem weryfikacji bezpiecznego podpisu elektronicznego). Stacja robocza: SWOP musi spełniać wszystkie wymagania określone w specyfikacji, będąc obsługiwany przez użytkowników korzystających z komputerów klasy IBM PC o minimalnej konfiguracji: Procesor: Pamięć RAM: Karta sieciowa: Dostępna przestrzeń dyskowa: System operacyjny: Przeglądarka internetowa: AMD Athlon 1,6 GHz 256 MB 10/100 Mb/s 2 GB Windows XP Professional Netscape 7.x; Mozilla 1.6; Firefox 1.x, 2.x; IE 5.x, 6.0, 7.x; Konfiguracja sprzętowa serwera: Wszystkie komponenty wchodzące w skład systemu SWOP muszą spełniać wymagania określone w specyfikacji mając przydzielone następuje zasoby sprzętowe serwera w zależności od liczby równoległych sesji użytkowników w systemie (U): U <= 125 Procesor: Pamięć RAM: Karta sieciowa: Dysk: 1x RISC 64-bit Power GHz 2 GB 1x wirtualny interfejs sieciowy Ethernet 1Gb/s Zbiór dysków twardych o łącznej pojemności 2TB pracujących w mirroringu (osobne 2TB) w technologii 2Gb/s Fibre Channel 125 < U <= 250 Procesor: Pamięć RAM: Karta sieciowa: Dysk: 2x RISC 64-bit Power GHz 4 GB 1x wirtualny interfejs sieciowy Ethernet 1Gb/s Zbiór dysków twardych o łącznej pojemności 2TB pracujących w mirroringu (osobne 2TB) w technologii 2Gb/s Fibre Channel 250 < U <= 375 Procesor: Pamięć RAM: Karta sieciowa: 3x RISC 64-bit Power GHz 6 GB 1x wirtualny interfejs sieciowy Ethernet 1Gb/s

12 SPECYFIKACJA WYMAGAŃ SWOP 11 Dysk: Zbiór dysków twardych o łącznej pojemności 2TB pracujących w mirroringu (osobne 2TB) w technologii 2Gb/s Fibre Channel 375 < U <= 500 Procesor: Pamięć RAM: Karta sieciowa: Dysk: 4x RISC 64-bit Power GHz 8 GB 1x wirtualny interfejs sieciowy Ethernet 1Gb/s Zbiór dysków twardych o łącznej pojemności 2TB pracujących w mirroringu (osobne 2TB) w technologii 2Gb/s Fibre Channel Uzasadnienie: Zamawiający posiada infrastrukturę serwerową o podanej konfiguracji. Konfiguracja w zależności od liczby użytkowników została ustalona na podstawie doświadczeń z podobnym systemem, który rozwijany jest od ponad 10 lat i w chwili obecnej ma około 1500 jednoczesnych użytkowników. PROTOKOŁY KOMUNIKACYJNE Protokoły komunikacyjne zgodne z rozporządzeniem Prezesa Rady Ministrów z dnia 11 października 2005 r. w sprawie minimalnych wymagań dla systemów informatycznych [3]. INSTALACJA OPROGRAMOWANIA Użytkownicy będący administratorami powinni korzystać z SWOP za pośrednictwem przeglądarki internetowej, urządzeń mobilnych lub komputerów. Aplikacja udostępniająca funkcje administracyjne może być oparta zarówno o przeglądarkę internetową, jak i może mieć postać aplikacji dedykowanej instalowanej w systemie operacyjnym lub urządzeniu mobilnym. Uzasadnienie: Na komputerach, urządzeniach mobilnych użytkowników nieposiadających uprawnień administratora nie istnieje możliwość instalacji dodatkowego oprogramowanie. Dodatkowe oprogramowanie może zostać zainstalowane na stacjach roboczych obsługiwanych przez administratorów systemu. INTERFEJSY PROGRAMISTYCZNE SWOP musi udostępniać zdalne API umożliwiające w przyszłości integrację SWOP w trybie online, bez konieczności zakupu dodatkowego oprogramowania narzędziowego, z aplikacjami wykonanymi w technologii Lotus Notes 2.4. DOKUMENTACJA UŻYTKOWNIKA Dokumentacja powinna obejmować następujące pozycje: Nazwa: Podręcznik użytkownika (User Guide) Opis zawartości: Przewodnik opisujący sposób użycia poszczególnych funkcji SWOP. Standard: IEEE [8] drukowany postać książki; dla każdej grupa użytkowników (administratorzy, czytelnicy) powinna zostać stworzona osobna wersja dokumentacji, Format: zawierające opis dostępnych funkcji, elektroniczny

13 SPECYFIKACJA WYMAGAŃ SWOP 12 Język: polski o elektroniczna wersja postaci książkowej, o dokumentacja kontekstowa wbudowana w system, będąca integralną częścią systemu ADE. Nazwa: Przewodnik (Reference Guide) Opis zawartościrametry konfiguracyjne. Przewodnik opisujący poszczególne formatki, raporty, strukturę menu, oraz pa- Standard: IEEE [8] drukowany postać książki, elektroniczny Format: o elektroniczna wersja postaci książkowej, o dokumentacja kontekstowa wbudowana w system, będąca integralną częścią systemu ADE. Język: polski Nazwa: Standard: Format: Język: Dokumentacja techniczna Dokument opisujący budowę systemu (jego podstawowe komponenty), sposób instalacji i konfiguracji oraz instrukcje odnośnie obsługi (konserwacji) systemu w trakcie działania. drukowany postać książki, elektroniczny - elektroniczna wersja postaci książkowej. polski Opis zawartości: Nazwa: Opis zawartości: Standard: Format: Język: Dokumentacja API Opis funkcji API udostępnianych przez system SWOP, oraz instrukcje jak z nich skorzystać (wzbogacone o przykłady). drukowany postać książki, elektroniczny - elektroniczna wersja postaci książkowej. polski 2.5. ZAŁOŻENIA I ZALEŻNOŚCI ZAŁOŻENIA Platforma sprzętowa Zamawiający posiada infrastrukturę sprzętową opisaną w rozdziale 2.3. Zakłada się, że platforma ta jest wystarczająca do funkcjonowania systemu SWOP. Dostępne oprogramowanie SWOP może wykorzystywać posiadany przez Zamawiającego system Lotus Domino w wersji Zamawiający posiada 1300 licencji klienckich Lotus Notes w wersji Na stacjach roboczych jest zainstalowana przynajmniej jedna z przeglądarek internetowych: Netscape 7.x; Mozilla 1.6; Firefox 1.x, 2.x;

14 SPECYFIKACJA WYMAGAŃ SWOP 13 IE 5.x, 6.0, 7.x; Na stacjach roboczych zainstalowana jest przeglądarka plików PDF Acrobat Reader w jednej z wersji: 4.x, 5.x, 6.x. ZALEŻNOŚCI Brak

15 SPECYFIKACJA WYMAGAŃ SWOP MODEL PROCESÓW BIZNESOWYCH 3.1. AKTORZY I CHARAKTERYSTYKA UŻYTKOWNIKÓW AKT_PACJ Nazwa: Pacjent Pacjent to osoba chorująca przewlekle. Pacjenci mogą wprowadzać do systemu dane o swoim stanie zdrowia manualnie lub automatycznie z wykorzystaniem urządzeń pomiarowych obdarzonych w protokoły komunikacyjne. Do pacjentów będą kierowane informacje o sposobie postępowania przy leczeniu przesyłane przez lekarzy lub Call Center. Pacjenci o silnej demencji będą mogli mieć zainstalowany odbiornik GPS, który pozwoli na łatwe ich namierzenie. AKT_RODZ_PACJ Nazwa: Rodzina pacjenta Rodzina pacjenta to osoby spokrewnione lub spowinowacone z pacjentem. Mają wgląd do danych odnośnie stanu zdrowia pacjenta oraz możliwość zareagowania wysłaniem komunikatu lub zadzwonieniem do Call Center lub do lekarza. Mogą oni również sprawdzać położenie pacjentów z odbiornikami GPS oraz podejmować decyzje o sposobie leczenia w przypadku pacjentów niezdolnych do podejmowania samodzielnych decyzji. AKT_LEK Nazwa: Lekarz Lekarz to osoba o doświadczeniu medycznym, która jest odpowiedzialna za metody leczenia pacjenta. Ma możliwość sprawdzenia stanu zdrowia pacjenta z wprowadzonych danych przez pacjenta lub przez urządzenia monitorujące. Jest on również powiadamiany przez System SWOP, rodzinę lub Call Center o sytuacjach kryzysowych wynikających ze złych wyników zdrowia pacjenta. AKT_CALL_CENT Nazwa: Call Center Call Center to jednostka odpowiedzialna za odpowiadanie na pytania o sposób działania systemu, reagująca na podane informacje od pacjenta lub rodziny. Informuje również lekarza o potrzebie wizyty u pacjenta oraz spełnia rolę informacyjną dla pozostałych użytkowników systemu.

16 SPECYFIKACJA WYMAGAŃ SWOP 15 AKT_FIRM_SPEC_IT Nazwa: Firmy IT Firmy IT i specjaliści IT to firmy oraz osoby, które chcą budować inne systemy, np. monitoringu w oparciu o system SWOT. Mają oni dostęp do Call Center oraz do danych informacyjnych o sposobie działania systemu. Nie mają dostępu do danych o pacjencie. AKT_ADMN Nazwa: Administrator Osoba odpowiedzialna za zarządzanie systemem od strony technicznej. Ma dostęp do wszystkich elementów systemu, jednakże nie może udostępniać danych osobowych pacjenta osobom trzecim. Każdy aktor ma różny dostęp do systemu. Nikt, poza administratorami, nie ma pełnego dostępu do systemu, nie wolno im jednak udostępniać osobom trzecim danych pacjentów oraz lekarzy, czyli danych wprowadzanych do systemu. Firmy IT i specjaliści mają jedynie dostęp do informacji o sposobie działania systemu. Rodzina pacjenta może wykorzystywać funkcjonalność systemu do obserwacji oraz reagowania na stan zdrowia chorego. Call Center pełni ważną rolę informowania zainteresowanych o stanie zdrowia, przekazywaniu informacji od innych użytkowników systemu i reagowania na alerty systemowe. Większość użytkowników nie musi posiadać specjalnej wiedzy informatycznej, wystarczy znajomość podstaw obsługi urządzeń mobilnych oraz komputerów. Wyjątek stanowią Call Center i administratorzy OBIEKTY MEDYCZNE I BIZNESOWE Poniżej przedstawione zostały ogólne informacje na temat najważniejszych obiektów medycznych i biznesowych. Nazwa: Wyniki Wyniki to zbiór danych z urządzeń pomiarowych wprowadzanych do systemu przez pacjenta lub bezpośrednio przez urządzenie. Nazwa: Informacje o chorobie Informacje przesyłane do pacjenta lub rodziny o danej chorobie. Nazwa: Informacje o sposobie leczenia Informacje od lekarza o sposobie leczenia oraz rozszerzenie informacji o chorobie przewlekłej.

17 SPECYFIKACJA WYMAGAŃ SWOP 16 Nazwa: Informacje biznesowe Informacje o sposobie działania systemu potrzebne do budowania aplikacji końcowych opartych o system SWOP PROCESY MEDYCZNE I BIZNESOWE MB01 Nazwa: Pomiar stanu zdrowia pacjenta Aktorzy główni: Pacjent, Urządzenia pomiarowe Aktorzy pomocniczy: Rodzina pacjenta Poziom: Medyczny Pacjent pobrał dane z urządzeń pomiarowych i jest gotów wprowadzić je do systemu. Wyzwalacze: 1. Upłynął ustalony okres czasu pomiaru stanu zdrowia pacjenta. Warunki początkowe: Warunki końcowe: Dane wejściowe: 1. Wyniki badań z urządzeń. Dane wyjściowe: 1. Elektroniczny zapis danych zapisane w standardzie DICOM. Prolog: 1. Urządzenia pomiarowe badają stan zdrowia pacjenta. Scenariusz Główny: 1. Pacjent wprowadza dane za pomocą interfejsu na urządzeniu mobilnym lub PC systemu SWOP. Scenariusze alternatywne i rozszerzenia: 1.A. Dane wprowadzane przez innego aktora. 1.A.1. Dane wprowadzane przez rodzinę pacjenta za pomocą interfejsu systemu SWOP.. 1.A.2. Dane wprowadzane automatycznie poprzez urządzenia pomiarowe. 1.A.4. Koniec przypadku użycia. Wyjątki: Urządzenia medyczne mogą nie być sprawne. Pacjent niepoprawnie wprowadzi dane. Dodatkowe wymagania: MB02 Nazwa: Rejestracja pacjenta w systemie SWOP Aktorzy główni: Pacjent Aktorzy pomocniczy: Administrator systemu SWOP, rodzina Pacjenta Poziom: Biznesowy

18 SPECYFIKACJA WYMAGAŃ SWOP 17 Pacjent/rodzina pacjenta dobrowolnie przystępuje do rejestracji w systemie SWOP. Wyzwalacze: 1. Pacjent/rodzina pacjenta chce się zarejestrować w systemie SWOP. Warunki początkowe: Poinformowanie zainteresowanych o sposobie działania systemu. Warunki końcowe: Zarejestrowanie pacjenta. Dokumenty wejściowe: Dokumenty wyjściowe: Prolog: 1. Poinformowanie pacjenta i zainteresowanych o sposobie działania systemu. Scenariusz Główny: 1. Podanie dokładnych danych pozwalających na identyfikację pacjenta oraz komunikację alternatywnymi kanałami obejmującymi, poza platformą SWOP; pocztę internetową, telefon komórkowy lub stacjonarny oraz kontakt do członków rodziny lub opiekunów formalnych pozostających w stałych relacjach z pacjentem 2. Wypełnienie ankiety pozwalającej określić wstępnie stadium zaawansowania choroby lub stopień jej ciężkości (jeśli w przypadku konkretnego problemu medycznego występującego u pacjenta, taka ocena jest możliwa i dostępne są odpowiednie narzędzia) 3. Wybór opcji korzystania z systemu oferowanych w ramach wybranego przez pacjenta wariantu abonamentu, np. kontakt na telefon komórkowy w razie stwierdzenia zaostrzenia choroby, powiadomienie lekarza prowadzącego o zapytaniu wysłanym przez pacjenta, etc. 4. Wybór trybu monitorowania system automatycznie proponuje tryb monitorowania dostosowany do stanu pacjenta ocenianego na podstawie ankiety wypełnionej przez pacjenta, jednak pacjent nie musi zaakceptować tego trybu i wybrać inny tryb związany np. z rzadszym wprowadzaniem danych do systemu 5. Podanie danych kontaktowych do pracowników ochrony zdrowia i opiekunów formalnych oraz nieformalnych, stanowiących potencjalnych współpracowników mogących korzystać z systemu SWOP w celu oferowania wsparcia dla pacjenta, np. do lekarza prowadzącego, najbliższego członka rodziny przyjmującego powiadomienia o zagrożeniu zaostrzeniem choroby lub opiekuna formalnego sprawującego nad pacjentem codzienna opiekę. Scenariusze alternatywne i rozszerzenia: 1. Po zarejestrowaniu pacjent zostaje przeszkolony w zakresie użycia systemu oraz korzystania z urządzeniem pomiarowych i/lub monitorujących wypożyczonych w ramach umowy z firmą oferującą usługę SWOP. 2. W przypadku osób niepełnoletnich bądź niezdolnych do podejmowania własnych decyzji rejestrację mogą przeprowadzić opiekunowie lub rodzina chorego. Wyjątki: Nie można zarejestrować pacjenta bez jego lub jego opiekuna/rodziny zgody i wiedzy. Dodatkowe wymagania: Zgoda na rejestrację.

19 SPECYFIKACJA WYMAGAŃ SWOP WYMAGANIA FUNKCJONALNE 4.1. WPROWADZANIE DANYCH DO SYSTEMU Opis i priorytet Moduł zawiera funkcjonalność pozwalającą na wprowadzanie danych poprzez interfejs użytkownika lub bezpośrednio z urządzeń pomiarowych. Dodatkowo możliwe jest zlokalizowanie położenia pacjenta za pomocą współrzędnych urządzenia GPS. Priorytet: Wysoki Przypadki użycia RYSUNEK 2 DIAGRAM PRZYPADKÓW UŻYCIA DLA MODUŁU WDDS

20 SPECYFIKACJA WYMAGAŃ SWOP 19 WDDS_UC1 Nazwa: Wprowadź dane od użytkownika (pacjenta) Aktorzy główni: Pacjent Aktorzy pomocniczy: Poziom: Użytkownika Priorytet: Wysoki Pacjent wprowadza dane do systemu za pomocą interfejsu użytkownika lub dane są wprowadzane automatycznie za pomocą urządzeń pomiarowych. Wyzwalacze: 1. Upłynął okres przeznaczony na pomiar stanu zdrowia pacjenta. Warunki początkowe: 1. Pacjent jest zarejestrowany w systemie. 2. Urządzenia pomiarowe są sprawne. Warunki końcowe: Scenariusz Główny: 1. Pacjent wprowadza dane do systemu sczytując je z urządzeń pomiarowych. 2. Za pomocą interfejsu logowania podaje swoje dane. 3. Pacjent za pomocą interfejsu odpowiedzialnego za pobranie od użytkownika danych pomiarowych wprowadza do systemu dane. 4. Dane zostają zapisane w systemie. Scenariusze alternatywne i rozszerzenia: 1.A. Pacjent podaje dane nieprawidłowe. 1.A.1. Administrator/lekarz/system wysyła komunikat o błędnych danych do pacjenta. 1.A.2. Pacjent ponownie wprowadza dane (tym razem poprawnie). 1.A.3. Jeśli ponownie wprowadzone dane są niepoprawne, administrator systemu/lekarz/call center kontaktują się z pacjentem osobiście i szkolą go w zakresie poprawnego wprowadzania danych. Wyjątki: 1.A. Pacjent jest pozbawiony dostępu do systemu. 1.A.1. Lekarz/Call center może wprowadzić dane telefonicznie podane od pacjenta. 1.A.2. Koniec przypadku użycia. 1.A. Pacjent jest nieprzytomny. 1.A.1. Rodzina/Call Center/Lekarz mogą zlokalizować pacjenta podpiętego pod system GPS lub próbować skontaktować się z nim za pomocą telefonu, osobiście bądź w inny dostępny sposób. 1.A.2. Przejdź do kroku 4. Dodatkowe wymagania: Wprowadzenie danych powinno być kompletne. WDDS_UC2 Nazwa: Wprowadź dane z urządzeń pomiarowych użytkownika (pacjenta) Aktorzy główni: Pacjent Aktorzy pomocniczy: Urządzenia pomiarowe Poziom: Użytkownika Priorytet: Wysoki Dane do systemu są wprowadzane automatycznie w cyklicznie powtarzającym się odstępie czasu.

21 SPECYFIKACJA WYMAGAŃ SWOP 20 Wyzwalacze: 1. Upłynął okres przeznaczony na pomiar stanu zdrowia pacjenta. Warunki początkowe: 1. Pacjent jest zarejestrowany w systemie. 2. Urządzenia pomiarowe są sprawne. Warunki końcowe: Scenariusz Główny: 1. Urządzenia wprowadzają dane do systemu. 2. Za pomocą interfejsów komunikacyjnych nawiązywana jest łączność z systemem. 3. Dane zostają zapisane w systemie. Scenariusze alternatywne i rozszerzenia: Wyjątki: 1.A. Urządzenia są niesprawne. 1.A.1.System automatycznie wykryje błąd spowodowany nieprawidłową pracą urządzeń pomiarowych i wystosuje odpowiedni komunikat do administratora systemu. 1.A.2. Koniec przypadku użycia. Dodatkowe wymagania: Wprowadzenie danych powinno być kompletne. WDDS_UC3 Nazwa: Pobierz współrzędne pacjenta (GPS) Aktorzy główni: Pacjent, Aktorzy pomocniczy: Urządzenie GPS Poziom: Podfunkcji Priorytet: Wysoki Pobieranie współrzędnych z urządzenia GPS podpiętego do pacjenta. Wyzwalacze: 1. Zgłoszenie chęci zlokalizowania pacjenta przez rodzinę lub lekarza (WDDS_UC5). Warunki początkowe: 1. Wyrażenie zgody rodziny chorego lub samego pacjenta na uaktywnienie usługi geolokalizacyjnej. Warunki końcowe: 1. Scenariusz Główny: 1. Pobranie współrzędnych geograficznych z urządzenia pacjenta. 2. Przesłanie ich do systemu za pomocą interfejsów komunikacyjnych urządzenia pomiarowego. 3. Lokalizacja na podstawie zwróconych danych. Scenariusze alternatywne i rozszerzenia: 5.A. Urządzenie jest niesprawne/wyłączone lub nie ma dostępu do sieci. 5.A.1. System może zlokalizować ostatnio przesłaną informację o położeniu. 5.A.2. Rozpoczynane są poszukiwania pacjenta. Wyjątki: Brak zgody na usługi geolokalizacyjne. Dodatkowe wymagania: o Weryfikacja możliwości rzeczywistego położenia pacjenta.

22 SPECYFIKACJA WYMAGAŃ SWOP 21 WDDS_UC4 (specjalizacja WDDS_UC1) Nazwa: Dodaj wyniki pacjenta do systemu Aktorzy główni: Pacjent Aktorzy pomocniczy: Poziom: Użytkownika Priorytet: Wysoki Dodanie wyników, uprzednio wprowadzonych, do systemu. Dodatkowe wymagania: WDDS_UC5 (specjalizacja WDDS_UC3) Nazwa: Zlokalizuj pacjenta Aktorzy główni: Rodzina, lekarz Aktorzy pomocniczy: Poziom: Zewnętrzny Priorytet: Wysoki Zgłoszenie przez Rodzinę lub Lekarza żądanie zlokalizowania pacjenta za pomocą systemu GPS Wyzwalacze: 1. Pacjent nie odpowiada telefonicznie. Rodzina lub Lekarz zaczynają się martwić. Warunki początkowe: 1. Pacjent musi mieć przy sobie urządzenie namierzające GPS 2. Pacjent musi wyrazić zgodę na geolokalizację. Warunki końcowe: Scenariusz Główny: 1. Rodzina zgłasza chęć zlokalizowania Pacjenta. 2. System pobiera współrzędne z odbiornika GPS Pacjenta. 3. System zwraca wynik zainteresowanym. Scenariusze alternatywne i rozszerzenia: Wyjątki: Dodatkowe wymagania:

23 SPECYFIKACJA WYMAGAŃ SWOP REAKCJA LEKARZA NA WYNIKI PACJENTA Opis i priorytet Moduł zawiera funkcjonalność pozwalającą na reakcję lekarza na wprowadzone do systemu wyniki pacjenta lub na wezwanie rodziny lub Call Center. Lekarz może udzielić pacjentowi niezbędnych informacji lub pojechać do niego z wizytą. Priorytet: Wysoki Przypadki użycia RLNWP_UC1 RYSUNEK 3 DIAGRAM PRZYPADKÓW UŻYCIA DLA MODUŁU RLNWP Nazwa: Pobierz dane od Pacjenta Aktorzy główni: Pacjent Aktorzy pomocniczy: Poziom: Systemu Priorytet: Wysoki Pacjent poprzez interfejs użytkownika wprowadza dane do systemu. Następnie są one przetwarzane przez System. Wyzwalacze: 1. Pacjent wprowadza dane do systemu. 2. System je interpretuje. 3. System po zweryfikowaniu danych przekazuje je dalej. Warunki początkowe: 1. Pacjent jest zarejestrowany w Systemie. Warunki końcowe:

24 SPECYFIKACJA WYMAGAŃ SWOP Wprowadzenie wyników do Systemu. Scenariusz Główny: 1. Pacjent wprowadza dane do Systemu za pomocą interfejsu użytkownika. 2. Dane są odbierane przez System. Scenariusze alternatywne i rozszerzenia: 1.A.Dane są niekompletne/niepoprawne. 1.A.1. System prosi o ponowne podanie poprawnych danych. 2.A.Dane z urządzeń pomiarowych są niekompletne/niepoprawne. 1.A.1. System prosi o ponowne przesłanie danych. 1.A.2. Jeśli dane są niepoprawne przejdź do kroku 3. 1.A.3. System rozpoznaje usterkę urządzeń. 1.A.4. System informuje Pacjenta, Lekarza i Administratora o uszkodzonych urządzeniach pomiarowych. Wyjątki: Dodatkowe wymagania: RLNWP_UC2 Nazwa: Odbierz zgłoszenie o problemie od Rodziny Aktorzy główni: Rodzina Pacjenta Aktorzy pomocniczy: Poziom: Systemu Priorytet: Wysoki Rodzina Pacjenta zgłasza problem za pomocą interfejsu Systemu. System odbiera zgłoszenie i je interpretuje. Wyzwalacze: 1. Rodzina Pacjenta zgłasza problem. Warunki początkowe: Rodzina zarejestrowana w Systemie. Warunki końcowe: 1. Wprowadzone zgłoszenie do Systemu. Scenariusz Główny: 1. Rodzina zgłasza problem. 2. System odbiera zgłoszenie. 3. System je przetwarza. Scenariusze alternatywne i rozszerzenia: Wyjątki: Dodatkowe wymagania:

25 SPECYFIKACJA WYMAGAŃ SWOP 24 RLNWP_UC3 (specjalizacja RLNWP_UC1) Nazwa: Wezwij lekarza Aktorzy główni: Lekarz, Call Center Aktorzy pomocniczy: Brak Poziom: Użytkownika Priorytet: Wysoki Call Center ma możliwość wezwania lekarza na podstawie pobranych od niego wyników lub zgłoszenia Rodziny Pacjenta. Wyzwalacze: 1. Złe wyniki pacjenta. 2. Wezwanie Rodziny Pacjenta. Warunki początkowe: 1. Pacjent i Rodzina zarejestrowani w Systemie. Warunki końcowe: Scenariusz Główny: 1. System intepretując wyniki pacjenta przesyła informację do Call Center. 2. Call Center interpretuje wyniki Pacjenta oraz komunikaty Systemu. 3. Call Center za pomocą interfejsu Systemu wzywa lekarza. 4. Lekarz odbiera wezwanie od Call Center. 5. Call Center zawiadamia Pacjenta/Rodzinę o toku postępowania. 6. Scenariusze alternatywne i rozszerzenia: 1.A. Nie jest wymagane wezwanie Lekarza tylko uzyskanie informacji o toku postępowania w przypadku Pacjenta. 1.A.1. Call Center prosi o radę Lekarza. 1.A.2. Lekarz udziela porad o sposobie leczenia/postępowania w stosunku do Pacjenta i Rodziny. 1.A.3. Call Center komunikuje się ponownie z Rodziną i lub Pacjentem przekazując im odpowiednie wskazówki od Lekarza. 2.A. Wyniki pobrane od Pacjenta kwalifikują go do zabrania do szpitala. 3.A.1. System zgłasza problem do Call Center. 3.A.2. Call Center wzywa pogotowie. 3.A.3. Call Center informuje Lekarza o problemie. 3.A.4. Call Center przekazuje informacje pomocnicze do Rodziny Pacjenta i informuje o toku postępowania. Wyjątki: 1. Brak wolnych Lekarzy. 2. Rodzina/Pacjent nalegają na wizytę, choć System zgłasza podstaw do wezwania Lekarza na podstawie wyników. Dodatkowe wymagania: 1. Lekarz zarejestrowany w Systemie. 2. Rodzina zarejestrowani w Systemie. 3. Pacjent zarejestrowany w Systemie.

26 SPECYFIKACJA WYMAGAŃ SWOP 25 RLNWP_UC4 (specjalizacja RLNWP_UC2) Nazwa: Przekaż zgłoszenie od Rodziny Aktorzy główni: Rodzina Pacjenta Aktorzy pomocniczy: Brak Poziom: Systemowy Priorytet: Wysoki System przekazuje uprzednio przesłane przez Rodzinę Pacjenta zgłoszenie, po ówczesnej interpretacji. Wyzwalacze: 1. Zgłoszenie wykonane przez Rodzinę Pacjenta. 2. Wezwanie Rodziny Pacjenta. Warunki początkowe: 1. Rodzina zarejestrowana w Systemie. Warunki końcowe: 1. Odebranie zgłoszenia przez Call Center. Scenariusz Główny: 1. System intepretując zgłoszenie Rodziny pacjenta przesyła informację do Call Center. 2. Call Center odbiera zgłoszenie. Scenariusze alternatywne i rozszerzenia: Wyjątki: Dodatkowe wymagania: RLNWP_UC5 (specjalizacja RLNWP_UC3) Nazwa: Wezwij lekarza Aktorzy główni: Lekarz, Call Center, Pacjent Aktorzy pomocniczy: Rodzina Pacjenta Poziom: Użytkownika Priorytet: Wysoki Call Center po zinterpretowaniu zgłoszenia o problemie od Rodziny Pacjenta lub od Pacjenta wzywa Lekarza. Wyzwalacze: 1. Zły stan chorego 2. Złe wyniki Pacjenta 3. Ważny powód wezwania od Rodziny 4. Konieczna wizyta lekarska Warunki początkowe: 1. Pacjent zarejestrowany w Systemie. 2. Rodzina zarejestrowana w Systemie. Warunki końcowe: 1. Przybycie Lekarza. 2. Poinstruowanie Rodziny/ Pacjenta o toku postępowania. 3. Odbyta wizyta

27 SPECYFIKACJA WYMAGAŃ SWOP 26 Scenariusz Główny: 1. Call Center na podstawie zgłoszenia przyjętego od Rodziny Pacjenta lub od niego samego informuje Lekarza o sytuacji. 2. Lekarz na podstawie wyników badań oraz treści zgłoszenia i informacji uzyskanych o Call Center decyduje o dalszym postępowaniu. 3. Lekarz wysyła do Call Center instrukcje dla Rodziny/Pacjenta o sposobie postępowania w danym przypadku. 4. Lekarz informuje System o chęci odbycia wizyty. 5. Lekarz pobiera z systemu wszelkie potrzebne dane: a) Dane osobowe Pacjenta b) Adres zamieszkania Pacjenta c) Wyniki badań 6. Lekarz jedzie do chorego. Scenariusze alternatywne i rozszerzenia: 1.A. Nie jest wymagana wizyta Lekarza tylko uzyskanie informacji o toku postępowania w przypadku Pacjenta. 1.A.1. Call Center prosi o radę Lekarza. 1.A.2. Lekarz udziela porad o sposobie leczenia/postępowania w stosunku do Pacjenta i Rodziny. 1.A.3. Call Center komunikuje się ponownie z Rodziną i lub Pacjentem przekazując im odpowiednie wskazówki od Lekarza. 2.A. Wyniki pobrane od Pacjenta kwalifikują go do zabrania do szpitala. 2.A.1. System zgłasza problem do Call Center. 2.A.2. Call Center wzywa pogotowie. 2.A.3. Call Center informuje Lekarza o problemie. 2.A.4. Call Center przekazuje informacje pomocnicze do Rodziny Pacjenta i informuje o toku postępowania. Wyjątki: 1. Brak wolnych Lekarzy. 2. Rodzina/Pacjent nalegają na wizytę, choć System zgłasza podstaw do wezwania Lekarza na podstawie wyników. Dodatkowe wymagania: 1. Lekarz zarejestrowany w Systemie. 2. Rodzina zarejestrowani w Systemie. 3. Pacjent zarejestrowany w Systemie.

28 SPECYFIKACJA WYMAGAŃ SWOP CHARAKTERYSTYKA INTERFEJSÓW 5.1. INTERFEJS UŻYTKOWNIKA Zgodnie z założeniami, System SWOP musi posiadać przyjazny i łatwy w obsłudze Interfejs Użytkownika. Musi być on intuicyjny i jednolity dla wszystkich urządzeń obsługujących System (urządzenia mobilne, komputery stacjonarne, laptopy). Poniżej zamieszczony został Graficzny Interfejs Użytkownika przestawiający ekran do wprowadzania większości danych od użytkowników Systemu. Większość interfejsów jest niemal identyczna, tzn. GUI jest bardzo uwzględniając nieznaczące zmiany, tak aby każdy użytkownik rozpoznawał elementy Systemu. Funkcje graficznego interfejsu użytkownika (okno do pobierania wyników od Pacjenta oraz zgłoszeń od Rodziny): ID Wymaganie Priorytet GUI1 System musi zapewniać konieczność wprowadzania tytułu zgłoszenia. Niski GUI2 Interfejs musi wymagać określenia priorytetu zgłoszenia (1 wysoki priorytet, 5 niski) Średni GUI3 Interfejs musi mieć możliwość wyboru do kogo ma być adresowane zgłoszenie z dostępnej listy wyboru (Rodzina, Pacjent, Call Center, Lekarz Wysoki etc.) GUI4 W oknie do pobierania zgłoszeń/wyników musi być dostępne pole tekstowe służące do opisu danego zgłoszenia. Użytkownik wprowadza w nim treść wezwania/ zgłsozenia. Średni

29 SPECYFIKACJA WYMAGAŃ SWOP 28 ID Wymaganie Priorytet GUI5 Za pomocą Radio Button użytkownik ma możliwość wyboru typu zgłoszenia. Dostępne są trzy do wyboru: Pomoc Wyniki badań Prośba o informację Wysoki GUI6 Użytkownik musi zaakceptować Regulamin przed wysłaniem zgłoszenia za pomocą CheckBox a. Wysoki Wymagania odnośnie interfejsu użytkownika: ID Wymaganie Priorytet IU1 System musi zapewniać polskojęzyczny interfejs użytkownika, oraz umożliwiać wprowadzanie danych w języku polskim. Wysoki IU2 SWOP musi posiadać przyjazny i łatwy w obsłudze interfejs użytkownika. Średni IU3 Dostęp do funkcji systemu będzie możliwy z wykorzystaniem skrótów klawiaturowych. Średni IU5 Średni czas wprowadzenia pojedynczych wyników do Systemu przez użytkownika będzie nie większy niż 30 sekund x liczba pól metadanych wyników. Weryfikacja zostanie przeprowadzona na 10 losowo wybranych użytkownikach systemu (po przejściu 8h szkolenia) i 20 losowo wybranych dokumentach o liczbie pól metadanych od 5 do 20. Wysoki

30 SPECYFIKACJA WYMAGAŃ SWOP INNE WYMAGANIA Nie zdefiniowano.

31 SPECYFIKACJA WYMAGAŃ SWOP 30 DODATEK A: SŁOWNIK POJĘĆ I TERMINÓW Niniejsza specyfikacja wymaga, aby użyte terminy posiadały ściśle zdefiniowane znaczenie. Gdziekolwiek jest to możliwe, definicje pokrywają się z powszechnym znaczeniem terminów bądź ich rozumieniem w medycynie. Lekarz, Pacjent, Call Center i inni użytkownicy Systemu zostali opisani w Rozdziale 3. Niektóre ważne terminy zostały zdefiniowane poniżej. SWOP Skrót od System Wspomagania Opieki Przewlekłej. Jest to zbiór aplikacji i potrzebnych urządzeń do prawidłowego funkcjonowania podstawowej wersji Systemu. Stan zdrowia Jest to ocena prawidłowego funkcjonowania organizmu Pacjenta oparta na wynikach badań. W przypadku Systemu, użytkownicy określani mianem Pacjenta chorują na choroby przewlekłe. Diagram przepływu danych (diagram kontekstowy) Diagram przepływu danych (DPD lub z ang. DFD - Data Flow Diagram) - graficzna prezentacja przepływu danych w procesie. Na proces składają się następujące elementy: Funkcje (procesy) realizują określone cele; jeśli funkcji nie można rozbić na podfunkcje, wówczas nosi ona nazwę elementarnej. Magazyny danych trwałe lub tymczasowe składnice danych, które są argumentami dla funkcji. Terminatory obiekty, które nie są częścią systemu, ale stanowią odbiorców bądź źródła danych lub argumentów funkcji. Przepływy elementy pokazujące kierunek przesyłu danych (np. bajtów, znaków, pakietów..). DFD obrazuje za pomocą przepływów kierunek przepływu danych pomiędzy funkcjami, magazynami i obiektami zewnętrznymi. DFD mogą być prezentowane na różnych stopniach szczegółowości, mówimy o: 1. Diagramach kontekstowych, które pokazują granice systemu, źródła i odbiorców danych oraz główne wejścia i wyjścia systemu. Aktor Opis ról użytkowników w Systemie. Podstawowi aktorzy w SWOP to: Pacjent Rodzina Pacjenta

32 SPECYFIKACJA WYMAGAŃ SWOP 31 Lekarz Call Center Firmy IT/Specjaliści IT Aktor w języku UML (UML) oznacza użytkownika lub zewnętrzny system, z którymi modelowany system wchodzi w interakcje Aplikacja mobilna Ogólna nazwa dla oprogramowania działającego na urządzeniach przenośnych, takich jak telefony komórkowe, smartfony, palmtopy czy tablety, które pisane są przy użyciu różnych platform i języków programowania. Do tej pory większość z nich pisana jest w technologii Java ME. Przykładem zastosowania aplikacji mobilnych jest tzw. "Bankowość mobilna", która ułatwia klientom dostęp do konta bankowego z możliwością dokonywania operacji bankowych. Interfejs użytkownika W technice część urządzenia odpowiedzialna za interakcję z użytkownikiem. Człowiek nie jest zdolny do bezpośredniej komunikacji z maszynami. Aby było to możliwe urządzenia są wyposażone w odpowiednie urządzenia wejścia-wyjścia tworzące razem interfejs użytkownika. Graficzny interfejs użytkownika (ang. Graphical User Interface, GUI) Często nazywany też środowiskiem graficznym ogólne określenie sposobu prezentacji informacji przez komputer oraz interakcji z użytkownikiem, polegające na rysowaniu i obsługiwaniu widżetów. Urządzenia pomiarowe Urządzenia pozwalające na odczyt parametrów biomedycznych opisujących stan zdrowia Pacjenta. Niektóre wyposażone są w protokoły komunikacyjny w celu bezprzewodowego przesłania wyników do Systemu. Bluetooth Technologia bezprzewodowej komunikacji krótkiego zasięgu pomiędzy różnymi urządzeniami elektronicznymi, takimi jak klawiatura, komputer, laptop, palmtop, telefon komórkowy i wieloma innymi. Global Positioning System (GPS) Właściwie GPS-NAVSTAR (ang. Global Positioning System NAVigation Signal Timing And Ranging) jeden z systemów nawigacji satelitarnej, stworzony przez Departament Obrony Stanów Zjednoczonych, obejmujący swoim zasięgiem całą kulę ziemską. System składa się z trzech seg-

33 SPECYFIKACJA WYMAGAŃ SWOP 32 mentów: segmentu kosmicznego - 31 satelitów orbitujących wokół Ziemi na średniej orbicie okołoziemskiej; segmentu naziemnego - stacji kontrolnych i monitorujących na ziemi oraz segmentu użytkownika - odbiorników sygnału. Zadaniem systemu jest dostarczenie użytkownikowi informacji o jego położeniu oraz ułatwienie nawigacji po terenie. Geolokalizacja Położenie oraz proces określania geograficznego położenia fizycznych przedmiotów lub osób typowo za pomocą GPS, bądź adresu IP urządzenia. Położenie zwykle określane jest poprzez współrzędne geograficzne, ale także innego rodzaju dane adresowe (kod pocztowy, miasto, ulica i numer domu). Geolokalizacja jest ściśle powiązana z pozycjonowaniem, jak czasem nazywany jest proces ustalania samych współrzędnych geograficznych. Osoba trzecia Często wymieniana w aktach prawnych, to każda osoba fizyczna, osoba prawna bądź też jednostka organizacyjna nieposiadająca osobowości prawnej, której nie dotyczy dana umowa, stosunek prawny czy też inna, skonkretyzowana przepisami, relacja. Przypadek użycia Tworzenie przypadków użycia (ang. use case) technika stosowana w inżynierii oprogramowania w celu opisania wymagań tworzonego systemu informatycznego. Przypadek użycia przedstawia interakcję pomiędzy aktorem (użytkownikiem systemu), który inicjuje zdarzenie oraz samym systemem jako sekwencję prostych kroków. Scenariusz przypadków użycia Tekstowy opis kroków (ciągu zdarzeń), które składają się na dany przypadek sekwencja zdarzeń w systemie oraz opis interakcji użytkownika (obiektu zewnętrznego) z systemem. W projektowaniu systemów informatycznych (pt. widzenia użytkownika, w szczególności klienta) Posiada trzy rodzaje przebiegów (główne, alternatywne, wyjątkowe)