Kravspesifikasjon gruppe 42 Nils-Kristian Liborg (brukergrensesnitt), Bente Brevig (beskrivelser, aktørbeskrivelser, diagram, kvalitetssikring), Tom Olav Bruaas (beskrivelser), Eirik Lied (beskrivelser, diagram, domenemodellen) og Hege Lid Pedersen (dokumentasjon) 4. oktober 2002
Innhold Introduksjon til kravspesifikasjonen 3. Forandringer i leveranse 2..................... 3.2 UseCase-del.............................. 3.2. UseCasediagram....................... 3.2.2 Aktørbeskrivelser...................... 4.2.3 UseCase-beskrivelser.................... 5.3 Beskrivelse av ikke-funksjonelle krav.............. 2.4 Tekniske konsekvenser av gitte krav.............. 2.5 Domenemodell............................ 3 2 Brukergrensesnitt 4 2
Introduksjon til kravspesifikasjonen Dette dokument bygger på en ufullstendig kravspesifikasjon gitt av oppdragsgiver. Hver leveranse er en utvidelse og/eller oppdatering av den forrige. Det som eventuelt er oppdatert vil være nøye beskrevet under hver leveransedel.. Forandringer i leveranse 2.okt: Vi har oppdatert en del av usecase-beskrivelsene. Da spesielt pre- og postbetingelsene. I tillegg er domenemodellen forfinet - ledd i leveranse 3. Brukergrensesnittet har fått en bedre beskrivelse..2 UseCase-del.2. UseCasediagram Lege Sykepleier Skriv ut pasient Modifiser pasient informasjon Modifiser venteliste informasjon include Beregn venteliste Vis venteliste Skriv inn pasient Vis pasient s timeplan Vis pasient informasjon Vis legens pasienter Vis lege s månedlige timeplan Vis sykepleier s månedlige timeplan List sykepleiere Vis avdeling informasjon Vis senge informasjon Vis ledige senger extend Opprett modifiser eller fjern avdeling Opprett pasient Vis sykepleier informasjon Opprett modifiser eller fjern seng Opprett modifiser eller fjern sykepleier Modifiser personell til operasjon Vis lege informasjon Alloker personell til operasjon include Bestill operasjon Opprett modifiser eller fjern lege Admin Figur : UseCase-diagram 3
.2.2 Aktørbeskrivelser En del av usecasene vil ha flere aktører siden det er nødvendig for flere å få tak i den samme informasjonen. En lege vil ha kompetanse til å gjøre alt det en sykepleier gjør. Derfor vil leger ha tilgang til sykepleieroppgaver. Men en sykepleier skal ikke ha tilgang til å gjøre alle legens oppgaver. F.eks Skriv ut pasient. Admin-aktøren har ansvaret for en del administrative ting, og disse sammenfaller ofte med leger og sykepleiers oppgaver. Dette begrunner hvorfor alle aktørene ofte har tilgang til se samme usecasene. Sykepleier Beskrivelse: Sykepleieren har omsorg for pasienten. En sykepleier er også med under en operasjon. De utfører ordrer fra legene. Eksempler: Sykepleier assisterer lege under opersajon. Sykepleier noterer pasientens vekt i journalen. Lege Beskrivelse: Legen har det totale overordnede ansvaret for pasienten. Legen er den som rekvirerer rett behandling mot pasientens sykdom. Legen kan også selv behandle pasientens sykdom. Eksempler: Legen opererer pasienten. Legen dikterer sykejournal og innkomst. ADMIN - administrator Beskrivelse: Admin er en ansatt med ansvar for adminstrasjon og drift av sykehuset. Dette kan være en lege, sykepleier eller en annen ansatt som har utvidet tilgang på systemet. Eksempler: Avdelingssykepleier (sjef for sykepleierene på én avdeling) ansetter en ny sykepleier og legger inn personlige opplysninger i datasystemet. En avdelingsoverlege bestiller operasjon på en av avdelingens pasienter. 4
.2.3 UseCase-beskrivelser Skriv inn pasient Lege, Sykepleier, Admin Pasient skal legges inn på sykehuset Informasjon om pasienten ligger lagret i datasystemet og pasienten har status som inneliggende. Normalt hendelsesflyt:. Systemet ber om -sifret fødselsnummer. 2. Aktør skriver inn pasientens fødselsnummer. 3. Systemet sjekker at feltet er korrekt utfylt. 4. Systemet viser informasjonen om pasientens som er lagret i registeret. 5. Aktøren endrer og føyer til informasjon om pasienten. 6. Aktøren ber om å få lagret pasient informasjonen. 7. Systemet sjekker at feltene er korrekt utfylt. 8. Systemet lagrer informasjonen og bekrefter oppdateringen av registeret. Variasjoner: 3a. Feltet for fødselsnummer er feil utfylt..... Systemet gir feilmelding og ber om -sifret fødselsnummer på nytt.... 2.Aktør skriver inn pasientens fødselsnummer riktig. 4a. Pasienten er ikke registrert..... Extend use case Opprett pasient. 7a. Feil i utfyllelsen av feltene..... Systemet gir feilmelding og ber aktør rette feil.... 2. Aktør retter feil i skjemaet. 5
Opprett pasient Lege, Sykepleier, Admin. Aktør ønsker å registrere ny pasient i systemet Pasient er ikke registrert Pasienten er registrert Normalt hendelsesflyt:. Systemet viser utfyllingskjema. 2. Aktør fyller inn informasjon om pasienten, inkludert -sifret fødselsnummer. 3. Systemet sjekker at skjemaet er riktig fylt ut. 4. Aktør bekrefter informasjonen om pasienten. 5. Systemet lagrer opplysningene. Variasjoner: 3a. Feil i utfyllese av skjemaet..... Systemet gir feilmelding og ber aktør rette feil.... 2. Aktør retter feil i skjemaet. Skriv ut pasient Lege Pasienten er ferdigbehandlet og frisk nok til å forlate sykehu- set Pasienten er skrevet inn Pasienten har status utskrevet Normalt hendelsesflyt:. Systemet ber om -sifret fødselsnummer. 2. Lege skriver inn pasientens fødselsnummer. 3. Systemet sjekker at feltet er korrekt utfylt. 4. Systemet viser informasjonen om pasientens som er lagret i registeret. 5. Legen endrer pasientens status til utskrevet og annen aktuell informasjon. 6. Legen ber om å få lagret informasjonen om pasienten. 7. Systemet sjekker at feltene er korrekt utfylt. 8. Systemet lagrer informasjonen og bekrefter oppdateringen av registeret. 6
Variasjoner: 3a. Feltet for fødselsnummer er feil utfylt..... Systemet gir feilmelding og ber om -sifret fødselsnummer på nytt.... 2. Legen skriver inn pasientens fødselsnummer riktig. 7a. Feil i utfyllelsen av feltene..... Systemet gir feilmelding og ber legen rette feil.... 2. Legen retter feil i skjemaet. Vis legens pasienter Lege, Sykepleier, Admin Admin vil vite om legen skriver ut for mye rohypnol til suspekte pasienter. Pasienter og deres lege er registrert i systemet Legens pasienter blir listet opp Normalt hendelsesflyt:. Systemet ber aktør fylle inn legens navn. 2. Aktør fyller inn navn på aktuell lege. 3. Systemet sjekker at lege er registrert. 4. Systemet viser oversikt over legens pasienter. Variasjoner: 3a. Lege er ikke registrert..... Systemet gir feilmelding, og ber aktør sjekke stavefeil og eventuelt prøve på nytt. Alloker personell til operasjon Admin En operasjon bestilles. Operasjonen må være bestilt Personell er booket til operasjon Normalt hendelsesflyt:. Systemet viser utfyllingskjema 2. Admin legger til aktuellt personell til operasjonen 3. Systemet sjekker at informasjonen inn er fylt ut riktig. 4. Systemet sjekker at oppført personell er ledig. 5. Admin ber om at informasjonen blir lagret. 6. Systemet lagrer informasjonen 7
Variasjoner: 3a. Informasjon inn er ikke riktig fylt ut..... Systemet gir feilmelding og ber admin rette informasjonen.... 2. Admin retter utfyllingen av informasjon. 4a. Nytt oppført personell er ikke ledig..... Systemet gir feilmelding. Modifiser ventelisteinformasjon Lege ) Det skjer forandringer i tilstanden til en pasient. 2) En pasient skal legges til en venteliste. Pasienten står på ventelisten Pasientens ventelisteinformasjon er forandret Normalt hendelsesflyt:. Systemet ber om pasientens fødselsnummer (-siffer). 2. Lege fyller inn aktuell pasient s fødselsnummer. 3. Systemet viser informasjon om pasienten og ber om at ny informasjon fylles ut. 4. Lege fyller ut ny ventelisteinformasjon. 5. Systemet sjekker at informasjonen er riktig utfylt. 6. Lege ber om at den nye ventelisteinformasjonen blir lagret. 7. Include use case Beregn venteliste Variasjoner: 5a. Informasjonen er ikke riktig fylt ut..... Systemet gir feilmelding og ber admin rette informasjonen.... 2. Admin retter utfyllingen av informasjon Bestill operasjon Admin En pasient skal opereres Operasjonssal og overvåkningsrom må være ledig ) Operasjonssal er satt av, plass på overvåkningsrom er satt av, nødvendig personell er satt opp, operasjonen lagt inn i systemet eller 2) Admin har fått feilmelding 8
Normalt hendelsesflyt:. Systemet ber om tidspunkt, operasjonssal, pasient, leger og sykepleiere. 2. Admin legger inn nødvendig informasjon. 3. Systemet sjekker den nødvendige informasjonen er riktig utfylt. 4. Systemet sjekker at de ønskede ressurser er ledige. 5. Admin ber om at operasjonen blir bestilt og lagret. 6. Systemet lagrer operasjonen Variasjoner: a. Admin behøver ikke å fylle ut all informasjon, slik at systemet kan foreslå ledige ressurser. 3a. Nødvendig informasjon er ikke tilfredsstillende utfylt..... Systemet gir feilmelding og ber admin rette feil i utfyllingen.... 2. Admin retter feil. 4a. De nødvendige rom/ansatte er ikke ledige.... Systemet informerer om hvilke ressurser som ikke er ledige og ber admin prøve igjen Beregn venteliste Lege Ventelisteinformasjon på en pasient blir forandret ) Det må være en venteliste. 2) Det må finnes ventelisteinformasjon på pasientene. En venteliste har blitt generert Normalt hendelsesflyt:. Systemet beregner prioriteringsnummer for pasienten. 2. Systemet finner prioritetsnummer på andre pasienter på ventelisten. 3. Systemet beregner en ny venteliste. Variasjoner: Opprett, modifiser eller fjern avdeling Admin Admin ønsker å opprette/modifisere/fjerne en avdeling Avdelingen må finnes dersom den skal modifiseres eller fjernes. I likhet må det ikke finnes en lik avdeling dersom det skal opprettes en ny. Systemet må være oppdatert i forhold til endringene 9
Normalt hendelsesflyt:. Systemet ber admin velge mellom å opprette, modifisere eller fjerne. 2. Admin gjør et valg. 3. Systemet kommer opp med nytt skjema hvor Admin må skrive inn navn på avdeling. 4. Systemet sjekker at et gyldig navn er skrevet inn. 5. Systemet endrer og oppdaterer de interne dataene, evt. oppretter en ny avdeling. 6. Systemet svarer til admin med resultat av operasjonen. Variasjoner: Opprett, modifiser eller fjern seng Admin Admin ønsker å opprette, modifisere eller fjerne en seng fra avdeling Sengen skal modifiseres eller fjernes må være registrert. Sengen som skal opprettes må ikke være registrert. Systemet må være oppdatert i forhold til endringene Normalt hendelsesflyt:. Systemet spør admin om det skal opprettes, modifiseres eller fjernes en sengeplass. 2. Admin velger blant de tre alternativene. 3. Systemet ber om nummer på sengeplass. 4. Admin skriver inn nummer. 5. Systemet validerer dataene, og evnt. sjekker om den aktuelle sengeplassen finnes. 6. Systemet endrer den interne tilstanden til sengeplassen. Dersom sengeplassen skal slettes så utføres dette, og oppdaterer databasen. 7. Systemet svarer til admin med resultat Variasjoner: 5a. Aktuell sengeplass finnes ikke..... Systemet gir feilmelding... 2. Systemet ber admin skrive nytt nummer. Opprett, modifiser eller fjern sykepleier Admin Admin ønsker å opprette, modifisere eller fjerne en sykepleier 0
Dersom sykepleiern skal opprettes er det viktig at det ikke finnes en tilsvarende sykepleier. Videre må den respektive sykepleier som skal modifiseres eller fjernes finnes i systemet Systemet må være oppdatert i forhold til endringene Normalt hendelsesflyt:. Systemet spør admin om det skal opprettes, modifiseres eller fjernes en sykepleier. 2. Admin velger blant de tre alternativene. 3. Systemet ber om sykepleiers ansatt nummer. 4. Admin skriver inn nummer. 5. Systemet validerer dataene, og evnt. sjekker om den aktuelle sykepleieren finnes. 6. Systemet endrer den interne informasjon om sykepleieren. Dersom sykepleieren skal fjernes så utføres dette, og databasen oppdateres. 7. Systemet svarer til admin med resultat. Variasjoner: 5a. Aktuell sykepleier finnes ikke..... Systemet gir feilmelding og ber adim rette feil.... 2. Admin retter feil. Modifiser pasientinformasjon Lege, sykepleier Lege eller sykepleier ønsker å modifisere pasientinformasjon Pasienten må være registrert i systemet. Den nye tilstanden oppdateres i databasen Normalt hendelsesflyt:. Systemet ber aktøren skrive inn -sifret fødselsnummer til pasient. 2. Aktør skriver inn pasientens fødselsnummer. 3. Systemet sjekker at utfyllingen er korrekt. 4. Systemet sjekker at denne pasienten eksisterer i systemet. 5. Systemet henter opp gjeldene informasjon som ligger lagret om pasienten. 6. Aktøren skriver inn de nye opplysningene. 7. Systemet sjekker at utfyllingen er korrekt. 8. Systemet oppdaterer databasen og gir melding om resultat tilbake til aktøren. Variasjoner: 3a. Feil i utfylling av fødselsnummer..... Systemet gir feilmelding og ber aktør rette.... 2. Aktør retter feil.
7a. Feil i utfylling av fødselsnummer..... Systemet gir feilmelding og ber aktør rette.... 2. Aktør retter feil..3 Beskrivelse av ikke-funksjonelle krav Siden det er mye sensitiv informasjon lagret i systemet så må det være innbruddssikkert. Alle som skal bruke systemet må ha passord. Dessuten skal ikke systemet bryte sammen, fordi en pasients helse kan stå på spill. Systemet må være robust. Data kan på ingen måte tapes eller bli borte. Systemet må være så brukervennlig at "alle" kan lære seg det på to dager. Det antas at bruker i verste fall ikke er kjent med bruk av datamaskin. Alle kommandoer fra brukeren må gi raske og klare svar, slik at bruker har kontrollen..4 Tekniske konsekvenser av gitte krav Vurdering av oppdragsgivers krav og tekniske konsekvenser som følger av disse: Det kreves at mye informasjon skal kunne lagres og hentes ut til enhver tid. Derfor vil det være naturlig å bruke en database for å ta vare på denne informasjonen. På denne måten vil det være mulig å lagre store datamengder, med enkel oppdatering og rask aksess. For at det skal være mulig å bruke systemet over store deler av sykehuset vil det være nødvendig å sette ut terminaler på lett tilgjengelige steder. Disse må være koblet sammen i et internt nett for å kunne kommunisere med databasen. For å kunne bruke systemet må brukerne logge seg inn på terminalene med brukernavn og passord. Det bør være et grensesnitt mellom brukerne og databasen som kan vise informasjon fra databasen på en ordnet måte for brukeren. Grensesnittet må også kunne ta i mot informasjon fra brukerne, validere denne, for så å oppdatere/legge inn dette i databasen. Et slikt brukergrensesnitt kan lages i java. 2
.5 Domenemodell Venteliste Lege Timeplan..*..* Pasient timeplan 0....* 0.. Pasient Sykepleier..* Seng 0.. Avdeling Operasjon Recovery plass Figur 2: Domenemodellen 3
2 Brukergrensesnitt Dette er slik vi tenker oss hovedbildet i "General Hospital". For å velge funksjoner kan man enten trykke på knappene øverst i bildet eller velge fra menyene. Da kommer det nye valg i hoveddelen av vinduet. All input og rapportskriving i programmet foregår i hoveddelen. For å navigere raskere i menyen tenker vi oss "Windows" hotkeys som alt+bokstav for å velge meny og en bokstav til for å velge forskjellige funksjoner (f.eks. Fil->Åpne blir da alt+f+p). I tillegg kommer det til å være enklere hotkeys for ofte brukte funksjoner ved bruk av ctrl+bokstav, f.eks. sett opp operasjon kommer til å være ctrl+o. Standard hurtigtaster fra Windows, som F for hjelp og F5 for oppdater osv. kommer også til å bli brukt. Hvis man trykker på enter i et vindu som krever at man bekrefter noe er dette synonymt med at man gjør valget (altså istedetfor å trykke med musen på ok knappen trykker man bare enter). Hvis man ikke ønsker å bruke musen i det hele tatt, kan man også bruke tabulator for å velge hvilken knapp som skal være valgt å trykke enter for å utføre funksjonene tilknyttet denne. 4
Figur 3: Brukergrensesnitt 5