Kravspesifikasjon. Utvikle et registreringssystem for personalet Periode: Kamiran Ahmed Selewani (s156192) Ali Ahmed Mirzaiei (s156172)

Transkript

1 K-skjemaer og feriekalander. Oppgave: Utvikle et registreringssystem for personalet Periode: 03.Januar til 17.Juni Gruppenr: 4 Medlemmer: Kamiran Ahmed Selewani (s156192) Ali Ahmed Mirzaiei (s156172) Behrouz Saki (s155476) Azad Bamarni (s141710) Oppdragsgiver: Kontaktperson: Veileder Utlendingsnemnda (UNE) Carlos Ahomada cah@une.no Steinar Johannessen Hovedprosjekt 2011 Side 0 av 20 Gruppe 4

2 Forord Dette dokumentet inneholder kravspesifikasjon for prosjektet K-Skjemaer utarbeidet av gruppe 4 i forbindelse med hovedprosjekt oppgaven ved Høgskolen i Oslo(HIO) i samarbeid med Utlendingsnemnda(UNE) for sluttsemesteret Våren Hensikten med dokumentet er å framlegge kravene fra oppdragsgiveren(une) på funksjonelle og ikke funksjonelle krav for prosjektet K-Skjemaer. Kravspesifikasjonen er beregnet for sensor, veileder, oppdragsgiver, gruppemedlemmer og kan også leses av andre som skulle finne den interessant. Kravspesifikasjonen har vært av stor betydning for utviklingen av systemet og systemets funksjonalitet og har i tillegg hatt en stor betydning for fremdriftsplanen. Hovedprosjekt 2011 Side 1 av 20 Gruppe 4

3 Innholdsfortegnelse 1 Bakgrunn Leser veiledning Systembeskrivelse Systembrukere Funksjonelle krav: A- Fra Administrator: B- Fra avdelinger Ikke funksjonelle krav: Nivåene er som følgende: Ikke-funksjonelle krav deles i tre typer a Produktkrav b Prosesskrav c Eksterne krav Rammekrav i systemet, f.eks Eventuelle krav til systemkonstruksjon Eventuelle krav til dokumentasjon Eventuelle krav til manuelle funksjoner Eksempel på input data:... Feil! Bokmerke er ikke definert. 11 Logisk datamodell System-Nivå A.1 Logg inn A.2 Registrering/Endring B.1 Logg inn B.2 Registrering/Endring Use Case-modell Opprett administrator Logging System Hovedprosjekt 2011 Side 2 av 20 Gruppe 4

4 Bakgrunnen/Leser veiledning/systembeskrivelse 1 Bakgrunn Klageinstansen Utlendingsnemnda (UNE) er et domstolliknende forvaltningsorgan til behandling av klager på asyl/oppholdstillatelse over avslag gitt av førsteinstansen Utlendingsdirektoratet(UDI) etter utlendingsloven og statsborgerloven. UNE ble startet i januar Over tiden var arbeidsmengden hos UNE stadig voksende og det medførte et behov for flere ansatte. UNE har per i dag ca. 400 ansatte som jobber i sju avdelinger. UNE bruker per i dag et personalregistersystem for ansatte bestående av såkalte K-Skjemaer. Det er skjemaer som brukes for operasjoner som lagring av personal opplysninger og ansettelsesforhold. Skjemaene blir lagret som Access filer hvor hver fil tilhører en ansatt. Eksisterende System anses som et tungvint system og ivaretar ikke sikkerheten. Og På bakgrunn av dette har UNE innforstått behovet for et nytt system som kan redusere arbeidsmengden ved å samle alle operasjoner et sted, automatisere oppdateringer og samtidig ivareta sikkerheten. 2 Leser veiledning Kravene til produktet er organisert i to hovedgrupper. Kravgruppene er funksjonelle og ikke funksjonelle krav. Funksjonelle krav beskriver en tilstand vi ønsker å oppnå og funksjoner produktet bør utføre. Ikke-funksjonelle er krav systemet stiller til sine omgivelser. Dette omfatter krav til produktet fra sluttbrukere og de systemer og rutiner som finnes i organisasjonen. Under de to hoved kravgruppene har vi igjen delt kravene fra forskjellige brukere av systemet. Vi vil gå i mer detaljer videre i rapporten hvor vi beskriver både funksjonelle og ikke funksjonelle krav. 3 Systembeskrivelse Systemet er en nettbasert applikasjon bestående av to deler, en administreringsdel for administrator, og en avdelingsdel for andre system brukere. Systemet vi skal utvikle skal forbedre problemområdet ved å automatisere operasjoner, samle alle opplysninger på en database og koble skjemaene sammen. Operasjoner skal automatiseres ved registrering av nye ansatte eller ved endringer av ansettelsesforhold. Det skal benyttes lynmeldinger i form av e-post meldinger som skal sendes til de som har ansvaret i avdelinger for å informere om nye registreringer, eventuelt endringer av eksisterende opplysninger. Hovedprosjekt 2011 Side 3 av 20 Gruppe 4

