Use Case-modell. Vurdering av oppdragsgivers krav

Transkript

1 Use Case-modell Vurdering av oppdragsgivers krav Kravspesifikasjonen presiserer at brukergrensesnittet skal være grafisk, menybasert, ha støtte for bruk av mus og ha et intuitivt utseende, slik at enhver bruker enkelt finner fram. Det kreves også at dybden i menyene ikke overstiger tre nivåer, og at det ikke kreves mer enn to menyvalg for å kunne endre data i systemet. Hurtigtaster må også implementeres, slik at erfarne brukere lett får tilgang til ofte brukte funksjoner. Brukerne har også uttrykt at de skal kunne bruke systemet til å generere en rekke rapporter etter behov. Systemet skal også ha predefinerte standardrapporter. Dette ser vi for oss at kan oppfylles ved bruk av swing-biblioteket i java, som gir oss muligheten til å lage et typisk vindusgrensesnitt. Menyer, støtte for mus og hurtigtaster er enkelt å implementere med dette biblioteket. Det vil være hensiktsmessig å involvere brukerne i designet av brukergrensesnittet, for eksempel ved å lage en prototype som vi kan få tilbakemeldinger på.

2 Overordnet Use Case-diagram

3 spesifikasjon Beskrivelse Eksempler Resepsjonist Resepsjonister tar seg av alle administrative oppgaver i systemet, og har høyeste adgangsrettigheter. Registrerer pasienter og personale, behandler inn- og utsjekking av pasienter, oppretter operasjoner. Beskrivelse Eksempler Doktor Doktorer behandler pasienter og har hovedansvar for operasjoner. Skriver pasienrapporter, sjekker tidsplan Beskrivelse Eksempler Helsesøster Helsesøstere har ansvar for alle pasienter i sin avdeling, samt assistering av doktorer ved operasjoner. Sjekker tidsplan Beskrivelse Eksempler Ansatt Dette er en samlet aktør for de tre overnevnte aktørene: Resepsjonist, doktor og helsesøster. Leser rapporter

4 Administrer person Resepsjonist Endring i ansatt-/pasientforhold Systemet må ha nok om ansatt til å gjøre endringer Endringer har blitt lagret 1. Resepsjonist spør om om ansatt eller pasient fra systemet. 2. Systemet gir om person. 3. Resepsjonisten sender endret om personen til systemet. 4. Systemet validerer endringene. 5. Systemet oppdateres. 6. Systemet bekrefter endring. 2a) Ufullstendig forespørsel Systemet ber resepsjonist om å spesifisere forespørsel. 2b) Personen finnes ikke i systemet Systemet ber resepsjonist om å endre forespørsel. 4a) Ufullstendig endring Systemet ber resepsjonist om å fylle ut manglende informsjon. Denne use-casen innebefatter oppretting, endring og sletting av ansatt eller pasient.

5 Administrer operasjon Resepsjonist Pasient i venteliste skal gis operasjon eller resepsjonist vil endre data om en eksisterende operasjon. Nok ledige ressurser til å utføre operasjon. Pasient på venteliste. Operasjon har blitt opprettet eller oppdatert. 1. Resepsjonist ber om å hente pasient fra venteliste. 2. Systemet returnerer pasientbeskrivelse. 3. Resepsjonist spør systemet om ledige ressurser i et oppgitt tidsrom. 4. Systemet oppgir ledige ressurser. 5. Resepsjonist tildeler ressurser til operasjonen. 6. Systemet validerer om operasjon. 7. Systemet oppdateres. 8. Systemet bekrefter oppdateringen. 2a) Pasienten er ikke i ventelista. Systemet returnerer feilmelding. 4a) Ikke nok ledige, nødvendige ressurser i oppgitt tidsrom. Systemet ber resepsjonist om å endre tidsrom. 6a) Resepsjonisten har ikke oppgitt alle nødvendige ressurser. Systemet ber om manglende opplysninger. Denne use-casen tar for seg oppretting og endring av en operasjon. Systemet har ansvaret for å finne ledige ressurser (doktor, operasjonsrom osv.) i et tidsrom som resepsjonisten bestemmer.

6 Administrer venteliste Resepsjonist Pasient skal legges inn på venteliste eller pasient skal fjernes fra lista. Pasient finnes i systemet. Pasient har blitt lagt til eller fjernet fra ventelista. 1. Resepsjonist ber om om pasient fra systemet eller ventelista. 2. Systemet returnerer om pasient. 3. Resepsjonist legger til eller fjerner pasienten fra ventelista. 4. Systemet validerer endring. 5. Systemet oppdateres. 6. Systemet bekrefter endringen. 7. 2a) Pasient finnes ikke i systemet eller ventelista. Systemet gir feilmelding og spør på nytt. 4a) Ugyldig operasjon (f.eks. fjerne pasient fra venteliste som ikke ligger der på forhånd). Systemet gir feilmelding. Denne use-casen dekker både innlegging av pasienter som skal opereres i venteliste, samt fjerning av pasienter som har fått operasjon fra lista..

