USE CASE FOR
INF3120-PROSJEKT: G15
Gruppe 15:
MORTEN M. WANG HANSEN
ESPEN URNE
PER THOMAS KRAABØL
CHRISTER MICHAELSEN
INNHOLD
| 1 | Use Case modell | 3 | |
|---|---|---|---|
| 1.1 | Oppdragsgivers krav og tekniske konsekvenser | 3 | |
| 1.2 | Use Case diagram | 4 | |
| 1.2.1 | Beskrivelse av aktører | 5 | |
| 1.2.2 | Beskrivelse av Use Case | 6 | |
| 1.3 | Domenemodell | 8 | |
| 1.4 | Ikke-funksjonelle krav | 9 |
1. USE CASE MODELL
1.1 Oppdragsgivers krav og tekniske konsekvenser
Kravene knyttet til brukergensesnittet er GUI, støtte for mus, menybasert system og hotkeys. Dette legger føringer knyttet til design av systemet. Brukergrensesnittet legges som skall på toppen av klassene som implementerer funksjonaliteten. Det kan også medføre en investering knyttet til et utviklingsverktøy med effektiv støtte for awt / swing
Det er spesifisert at systemet må kunne generere enhver ønsket rapport. Enhver ønsket rapport synes meget krevende å implementere, men vi skal ta hensyn til dette med valg av lagring av informasjonen. Dette skal gjøres slik at det flest mulig rapporter kan genereres.
Innføring av nytt system med fokus på GUI kan resultere i nye krav til arbeidstasjonene. Dette kan gi behov for oppgradering av eksisterende maskiner.
Likeledes kan nytt brukergrensesnitt avstedkomme behov for opplæring av brukere. Opplæringsbehovet bør kartlegges. Undervurdering av opplæringsbehovet kan ha alvorlige konsekvenser ved implementering av systemet.
Kravspesifkasjonen peker mot en infrastruktur med en eller flere sentrale tjenermaskiner og arbeidstasjoner knyttet sammen med et datanettverk. Om dette ikke finnes med tilstrekklig kvalitet må det investeres i slikt utstyr. En slik investering vil medføre investering i opplæring av de som skal ha det daglige tilsynet med systemet. Det vil ellers ikke være mulig å overholde kravet til oppetid og datasikkerhet.
Med unntak av hva som er spesielt nevnt ovenfor vil alle elementene i kravspesifikasjonen kunne møtes uten nye investeringer for prosjektgruppen. Kravspesifikasjonen kan leveres med gruppens eksisterende utstyr og programmvare.
1.2.1 Beskivelse av aktører
| Aktør | Administrasjonspersonell |
| Beskrivelse | Aktør som legger inn, endrer og sletter data |
| Eksempler | Legger inn ny pasient |
| Aktør | Doktor |
| Beskrivelse | Aktør som ser på data |
| Eksempler | Henter info om pasient |
| Aktør | Pleier |
| Beskrivelse | Aktør som ser på data |
| Eksempler | Henter info om pasient |
1.2.2 Beskrivelse av Use Case
| Use Case | leggTilPerson |
| Aktør | Administrasjonspersonell |
| Trigger | AdmPers ønsker å legge til en ny Person |
| Pre-betingelser | Person er ikke registrert i systemet |
| Post-betingelser | 1. Ny Person registrert i systemet eller 2. Bruker får feilmelding |
| Normal hendelsesflyt | 1. Systemet ber om relevant informasjon 2. Bruker skriver inn relevant informasjon 3. Systemet sjekker om alt er riktig utfylt 4. Bruker ber om at Person blir lagret 5. Systemet lagrer Person |
| Variasjoner | 3a. Alle felt er ikke tilfredsstillende utfylt 3b. Person kan allerede eksistere i systemet |
| Relatert informasjon | Tildeler unikt ID-nummer til ny Person |
| Use Case | endrePerson |
| Aktør | Administrasjonspersonell |
| Trigger | AdmPers ønsker å endre data på Person |
| Pre-betingelser | Person er registrert i systemet |
| Post-betingelse | 1. Data på Person endret eller 2. Bruker får feilmelding |
| Normal hendelsesflyt | 1. Bruker søker opp aktuell Person 2. Systemet viser Personens data 3. Bruker utfører endringen 4. Systemet sjekker om alt er riktig utfylt 5. Bruker ber om at Person blir lagret 6. Systemet lagrer Person |
| Variasjoner | 1. Person finnes ikke i systemet 4a. Alle felt er ikke tilfredsstillende utfylt |
| Relatert informasjon |
| Use Case | slettePerson |
| Aktør | Administrasjonspersonell |
| Trigger | AdmPers ønsker å slette Person |
| Pre-betingelser | Person er registrert i systemet |
| Post-betingelser | 1. Person slettet fra systemet eller 2. Bruker får feilmelding |
| Normal hendelsesflyt | 1. Bruker søker opp aktuell Person 2. Systemet viser Personens data 3. Bruker velger å slette Person 4. Systemet sjekker om det er tillatt 5. Bruker bekrefter at Person skal slettes 6. Systemet sletter Person |
| Variasjoner | 1a. Person finnes ikke i systemet 4a. Person er ikke tillatt slettet |
| Relatert informasjon | Systemet sjekker om Person kan slettes, eks. doktor vs operasjon |
| Use Case | visPerson |
| Aktør | Administrasjonspersonell, doktor, pleier |
| Trigger | Bruker ønsker å få informasjon om Person |
| Pre-betingelser | Bruker har valgt å få informasjon Person |
| Post-betingelser | 1. Informasjon om Person vises eller 2. Bruker får feilmelding |
| Normal hendelsesflyt | 1. Bruker søker opp aktuell Person 2. Systemet viser Personens data 3. Bruker ser på data |
| Variasjoner | 1a. Person finnes ikke i systemet |
| Relatert informasjon |
| Use Case | lagRapport |
| Aktør | Administrasjonspersonell, doktor, pleier |
| Trigger | Bruker ønsker å få en rapport |
| Pre-betingelser | Bruker har valgt å få en rapport |
| Post-betingelser | 1. Bruker får rapport eller 2. Bruker får feilmelding |
| Normal hendelsesflyt | 1. Bruker velger type rapport 2. Systemet ber om relevant informasjon 3. Bruker skriver inn nødvendig informasjon 4. Systemet finner data og generer rapport 5. Systemet viser rapport 6. Bruker velger skriver 7. Rapport kommer ut på valgt skriver |
| Variasjoner | 4a. Systemet finner ikke data 7a. Skriver virker ikke |
| Relatert informasjon |
1.4 Beskrivelse av ikke-funksjonelle krav
Sikkerhet
Et datasystem ved et sykehus vil naturlig nok inneholde mye sensitiv informasjon. Det er derfor viktig å hindre uvedkommende å få innsyn i dataene. Selve HSS-systemet skal sikres ved å autentisere bruker med passord. Hvis systemet også skal være tilkoblet Internett eller ha grensesnitt mot andre system, skal disse tilgangene også være sikret.
Oppetid
Siden systemet bl.a. skal brukes til å planlegge operasjoner, er det viktig at systemet har høy opptid i periodene hvor operasjonene gjennomføres. Enda viktigere er det at nedetiden er kort hvis systemet, mot formodning, skulle gå ned. Vi forutsetter at operasjonene for det meste skal planlegges og gjennomføres på dagtid. Da har man muligheter til å lage gode rutiner rundt backup- og recovery-strategier.
Pålitelighet
Det er viktig at systemet er robust, slik at dataene er pålitelige. Systemet må håndtere interne feil og det må sikres mot muligheten til å lagre "feil" data.