5 Systembrukere/Funksjonelle krav Det skal sendes data til forskjellige avdelinger hvor ansvarligperson i avdelingen skal fylle ut sine poster med tilsendt data. 4 Systembrukere Systemet skal brukes av en eller flere Administratorer og utvalgte ansvarlige for følgende avdelinger: HR-Human Resource. Service. Resepsjon/Vekter. DI (Drift og IT). Økonomi. Administrator skal være super administrator med lese og skriverettigheter på K-Skjemaene. Andre brukere(avdelinger) vil ha begrenset lese og skrive rettigheter. Systemet skal fylle ut følgende funksjonelle og ikke-funksjonelle krav. Vi lister opp kravene fra forskjellige system brukere. Vi lister kravene med høyest prioriterte krav øverst i listen. 5 Funksjonelle krav: Det er krav som enten blir oppfylt eller ikke oppfylt. Her har vi organisert krav fra forskjellige brukere som følgende. 5.1 A- Fra Administrator: 1. Innlogging skal skje med brukernavn og passord for administrator. 2. Administrator skal kunne endre innloggingspassord. 3. Registrering av systembrukere med rolletildeling. 4. Administrator skal kunne endre/slette systembrukere. 5. Registrering av nye ansatte. 6. Validering av inputdata. 7. Administrator skal stå registrert som ansatt. 8. En ansatt skal ikke kunne registreres to ganger med aktiv status. 9. Registrering eller endringer av eksisterende opplysninger skal lagres på samme database. 10. Ved registrering/endringer/sletting skal det sendes automatisk e-post til avdelingene med relatert opplysninger for hver avdeling. 11. Mulighet for å registrere/endre enheter og stillinger. 12. Ny registrerte enheter og stillinger skal lastes til siden automatisk. 13. Registrere/endre adgangskort. 14. Registrere/endre nøkler. 15. Ny registrerte adgangskort og nøkler skal lastes til siden automatisk. Hovedprosjekt 2011 Side 4 av 20 Gruppe 4