7 Administrer avdeling Resepsjonist Endring av materielle ressurser ved avdeling. Systemet må ha nok om avdeling til å gjøre endringer Systemet har lagret endringene 1. Resepsjonist ber om avdelings fra systemet. 2. Systemet returnerer avdelings. 3. Resepsjonist sender endringer til systemet. 4. Systemet validerer endringen. 5. Systemet oppdateres. 6. Systemet bekrefter endringen. 2a) Avdeling finnes ikke i systemet. Systemet spør etter nytt avdelingsnummer. 4a) Ugyldig endring Systemet ber om manglende. Denne use-casen tar for seg endringer innad i avdelingene, slik som anskaffelse eller fjerning av senger, oppretting av nye rom og lignende.

8 Oppdater pasientrapport Doktor Doktor behandler pasient og vil oppdatere pasientrapporten. Pasient finnes i systemet og behandles av gjeldende doktor. Pasientrapporten har blitt oppdatert. 1. Doktor ber om pasientrapport fra systemet. 2. Systemet returnerer pasientrapport. 3. Doktor sender oppdatert pasientrapport til systemet. 4. Systemet bekrefter endringer. 5. Systemet oppdateres. 2a) Pasienten finnes ikke i systemet Systemet ber om ny pasient. 2b) Doktoren behandler ikke gjeldende pasient Systemet gir feilmelding, og doktoren får ikke tilgang til rapporten. Denne use-casen tar for seg tilfellet der en doktor vil oppdatere historien/journalen til en pasient.

9 Administrer pasient Resepsjonist Pasienten skal plasseres (innsjekking) eller omplasseres. Pasienten finnes i systemet. Pasienten har blitt plassert eller bedt om å vente dersom det ikke er ledige senger eller rom. 1. Resepsjonist spør systemet om pasient. 2. Systemet returnerer. 3. Resepsjonisten spør systemet om ledig seng i en gitt avdeling. 4. Systemet returnerer ledige senger. 5. Resepsjonist sender forespørsel til systemet om å reservere valgt seng. 6. Systemet bekrefter endringen. 7. Systemet oppdateres. 2a) Pasienten finnes ikke i systemet. Systemet spør på nytt. 4a) Ingen ledige senger i avdeling. Systemet gir beskjed om at alle sengene er opptatt, og avbryter operasjonen. Denne use-casen tar for seg innsjekking og flytting av pasienter. Resepsjonisten velger avdeling, deretter finner systemet alt som er ledig av senger i de ulike rommene.

10 Hent rapport Ansatt Ansatt ønsker fra systemet. Systemet må inneholde nok til å generere valgt rapport. Valgt rapport har blitt generert. 1. Ansatt sender forespørsel om ønsket rapport til systemet. 2. Systemet leverer rapport. 2a) Ansatt har ikke tilstrekkelige rettigheter til å kunne få valgt rapport. Systemet avbryter operasjonen. 2b) Systemet har ikke nok til å generere valgt rapport. Systemet gir feilmelding og avbryter. Denne use-casen tar for seg generering av en valgfri rapport, for eksempel tidsplan eller ledige senger i en avdeling.

11 Domenemodell

12 Systemets ikke-funksjonelle krav Et av hovedkravene til systemet vårt er at det skal gjøre administrasjonen av sykehuset enklere. Dette innebærer at mye data som er nødvendig for driften kun er tilgjengelig gjennom dette systemet. Systemet må derfor være svært pålitelig, og vi har satt en målsetning om oppetid på 99 %. Hvis systemet er nede, må ansatte ved sykehuset kunne aksessere data på via backup, slik at driften av viktige områder (for eksempel operasjoner) kan gå som normalt. Systemet skal brukes av mange personer med ulik erfaring med data. Noen skal bruke systemet ofte, mens andre skal benytte det i liten grad. Brukergrensesnittet må derfor være intuitivt og enkelt å bruke for alle, samtidig som ofte brukte funksjoner er lett tilgjengelige (ved bruk av tastekombinasjoner) for de som bruker systemet ofte. Systemet inneholder sensitiv om pasienter. Denne en må krypteres slik at uvedkommende ikke får adgang til disse. Brukere skal ha forskjellig rettighetsnivå i systemet. Systemet bør ikke overstige en responstid på fem sekunder.