6 Funksjonelle krav 16. Ved ny registrering av ansatte skal enhet velges fra en liste som inneholder navn på alle enheter som er registrert sortert alfabetisk. 17. Ved ny registrering av ansatte skal stilling velges fra en liste som inneholder navn på alle typer stillinger som er registrert sortert alfabetisk. 18. Ved ny registrering av ansatte skal adgangskort velges fra en liste som inneholder navn på alle typer adgangskort som er registrert sortert alfabetisk Ved ny registrering av ansatte skal nøkkel velges fra en liste som inneholder navn på alle nøkler som er registrert sortert alfabetisk. 20. Administrator skal kunne gjenopprette passord hvis glemt passord. 21. Avansert søkemotor. Søke etter fødselsnummer, fornavn, etternavn eller registreringsnummer. 22. Statistikk. Mulighet for å liste alle aktive ansatte og ikke aktive ansatte. 23. Historikk. Mulighet for å liste en ansatts historikk. Ansatte som slutter skal registreres som ikke aktive. 5.2 B- Fra avdelinger 1. Innlogging for avdelinger skal skje med brukernavn og passord. 2. Innlogging skal være adgangsbegrenset til opplysninger som ligger i database. 3. Ansvarlige skal stå registrert som ansatte. 4. Skal kunne endre innloggingspassord. 5. Ved ny registrering/endring skal ansvarlig motta e-post som skal inneholde unikt registreringsnummer. 6. Ansvarlig skal kunne i et søke felt taste inn registreringsnummer og det skal vises opplysninger om gitt ansatt sammen med skjemaet som skal fylles ut av ansvarlig. 7. Vise opplysninger som er av betydning for avdelingen ved bruk av registreringsnummer. 8. Det skal lages skjemaer for avdelinger for å registrere opplysninger. 9. Ansvarlig skal kunne bekrefte utførte oppgaver ved å lagre en bekreftelsesmelding i en egen tabell i databasen. 10. Det skal ligge et kommentarfelt for å kunne legge til eventuelle kommentarer. 11. Dersom det foreligger opplysninger om utførte oppgaver, skal dette listes ut i et skjema, der skal det stå hva som er utført, dato og utført av hvilken brukr. 12. En ansvarlig skal kunne gjenopprette passord hvis glemt passord. Hovedprosjekt 2011 Side 5 av 20 Gruppe 4

7 6 Ikke funksjonelle krav: Kravspesifikasjon Ikke funksjonelle krav/rammeverk i system Dette er krav som kan utrykkes i en form som angir aksepteringsgrense for oppfyllelse av kravet. Vi definerer aksepteringsgrensen i 3 nivåer. 6.1 Nivåene er som følgende: 1. Ikke fornøyd anses som utilfredsstillende. 2. Litt fornøyd anses som akseptabelt men bør forbedres i fremtiden. 3. Fornøyd anses som krav tilfredsstillende. 6.2 Ikke-funksjonelle krav deles inn i tre typer: 6.2.a Produktkrav 1. Brukervennlighet. 2. Ytelseskrav. 3. Krav for lagringskapasitet. 4. Pålitelighet. Evnen til å opprettholde funksjonen (yteevne) over tid. 5. Tilgjengelighet. 6.2.b Prosesskrav 1. Krav til standarder. 2. Leveranse krav. 6.2.c Eksterne krav 1. Personvern. 2. Sikkerhetskrav. 7 Rammekrav i systemet, f.eks. Dette er krav som gjelder systemet som helhet. 1. Det kreves at systemet skal være tilpasset dagens eksisterende maskin og programvare. 2. Det skal til en hver tid være mulig å utvide/videreutvikle systemet uten store kostnader. 3. Tidsfaktorer på svartider, oppdatering og overføringstider skal ligge innen akseptabelt nivå. 4. Tilgjengelighet ved behov for konstantkjøring. 5. Presis og nøyaktighet på data. Hovedprosjekt 2011 Side 6 av 20 Gruppe 4

8 Eventuelle krav til systemkonstruksjon/dokumentasjon/manuelle funksjoner 8 Eventuelle krav til systemkonstruksjon 1. Windows Server 2008 skal brukes og skal være basis operativ system. 2. SQL server kreves som basis databasesystem. 3. Det kreves IT-Kunnskaper for drifting av systemet. 4. Det er ikke noe krav om noe kode konstruksjon men det bør følge standarder som er godkjent av globale institusjoner. 9 Eventuelle krav til dokumentasjon Dokumentasjonen skal samsvare med dokumentasjonsstandarden levert av HIO. Standarden er utarbeidet av førstelektor Ann-Mari Torvatn ved høgskolen i Oslo. Dokumentasjon skal leveres ved utgangen av prosjektperioden. Dokumentasjon samles til et hefte i flere eksemplarer som skal leveres til administrasjonen ved HIO og til oppdragsgiver. Kravspesifikasjonen er utarbeidet i samarbeid med oppdragsgiver og oppdragsgiveren har med dette hatt oversikt over standarden under utformingsperioden. Følgende skal leveres: 1. Prosessdokumentasjon. 2. Produktdokumentasjon. Dokumentasjon av systemets tekniske oppbygging. 3. Kravspesifikasjon. 4. Testdokumentasjon. 5. Forprosjektrapport. 6. Brukerveiledning. 10 Eventuelle krav til manuelle funksjoner 1. Beskrivelse av hvem skal utføre funksjonene. Funksjonene som skal utføres har forskjellige brukere. Administrator og Avdelinger. 2. Førstegangs brukernavn og Passord. Det skal kunne registrere førstegangs brukernavn ved førstegangs bruk av produktet. 3. Beskrivelse av Inn-data. Input data skal være i form av klar tekst. Det skal være tekststrenger eller heltallsverdier. Det er ikke satt noe krav på tekst format, størrelse og font familie. Datoer skal velges av kalender lister. Ellers vil datoer samsvare med maskinenes dato og klokkeslett. Dette vil være detaljert beskrevet i produktdokumentasjon. Hovedprosjekt 2011 Side 7 av 20 Gruppe 4

9 Logisk datamodell 10.1 Eksempel på input data: Navn Adresse Postnummer Poststed Fødselsdato Stilling Avdeling/Seksjon Kontor nr Tlf nr Startdato Registrert String (Fornavn Etternavn) String Int (Heltall) String Int (Heltall) Velges fra liste Velges fra liste String Int (Heltall) Kalender liste Systemtid 4. Beskrivelse av Ut-data. Ut-data skal være i klar tekst. Teksten skal være lett leselig og oversiktlig. 11 Logisk datamodell Dette kapitlet inneholder beskrivelse av arbeidsflyten for systemet K-Skjemaer illustrert i form av Dataflyt-diagrammer laget i APM(Action Port Model) modellen. Dette er modellen gruppen valgte for å illustrere dataflyten hvor vi mener at dette vil skape en god forståelse av dataflyten, modellen har en bedre oversikt og er lett forståelig. APM(Action Port Model) er en modell som beskriver prosesser og data-flyten i form av input-output data. Den viser prosesstype, input data, operasjoner, avhengigheter og utdata. Mer om denne prosessen står i artikkelen: Action Port Model: A Mixed Paradigm Conceptual Workflow Language. Skrevet av Steinar Carlsen, ved NTNU. Hovedprosjekt 2011 Side 8 av 20 Gruppe 4

10 Logisk datamodell Under hver figur ligger en kort forklaring på figuren System-Nivå 0 Forklaring til APM diagram i figur System-Nivå 0. Figuren ligger i 0-Nivået og den viser systemet som en helhet. Her står brukere av systemet. Brukere er Admin og Avdelinger. Figuren inneholder dataflyt diagrammene som ligger i videre nivåer vist som firkanter merket med navn og nummer A.1 Logg inn Hovedprosjekt 2011 Side 9 av 20 Gruppe 4

11 Logisk datamodell Forklaring til APM diagram i figur A.1 Logg inn: I prosessen ønsker Admin å logge inn, Admin skriver inn brukernavn og passord, input data blir kontrollert med data som er lagret på Admin tabellen i databasen. Ved godkjent innlogging blir utdata for Admin tilgang til Admin siden, ved mislykket innlogging blir det skrevet ut en feilmelding til Admin A.2 Registrering/Endring Forklaring til APM diagram i figur A.2 Registrering/Endring: Admin ønsker å foreta en ny registrering eller en forandring på eksisterende register, han/hun skriver inn opplysninger, trykker på lagre knappen, data blir oppdatert på Personalregister tabellene i databasen, det skrives en bekreftelse på skjermen hvis vellykket operasjon, ellers skrives det en feilmelding på skjermen. Hovedprosjekt 2011 Side 10 av 20 Gruppe 4

12 Logisk datamodell 11.4 B.1 Logg inn Forklaring til APM diagram i figur B.1 Logg inn: I prosessen ønsker Bruker å logge inn, Her kan bruker være en av de forskjellige brukere av del 2 av applikasjonen. Bruker skriver inn brukernavn og passord, innputt data blir kontrollert med data som er lagret på Brukeropplysninger i databasen. Ved godkjent innlogging blir utdata for en bruker tilgang til riktig programdel etter brukerens oppgitt rolle B.2 Registrering/Endring Hovedprosjekt 2011 Side 11 av 20 Gruppe 4

13 Use case-modell Forklaring til APM diagram i figur B.2 Registrering/Endring: Bruker ønsker å foreta en ny registrering eller en forandring på eksisterende register, han/hun skriver inn opplysninger, trykker på lagre knappen, data blir oppdatert på Personalregister tabellene i databasen, det skrives en bekreftelse på skjermen hvis vellykket operasjon, ellers skrives det en feilmelding på skjermen. 12 Use Case-modell En brukstilfellemodell (Use Case Model) er en modell over hva et informasjonssystem skal gjøre og for hvem. Et brukstilfelle er en isolert funksjon eller en prosess som tilfredsstiller et krav. Brukstilfellemodellen visualiserer kravene til systemet. Her har vi tatt med kun essensiell atferd av systemet. Det ligger et brukstilfelle (Use Case) beskrivelse under hver brukstilfellemodell Opprett administrator Use case beskrivelse av Opprett Administrator Use case Aktør Trigger Pre-betingelser Postbetingelser Opprett Administrator Administrator. Administratoren ønsker å legge til en ny bruker for førstegangs bruk av systemet. Administratoren har valgt å legge til første system bruker i databasen Brukeren blir lagt til eller feilmelding oppstår. Hovedprosjekt 2011 Side 12 av 20 Gruppe 4

14 Use case-modell Normal hendelsesflyt Variasjoner Relatert informasjon 1. Systemet ber om brukernavn, passord og e-post til den nye brukeren 2. Administratoren fyller inn feltene for brukernavn, passord og e- post 3. Systemet lagrer informasjonen og oppretter database for denne brukeren 4. Systemet gir melding til administratoren at ny bruker er lagret. 2. Alle felt er ikke tilfredsstillende utfylt 2.a: Systemet informerer Admin om hvilke felt som ikke er utfylt, og går ikke videre før dette har blitt utført. - Feltene må være utfylt med enten tall eller bokstaver. - Registreringens link skal være under logging feltene Logging Use case beskrivelse av Innlogging Use case Aktør Trigger Pre betingelser Post betingelser Normal hendelsesflyt Variasjoner Admin/Bruker logg inn Admin/Bruker. Aktør ønsker å logge inn. Aktør har valgt å logge seg inn i systemet Aktør er logget inn eller så har det oppstått en feilmelding. 1. Aktør fyller ut feltene for brukernavn og passord. 2. Systemet sjekker om alle feltene er riktig utfylt. 3. Systemet logger inn til en sikret side. 4. Aktør får beskjed om at han/hun er innlogget. 5. Aktør får nye alternativer. 2. Alle felt er ikke tilfredsstillende utfylt 2.a: Systemet informerer Aktør om hvilke felt som ikke er utfylt, og går ikke videre før dette har blitt ordnet (rettet). Hovedprosjekt 2011 Side 13 av 20 Gruppe 4

15 Use case-modell Relatert informasjon - Feltene må være utfylt med enten tall eller bokstaver. - Hvis Admin har glemt passordet, for han den tilsendt til e- postadressen sin System Hovedprosjekt 2011 Side 14 av 20 Gruppe 4

16 Use case beskrivelse Use case beskrivelse av System. Figuren visualiserer systemet som helhet. Brukstilfellene som ligger innenfor rammen etter innlogging på systemet er tatt med her. Use case beskrivelse av Opprett bruker Use case Aktør Trigger Pre betingelser Post betingelser Normal hendelsesflyt Variasjoner Relatert informasjon Opprett bruker Administrator Administrator ønsker å opprette ny bruker Administrator har valgt å opprette ny bruker og lagre den i databasen Brukeren er blitt lagt til eller feilmelding oppstår 1. Systemet ber om brukernavn, passord og E-postadresse til den nye brukeren 2. Administratoren fyller inn feltene 3. Systemet sjekker om brukernavnet eksisterer fra før. 4. Systemet genererer et innloggingspassord og sender det til brukeren. 5. Systemet lagrer informasjonen i databasen for denne brukeren 6. Systemet gir melding til administratoren at ny bruker er lagret 2. Alle felt er ikke tilfredsstillende utfylt 2.a: Systemet informerer Administratoren om hvilke felt som ikke er utfylt, og går ikke videre før dette har blitt utført. 3a. Brukernavnet finnes i databasen 3a1. Systemet informerer administratoren og går ikke videre får brukernavnet er endret - Feltene må være utfylt med enten tall eller bokstaver. -Oversikt over hvilken bruker kan ha hvilken rolle kan administratoren finne vha. en rullegardinmeny Hovedprosjekt 2011 Side 15 av 20 Gruppe 4

17 Use case beskrivelse Use case beskrivelse av Endre bruker Use case Aktør Trigger Pre betingelser Post betingelser Normal hendelsesflyt Variasjoner Relatert informasjon Endre bruker Administrator. Administrator sjekker og endrer databasen. Administrator har logget seg inn. Administrator har sjekket og gjort endringer i databasen. 1. Systemet ber Administrator om å logge seg inn. 2. Admin fyller ut feltene for brukernavn og passord. 3. Systemet sjekker om alle feltene er riktig utfylt. 4. Systemet logger inn til en sikret side. 5. Administrator gjør endringer i databasen. 6. Systemet ber om bekreftelse før den endrer i databasen. 7. Systemet lagrer alle endringene som er gjort av Administrator. 3. Alle felt er ikke tilfredsstillende utfylt 3.a: Systemet informerer Administratoren om hvilke felt som ikke er utfylt, og går ikke videre før dette har blitt ordnet. 6. Administratoren ombestemmer seg(vil ikke slette for eks.). 6.a:Systemet avbryter endringen. - Feltene må være utfylt med enten tall eller bokstaver. - Administratoren blir bedt om å logge seg inn før han kan gå inn på handlekurven. Use case beskrivelse av Slett brukere Use case Aktør Trigger Pre betingelser Post betingelser Normal endelsesflyt Variasjoner Relatert informasjon Slette bruker Administrator Administrator ønsker å slette en bruker Administrator har valgt hvilken bruker som skal fjernes Brukeren slettes eller feilmelding oppstår 1. Systemet ber om brukernavn på brukeren 2. Administrator velger brukernavn fra rullegardin-meny 3. Systemet sjekker om brukernavnet er gyldig 4. Systemet spør om bekreftelse 5. Administrator bekrefter 6. Systemet sletter brukeren 7. Systemet viser melding om at brukeren er slettet 3a. Brukernavnet finnes ikke i databasen 3a1. Systemet informerer administratoren og går ikke videre før brukernavnet er gyldig 5a. Administrator ombestemmer seg og velger "nei" under bekreftelse av sletting 5a1. Systemet avbryter slettingen av denne brukeren - Feltene må være utfylt med enten tall eller bokstaver. - Administrator må logge seg inn før han kan slette en bruker. - Administrator må få et valg boks i tilfelle han ombestemmer seg. Hovedprosjekt 2011 Side 16 av 20 Gruppe 4

18 Use case beskrivelse Use case beskrivelse av Registrer oppgaver Use case Registrer oppgaver Aktør Administrator/Avdelinger brukere Trigger Både administrator/avdelingsbrukere registrer nye oppgaver Pre betingelser Administrator/avdelinger har valgt å registrere ny oppgave og lagre den i databasen Post betingelser Oppgaver blir registrert eller feilmelding oppstår Normal Administrasjonen: hendelsesflyt 1. Systemet ber Administrator om å logge seg inn. 2. Administrator fyller ut feltene for brukernavn og passord. 3. Systemet sjekker om alle feltene er riktig utfylt. 4. Systemet logger inn til en sikret side 5. Administratoren fyller alle feltene for å registrere en ny ansatt 6. Systemet sjekker om ansatt er registret fra før, den blir sjekket med Etternavn, Fornavn og Fødselsdato. 7. Systemet lagrer informasjonen i databasen. 8. Systemet oppretter et unikt registrerings nr. 9. Systemet gir melding til administratoren at ansatt har blitt registrert. 10. En e-post blir sendt til forskjellige avdelinger med relaterte opplysninger hvor avdelinger skal gjøre sine oppgaver. Avdelingsbrukere: 1. Systemet ber avdelingsbrukere om å logge seg inn. 2. Avdelingsbrukere fyller ut feltene for brukernavn og passord. 3. Systemet sjekker om alle feltene er riktig utfylt. 4. Systemet logger inn til en sikret side 5. Avdelingsbrukere søker etter ny ansatt med registrerings nr. 6. Systemet sjekker om ansatt er registrert i databasen, den blir sjekket med registrerings nr. 7. Systemet gir ut relaterte opplysninger om ansatt i de forskjellige avdelinger. 8. Avdelingsbrukere fyller alle feltene for å registrere oppgaven for den eksakte ansatt. 9. Systemet gir melding til avdelingsbrukere at oppgaven for ansatt har blitt registrert. 10. Systemet lager informasjonen i databasen. Variasjoner 2. Alle felt er ikke tilfredsstillende utfylt 2.a: Systemet informerer Administratoren/avdelingsbrukere om hvilke felt som ikke er utfylt, og går ikke videre før dette har blitt utført. 3. Reg nummeret eksisterer ikke i databasen. 3a. Systemet informerer administratoren/avdelingsbrukere og går ikke videre får registreringsnummeret er endret 4. Avdelinger får relaterte opplysninger om ettersøkt ansatt. Hovedprosjekt 2011 Side 17 av 20 Gruppe 4

19 Use case beskrivelse Relatert informasjon 5. System feil. - Feltene må være utfylt med enten tall, bokstaver eller velges fra lister. Use case beskrivelse av Endre oppgaver Use case Aktør Trigger Pre betingelser Post betingelser Normal hendelsesflyt Endre oppgaver Administrator/Avdelinger brukere Både administrator/avdelingsbrukere endrer eksisterende oppgaver Administrator/avdelinger har valgt å endre eksisterende oppgaver og lagre informasjonen i databasen Oppgaver blir Endret eller feilmelding oppstår Administrasjonen: 1. Systemet ber Administrator om å logge seg inn. 2. Administrator fyller ut feltene for brukernavn og passord. 3. Systemet sjekker om alle feltene er riktig utfylt. 4. Systemet logger inn til en sikret side 5. Administrasjon søker med registrerings nr for å endre opplysninger for en ansatt. 6. Systemet sjekker om ansatt eksisterer, den blir sjekket med registrerings nr. 7. Administratoren fyller alle feltene for å endre opplysninger for ettersøkt ansatt. 8. Systemet lagrer informasjonen i databasen. 9. Systemet gir melding til administratoren om at opplysninger har blitt oppdatert/endret. 10. En e-post blir sendt til forskjellige avdelinger med relaterte opplysninger hvor avdelinger skal gjøre sine oppgaver. Avdelingsbrukere: 1. Systemet ber avdelingsbrukere om å logge seg inn. 2. Avdelingsbrukere fyller ut feltene for brukernavn og passord. 3. Systemet sjekker om alle feltene er riktig utfylt. 4. Systemet logger inn til en sikret side 5. Avdelingsbrukere søker med registrerings nr. 6. Systemet sjekker om ansatt eksisterer i databasen, den blir sjekket med registrerings nr. 7. Systemet gir ut relaterte opplysninger om ansatt i de forskjellige avdelinger. 8. Avdelingsbrukere fyller alle feltene for og registrerer og oppdaterer oppgavene for den eksakte ansatt. 9. Systemet gir melding til avdelingsbrukere at oppgaven for ansatt har blitt oppdatert/endret. 10. Systemet lager informasjonen i databasen. Hovedprosjekt 2011 Side 18 av 20 Gruppe 4

20 Use case beskrivelse Variasjoner Relatert informasjon 2. Alle felt er ikke tilfredsstillende utfylt 2.a: Systemet informerer Administratoren/avdelingsbrukere om hvilke felt som ikke er utfylt, og går ikke videre før dette har blitt utført. 3. registrerings nr finnes ikke i databasen 3a. Systemet informerer administratoren/avdelingsbrukere og går ikke videre får reg nummeret er endret 4. Avdelinger får relaterte opplysning om ettersøkt ansatt. 5. System feil. - Feltene må være utfylt med enten tall, bokstaver eller velges fra lister. Use case beskrivelse av Slett oppgaver Use case Slette oppgaver Aktør Administrator/Avdelinger brukere Trigger Både administrator/avdelingsbrukere kan slette eksisterende oppgaver Pre betingelser Administrator/avdelinger har valgt å slette eksisterende oppgaver og oppdaterer informasjonen i databasen Post betingelser Oppgaver blir slettet eller feilmelding oppstår Normal Administrator: hendelsesflyt 1. Systemet ber Administrator om å logge seg inn. 2. Administrator fyller ut feltene for brukernavn og passord. 3. Systemet sjekker om alle feltene er riktig utfylt. 4. Systemet logger inn til en sikret side 5. Administrator søker etter en ansatt med registrerings nr for å slette opplysninger for ettersøkt ansatt. 6. Systemet sjekker om ansatt eksisterer, den blir sjekket med registrerings nr. 7. Systemet gir ut opplysninger til Administrator. 8. Administrator sletter ansatt, og ansatt blir sett som ikke aktiv lenger i databasen. 9. Systemet lagrer informasjonen i databasen. 10. Systemet gir melding til administratoren om at opplysninger har blitt slettet. 11. En e-post blir sendt til forskjellige avdelinger med relaterte opplysninger hvor avdelinger skal gjøre sine oppgaver. Avdelingsbrukere: 1. Systemet ber avdelingsbrukere om å logge seg inn. 2. Bruker fyller ut feltene for brukernavn og passord. 3. Systemet sjekker om alle feltene er riktig utfylt. 4. Systemet logger inn til en sikret side 5. Avdelingsbrukere søker etter ansatt med registrerings nr. 6. Systemet sjekker om ansatt eksisterer i databasen, den blir sjekket med registrerings nr. Hovedprosjekt 2011 Side 19 av 20 Gruppe 4

21 Use case beskrivelse 7. Systemet gir ut relaterte opplysninger om ansatt i de forskjellige avdelinger. 8. Avdelingsbrukere fyller alle feltene for å slette og oppdatere oppgavene for den eksakte ansatt. 9. Systemet gir melding til avdelingsbrukere at oppgaven for ansatt har blitt slettet. 10. Systemet lagrer informasjonen i databasen og ansatt blir sett som ikke aktiv bruker i databasen. Variasjoner Relatert informasjon 2. Alle felt er ikke tilfredsstillende utfylt 2.a: Systemet informerer Administratoren/avdelingsbrukere om hvilke felt som ikke er utfylt, og går ikke videre før dette har blitt utført. 3. registrerings nr finnes ikke i databasen 3a. Systemet informerer administratoren/avdelingsbrukere og går ikke videre får registrerings nr er endret 4. System feil. - Feltene må være utfylt med enten tall, bokstaver eller velges fra lister. Use case beskrivelse av E-post Use case Sender e-post Aktør Administrator Trigger Administrator registrerer/endrer ansatt, systemet sender e-post med relaterte opplysninger til avdelinger Pre betingelser Administrator ønsker en ny registrering/endring, systemet sender en e-post til avdelinger. Post betingelser E-posten blir sendt eller feilmelding oppstår Normal Administrasjonen: hendelsesflyt 1. Når administrator registrerer/endrer eller sletter en ansatt blir det sendt en automatisk e-post til forskjellige avdelinger med relatert opplysninger. 2. Systemet sjekker om e-posten blir sendt til avdelinger. Avdelingsbrukere: 1. Avdelingsbrukere får en e-post fra administrator med relatert opplysning om ansatt. 2. Avdelingsbrukere søker med reg nummer for å registrere/endre eller slette oppgavene de bør gjøre. Variasjoner 2. Systemet sjekker om e-post adressen er riktig. 2a. systemet sjekker om e-post oppsett er riktig, dersom det er feil går ikke systemet videre før oppsett blir endret. 5. System feil. Hovedprosjekt 2011 Side 20 av 20 Gruppe 4