INSTRUKTION TIL LEVERANDØR
Bilag 2 Kravspecifikation |
Samarbejdsplatformen |
Version 0.8 |
INSTRUKTION TIL LEVERANDØR
Nærværende bilag skal udfyldes af Leverandøren, jf. nedenstående retningslinjer.
Leverandørens eventuelle forbehold anføres i forbeholdslisten og skrives ind med track changes i selve bilaget i overensstemmelse med udbudsbetingelserne.
Det bemærkes, at Kontrakten (forstået som Kontrakten uden bilag) og Driftskontrakten (forstået som bilag 7.2, 7.3 og 7.4) er at betragte som minimumskrav, jf. udbudsbetingelserne. Leverandør skal derfor sikre, at eventuelle forbehold til nærværende bilag ikke udgør et forbehold overfor Kon- trakten (forstået som Kontrakten uden bilag) og Driftskontrakten (forstået som bilag 7.2, 7.3 og 7.4)
Leverandør skal som del af sit tilbud følge og besvare instruktioner, som er markeret med […]. For nærværende bilag betyder det, at Leverandør skal:
• Bilaget skal ikke udfyldes af Leverandør.
• Instruktion til anvendelse af bilaget fremgår af kapitel 1 (Indledning).
Om betydningen og vurderingen af Leverandørs besvarelse af instrukser og eventuelle forbehold til bilaget henvises til punkt 5.9 i udbudsbetingelserne.
Kravspecifikationens indhold 6
Bilag til Kontrakt og underbilag 6
Leverandørs besvarelse af Kravspecifikationen 8
Kommunernes nuværende løsning på skoleområdet og dagtilbudsområdet 11
Vision, mål og succeskriterier 12
3 Brugerrejser, begreber og information 15
Begrebsmodel og begrebsdefinitioner 16
3.2.1 Krav til begrebs- og informationsmodellen 19
Beriget konceptuel model (informationsmodel) 19
Løsningens funktionelle krav 34
5.3.3 Åbn, kommentér og skjul Opslag 36
Opsætning af Profil og Kontakter 41
5.4.3 Overblik over Samtykke og Tilladelse 46
5.6.1 Opret og rediger Begivenhed 50
5.6.2 Se Kalendere og kalendervisninger 52
5.6.3 Få et forslag til næste mulige mødetidspunkt 53
5.6.4 Indkald til skole hjem-samtale og forældresamtaler 53
5.6.6 Instruktioner til vikar 55
5.7.1 Registrer Komme/gå for Barn/Elev 56
5.11.2 Generelle krav til administration 66
5.11.5 Central administration 71
5.11.6 Administrer indstillinger 71
5.11.7 Opsæt Centralt-definerede Dashboards 72
5.11.8 Opsæt nye Widget-leverandører og Widgets 73
5.11.9 Kommunal Administration 74
5.11.10 Administrer Stamdata og indstillinger for Kommunen 74
5.11.11 Opsæt kommunalt-definerede Dashboard skabeloner 75
5.11.12 Frigiv nye Widget-leverandører og Widgets til brug i Kommunens Institutioner 76
5.11.13 Administration på den enkelte Institution 77
5.11.14 Administrer Stamdata og indstillinger for Institutionen 77
5.11.15 Opsæt Institutions-definerede Dashboards 78
5.12.1 Tilknytning til ny Institution 80
5.12.2 Bestyrelser, Kontaktforældre og forældreråd 81
5.12.4 Filtrering og sortering 82
5.12.7 Håndtering af aktindsigt 85
6.1.1 Offentlige strategier og generelle arkitekturprincipper 87
6.1.3 Tværgående egenskaber for Løsningen 95
6.1.4 Fremtidig tilpasning af Løsningen 96
6.1.5 Tekniske krav til Løsningen 97
Løsningens Integrationer 103
6.2.1 Integration med Snitflader 104
6.2.2 Oversigt over Snitflader 105
6.2.3 Udstilling af Widgets 106
Brugervenlighed og brugerinddragelse 107
6.3.1 Generelle krav 108
6.3.2 Brugerinvolvering 110
6.3.3 Design, æstetik og udtryk 112
6.3.4 Tilgængelighed 112
6.3.5 Meddelelser og hjælp 112
6.3.6 Tekniske krav 114
Lovkrav 115
6.4.1 ISO/IEC 27001 115
6.4.2 Persondataloven - Lov 429 af 31. maj 2000 116
Sikkerhed 117
7 Optioner 118
Spørgeskema 118
7.1.1 Håndter Spørgeskema 118
7.1.2 Besvar Spørgeskema 119
Kursus 120
7.2.1 Håndter kursus 121
Oversættelse af tekster 122
Foreslå flere tidsrum for en Begivenhed 122
Overblik over Dokumenter om et Barn eller Elev 123
Understøtte redigering af importerede filer 123
Standardskabeloner til brug ved Beskeder, Notifikationer, Dokumenter og Opslag 124
Personalisering af Dashboards 124
Non-funktionelle optioner 125
1 Indledning
Dette dokument er bilag 2.1 Kravspecifikation til Kontrakten, som omfatter KOMBITs Kravspecifika- tion af Løsningen og relaterede ydelser med tilhørende bilag, og udgør i sammenhæng med bilag
2.2 Løsningsbeskrivelse, den samlede Leverancebeskrivelse.
Leverandør skal ikke udfylde dette bilag, men besvare bilaget gennem udfyldelse af 2.2.B (Krav- skema og bilag 2.2 Løsningsbeskrivelse.
I nærværende bilag anvendes betegnelsen Leverandør, såfremt der er tale om oplysninger eller krav, der skal opfyldes ved afgivelsen af tilbuddet og således af alle Leverandører. Betegnelsen KOMBIT dækker over den kravstillende part, og anvendes konsekvent i stedet for ”bestiller” eller ”Kunde”.
Kravspecifikationen med tilhørende bilag anvender en række termer, hvoraf de fleste er for- retningsbegreber og navne på forretningsbegrebernes attributter. Disse er beskrevet i bilag
2.1.A Begrebs- og informationsmodel.
Derudover anvendes de generelle definitioner og begreber for Kontrakten. Disse er defineret i bilag 0 Definitioner. Endelig er brugeraktører defineret i afsnit 4.1 i indeværende dokument.
Ovennævnte begreber, termer og brugeraktører er skrevet med stort begyndelsesbogstav.
Kravspecifikationen indeholder en detaljeret beskrivelse af, hvordan de identificerede krav til Løs- ningen skal forstås og besvares:
• Kapitel 1 er en kort beskrivelse af indholdet af bilag 2 Kravspecifikation og bilagene til dette samt instruktion til Leverandør om, hvordan disse udfyldes og leveres.
• Kapitel 2 er et baggrundsafsnit, der introducerer KOMBITs og Kommunernes behov for en fremtidig løsning. Afsnittet er baggrundsviden og beskriver ikke den konkrete Løsning, der skal leveres under Kontrakten.
• Kapitel 3 beskriver de begreber og informationer, som kendetegner forretningsområdet, og dermed danner baggrund for Løsningen. I afsnittet indgår brugerrejser og personaer ligele- des.
• Kapitel 4 beskriver Løsningens aktører og kontekst.
• Kapitel 5 angiver KOMBITs funktionelle krav til Løsningen, og indeholder indledningsvist en overordnet beskrivelse af de forretningsmæssige ambitioner med Løsningen.
• Kapitel 6 angiver KOMBITs ikke-funktionelle krav til Løsningen.
• Kapitel 7 beskriver de optioner som Leverandøren skal tilbyde
Bilag til Kontrakt og underbilag
Nedenfor er angivet sammenhængen mellem Kontrakten, bilag 2 Kravspecifikation og relevante bilag:
Bilag 2.1 | Kravspecifikation med tilhørende bilag: |
Bilag 2.1.A | Begrebs- og informationsmodel |
Bilag 2.1.B | Integrationer og snitflader |
Bilag 2.1.C Regler (decisions models) – Ikke medsendt til review | |
Bilag 2.1.D | Personas |
Bilag 2.1.E | Brugerrejser |
Bilag 2.1.F | Rettighedsmatrix - Ikke medsendt til review |
Bilag 2.1.G | Spørgeskemaundersøgelse (forældre) - Ikke medsendt til review |
Bilag 2.1.H | Indhold på Hjemmesider- Ikke medsendt til review |
Bilag 2.1.I | Brugstal for SkoleIntra- Ikke medsendt til review |
Bilag 2.1.J | Aftale set-up omkring Widgets - Ikke medsendt til review |
Alle krav er i Kravspecifikationen angivet ved et unikt nummer baseret på det afsnit kravet er place- ret i, og vil være angivet i tabeller som den følgende:
Krav[#] | [Navn] | ||
Kategori: | Type: | ||
Beskrivelse: | |||
Kravtabellen er opbygget som følger:
• I øverste række er angivet et unikt nummer samt et navn for kravet.
Kategori er en angivelse af, om kravet er:
• Minimumskrav, forkortet ”MK” (opfyldes et minimumskrav ikke, er tilbuddet ikke kon- ditionsmæssigt)
• Krav, forkortet ”K”
• Option, forkortet ”O”
• Type er en inddeling af kravet i følgende områder:
• Funktionelt krav (forretningskrav).
• Ikke-funktionelle krav (løsningsorienterede krav).
• Beskrivelse indeholder en tekstuel beskrivelse af kravet.
Der henvises i øvrigt til udbudsbetingelserne.
De funktionelle krav til Løsningen er beskrevet som use cases kombineret med egentlige krav.
Use cases tager udgangspunkt i Kommunernes forretning og intentionen med dem er at udstikke en retning for udviklingen af Løsningen, med det rum for fortolkning, som anses for at være nød- vendig for at give mulighed for en nutidig og fremtidssikker implementering.
En use case skal forstås som en specificering af, hvad Løsningen skal understøtte på et funktionelt niveau, men ikke en specificering af, hvordan dette rent faktisk implementeres i Løsningen. Det be- tyder med andre ord, at use casene er formuleret sådan, at de ikke tager stilling til, hvorledes Løs- ningen rent faktisk skal realiseres, men beskriver udvalgte, væsentlige dele af Kommunernes be- hov og forventninger til Løsningen. De skal således ikke forstås som en udtømmende liste over specifikke funktioner i selve Løsningen.
En use case vil altid, uden undtagelse, være koblet til et krav og kan ikke i sig selv være et krav. Use cases er angivet i den faste use case-skabelon vist nedenfor.
Use case nr. [Use casens unikke ID] | Navn [Use casens unikke navn] | |
Baseret på følgende lovgivning [Er udfyldt, hvis use casen er knyttet til be- stemt lovgivning] | Igangsættende ak- tører [Den aktør der igang- sætter use casen, f. eks. Sagsbehandler] | |
Formål, beskrivelse og afgrænsning | [Beskriver use casens formål og eventuelt afgrænsning] | |
Udløsende begiven- hed | [Beskriver en udløsende forretningshændelse] | |
Startbetingelser | [Beskriver de forudsætninger, der skal være til stede for at use ca- sen kan opfylde det ønskede forretningsmæssige resultat] | |
Handlinger | ||
[Beskriver den konkrete forretningsmæssige funktionalitet som Løsningen skal understøtte] | ||
Slutresultat | [Beskriver det ønskede forretningsmæssige resultat som use casen skal af- stedkomme] | |
Alternativt: | ||
[Hvis aktøren skal kunne afvige fra use casens primære handlinger beskrives det her. Hvert alternativ refererer til den handling den er alternativ til, ved at anføre handlingens nummer med efterstillet bogstav. Alternative forløb, der ikke hører til et enkelt handlingstrin, angives med * efterfulgt af bogstav] | ||
Sluttilstand | [Beskriver de forretningsobjekter som har ændret status pga. use casen] | |
Bemærkninger: | ||
[Indeholder evt. relevant information, som ikke er direkte del af use casen] | ||
Use case-skabelon
Leverandørs besvarelse af Kravspecifikationen
Leverandørs besvarelse af Kravspecifikationen skal ske henholdsvis gennem udfyldelsen af bilag
2.2.B Kravskema og bilag 2.2 Løsningsbeskrivelse.
Bilag 2.2.B Kravskema indeholder de samlede minimumskrav og krav fra bilag 2.1 Leverandøren skal i kravskemaet markere opfyldelsen af kravene. Dette gør Leverandør ved for hvert krav (dog ikke minimumskrav) i kravskemaet svarende til nedenstående Tabel 1 at angive, i hvilket omfang det er opfyldt.
Kravnummer | Titel | Kravkategori | Helt opfyldt | Delvist opfyldt | Xxxx opfyldt | Kommentar | Leverandørens reference til Løsningsbeskrivelsen |
1 | Titel | K | |||||
3 | Titel | MK | |||||
4 | Titel | O |
Følgende retningslinjer gælder ved udfyldelse af kravskemaet:
• Xxx Xxxxxxxxxx og dennes Løsningsbeskrivelse imødekomme det pågældende krav, angi- ves ”Helt opfyldt”.
• Xxx Xxxxxxxxxx og dennes Løsningsbeskrivelse delvis imødekomme det pågældende krav, angives ”Delvist opfyldt”. Angives ”Delvist opfyldt”, skal Leverandør i kommentarfeltet specificere, hvorfor kravets opfyldelse kun er delvis.
• Kan Leverandør ikke imødekomme det pågældende krav, angives ”Ikke opfyldt”. Angives ”Ikke opfyldt”, er kommentarer ikke nødvendige.
• Hvis Leverandør i en kommentar foretager konkrete referencer, f. eks. til et andet bilag, skal referencen være konkret, specifik og nem at finde.
• Det er ikke muligt at angive eller kommentere minimumskrav, og manglende opfyldelse af disse vil medføre, at tilbuddet ikke er konditionsmæssigt jf. ovenfor og udbudsbetingel- serne. Minimumskrav er derfor også markeret gråt og kan derfor ikke udfyldes.
• Leverandør må ikke ændre eller udfylde de med gråt markerede celler
Bilag 2.2 (Løsningsbeskrivelse) er Leverandørs beskrivelse af den tilbudte Løsning, og en beskri- velse af, hvordan KOMBITs krav i bilag 2.1 vil blive opfyldt. Løsningsbeskrivelsen udarbejdes som angivet i bilag 2.2 Løsningsbeskrivelse. Der er i forbindelse med udvalgte krav angivet, at Leveran- dør i særlig grad skal beskrive, hvordan kravet opfyldes i bilag 2.2 Løsningsbeskrivelse.
Ønsker Leverandør at vedlægge dokumenter til Løsningsbeskrivelsen, bør disse angives som bilag med fortløbende nummerering, og der skal i Løsningsbeskrivelsen refereres til relevante bilag. Re- ferencen skal være konkret, afgrænset og nem at finde med sidetal og afsnitsnummer/overskrift. Er den ikke det, ignoreres referencen i tilbudsvurderingen.
2 Baggrund, vision og mål
Dette kapitel indeholder en introduktion til baggrunden, visionen og målene for Løsningen.
Regeringen og KL aftalte i juni 2014, som led i aftalen om kommunernes økonomi for 2015, at rea- lisere initiativet om en brugerportal for folkeskolen (BPI). Aftaleparterne var endvidere enige om, at dagtilbudsområdet tillige skulle være understøttet for så vidt angår kommunikation. Som opfølgning herpå blev der indgået en aftale om konkretisering af det fælles brugerportalsinitiativ i oktober 2014 mellem Undervisningsministeriet, Finansministeriet, Ministeriet for Integration, Ligestilling og Soci- ale Forhold, Økonomi- og Indenrigsministeriet og KL.
BPI er en fælles digital udviklingsplan for folkeskolen, der inkluderer en ny fælles infrastruktur og et kommunalt ansvar for anskaffelse af lokale løsninger, som digitalt understøtter kommunikation, læ- ring og trivsel. Initiativet skal således understøtte målene i folkeskolereformen og bringe den digi- tale folkeskole et stort skridt videre ved at etablere tidssvarende digitale løsninger.
Ved at understøtte dagtilbudsområdet for så vidt angår kommunikation bliver der tale om en fælles løsning for folkeskole- og dagtilbudsområdet, hvor børn, unge og deres forældre vil opleve, at kom- munen stiller en sammenhængende kommunikationskanal til rådighed på tværs af de tilbud, som familien anvender i dagligdagen. Det pædagogiske og administrative personale vil opleve at få en moderne og tidssvarende løsning, der understøtter kommunikationen i det daglige.
Aftalen betyder, at kommunerne frem mod skolestart i 2016/2017 skal anskaffe Læringsplatforme, der understøtter læreprocesser i folkeskolen. Kommunerne skal således hver især indkøbe og im- plementere en læringsplatform, som skal understøtte folkeskolens kerneprocesser i form af Elever- nes læring og det pædagogiske personales tilrettelæggelse, gennemførelse og evaluering af læ- ringsforløb. Derudover skal kommunerne indkøbe en Samarbejdsplatform, som blandt andet skal afløse det eksisterende SkoleIntra og sikre én indgang for forældre til information om Børn og Ele- ver i henholdsvis skole- og på dagtilbudsområdet.
I aftalegrundlaget fremgår det, at der skal etableres en fællesoffentlige infrastruktur både for Læ- ringsplatforme såvel som Samarbejdsplatformen, som skal gøre brug af UNI-Login.
UNI-Login er et digitalt ID for børn, unge og ansatte på Institutioner, og det er aftalt, at det skal ud- vides til ligeledes at kunne benyttes af forældre. UNI-login indgår som en del, som STIL er i gang med at videreudvikle hvorfor kravspecifikationen adresserer UNI-logins fremtidige funktionalitet fremfor eksisterende.
Kommunernes anskaffelse af Samarbejdsplatformen er tilrettelagt således, at der gennemføres et fælleskommunalt udbud for alle 98 kommuner i regi af KOMBIT. Alle 98 kommuner har tilsluttet sig løsningen for skoleområdet og 92 kommuner har tilsluttet sig for dagtilbudsområdet.
Det er kravspecifikationen for Samarbejdsplatformen, som indeværende dokument omhandler.
Samarbejdsplatformen skulle jf. aftalen mellem Regeringen og KL oprindeligt være implementeret i skoler og taget i brug af Forældre og Elever ved start af skoleåret 2018/2019, men parterne har i fælles overensstemmelse rykket dette til skoleårets start 2019/2020. Bevæggrunden for forsinkel- sen skal ses i lyset af det generelt stigende fokus på digital sikkerhed i samfundet samt den kom- mende databeskyttelsesforordning. Det har vist sig nødvendigt løbende at styrke sikkerheden i identifikationen og autentifikationen ved brug af digitale løsninger. I tillæg er der behov for en nær- mere afdækning af håndteringen af følsomme oplysninger.
Der er i EU-regi indgået aftale om en ny Persondataforordning, som dette projekt underlægges, når forordningen træder i kraft i 2019. Regler og procedurer, som beskrevet i forordningen, tænkes derfor allerede ind i kravspecifikationen og det øvrige udbudsmateriale. Det betyder, at når løsnin- gen går i drift vil løsningen skulle opfylde den nye persondataforordning. I det samlede tiltag skal der således findes en balance mellem de behov for blandt andet fleksibilitet og brugervenlighed, der må tilgodeses af hensyn til gennemførelsen af kommunikation mellem brugerne i folkeskolen og på dagtilbudsområdet og behovet for sikkerhed i løsningen. Parterne er derfor enige i, at der skal etableres en sikkerhedsarkittektur gældende for hele BPI, som forventes færdig i november 2016. Den godkendte sikkerhedsarkittektur vil blive vedlagt det samlede udbudsmateriale.
Kommunernes nuværende løsning på skoleområdet og dagtilbudsområdet
Samarbejdsplatformen skal udfase det eksisterende SkoleIntra, som i dag bliver benyttet af alle 98 danske kommuner på skoleområdet. SkoleIntra dækker over systemerne LærerIntra, ElevIntra, ForældreIntra, MobilIntra, Fællesnet og Skoleporten, som er en lang række forskellige moduler, der primært er rettet mod at understøtte det pædagogiske personales såvel som Elevens daglig- dag.
I perioden fra 2002 og frem til 2014 drev, solgte og supporterede Uni-C SkoleIntra på vegne af Skolesoft – et mindre dansk firma, som oprindeligt udviklede løsningen. I 2013 blev SkoleIntra overtaget af firmaet itslearning, og UNI-C (i dag Styrelsen for It og Læring- STIL) udtrådte af sam- arbejdet medio 2014.
SkoleIntra har i hele dens levetid fra 2000 til 2014 ikke været genstand for et udbud og et udbud skal derfor både sørge for, at området bliver konkurrenceudsat for at sikre en optimering af pris og kvalitet af løsningen og sikre, at udbudsreglerne bliver overholdt. KOMBIT har indgået en transiti- onsaftale med itslearning, om udfasning af systemet til landets kommuner, og aftalen forlænges til august 2019 for at sikre, at kommunerne har en fungerende løsning frem til den nye løsning tages i brug i august 2019.
It-understøttelsen af området for Dagtilbud er væsentligt mere fragmenteret end skoleområdet, og kendetegnet ved, at der er et stort antal forskellige leverandører, med løsninger udviklet ved hjælp af en række af forskellige teknologier. Markedet domineres af platformløsninger som f. eks. As- semble, BørneIntra og Famly. Platformenes fokus er primært redskaber til ind- og udkrydsning og registrering af børnenes aftaler samt dialog mellem forældre og personale. Der eksisterer dog en- kelte platforme til leg og læring, der retter sig mod dagtilbudsområdet. Infoba giver f. eks. mulighed for at udarbejde digitale pædagogiske læreplaner, mens forlaget MC Nordic leverer pædagogisk materiale rettet mod de mindste som en del af deres læringsplatform.
Der er ved siden af disse portaler udviklet mange mindre, men relevante komponenter, dvs. løsnin- ger der opfylder mere specialiserede behov knyttet til børnenes udvikling og læring eller til håndte- ring af klasser og undervisning. Der er f. eks. særlige programmer til støtte for ordblinde, lektie- støtte med videoinstruktion og chat, videoproduktion og lignende.
Vision, mål og succeskriterier
Projektets målsætning er at levere en moderne løsning med en høj grad af innovation og med en udpræget grad af brugervenlighed. Projektet er bevidst om, at Løsningen vil blive benyttet af et meget stort antal brugere med forskellige it kompetencer og af samme årsag er en af målsætnin- gerne for projektet, at Samarbejdsplatformen bliver så intuitiv og let at bruge som muligt, og at langt de fleste brugere vil kunne tilgå løsningen uden et egentligt uddannelsesforløb.
Samarbejdsplatformens vision er at blive den fortrukne kommunikationsplatform, hvor Elever, børn i Dagtilbud (Børn i børnehave), forældre, Pædagogisk Personale og andre med tilknytning til folke- skole og Dagtilbud har adgang til relevante informationer og har mulighed for at kommunikere ind- byrdes.
KOMBIT og KL har med kommunal inddragelse udarbejdet et målhierarki for Samarbejdsplatfor- men, hvoraf de vigtigste mål er følgende:
1. På Samarbejdsplatformen skal brugerne hurtigt kunne skabe sig overblik, uanset om de går på løsningen via computeren, en telefon eller en tablet
2. Brugeren skal via få klik, og uanset hvor it-kyndig han eller hun er, kunne få hurtig adgang til de ønskede informationer
3. Løsningen skal give brugerne gode muligheder for at indgå i dialog, samarbejde og kom- munikere gennem både billeder, lyd og skrift
4. Informationer og data skal opbevares og formidles med udgangspunkt i fællesoffentlige principper og standarder for sikkerhed
5. Løsningen skal lette dagligdagen for alle Medarbejdere i kommunen ved f. eks. at gøre det nemt at planlægge aktiviteter og møder og booke Lokaler og andre Ressourcer
6. Leverandøren skal sørge for stabil drift af løsningen, der skal være bygget, så den er let at vedligeholde og kan videreudvikles løbende
7. Samarbejdsplatformen skal have stor udbredelse i de Skoler og Dagtilbud, hvor den tilby- des, og mange leverandører skal finde det attraktivt at udvikle Widgets som kan udstilles på Samarbejdsplatformen
8. Kommunernes økonomi i projektet skal sikres ved, at KOMBITs business case for Samar- bejdsplatformen overholdes.
Samarbejdsplatformen forventes at opnå en række gevinster for Kommunerne heriblandt følgende:
1. Forældre vil opnå en sammenhængende brugeroplevelse på tværs af Institutioner og spare tid ved at få adgang til relevant information for alle børn ét sted
2. En fælles løsning vil være mere omkostningseffektiv både med hensyn til udbud, udvikling og drift
3. Aftalen med regeringen stiller ambitiøse krav til en ny løsning, som det vil være uforholds- mæssigt dyrt at tilvejebringe gennem flere mindre udbud
4. En landsdækkende løsning vil reducere kompleksitet og risici i folkeskolens samlede digitale systemlandsskab, da det vil betyde færre integrationer, som leverandørerne af digitale løs- ninger på andre områder, f. eks. læringsplatforme, vil skulle forholde sig til
Overordnet indebærer aftalen indgået om Brugerportalsinitiativet, at dagtilbudsområdet og folke- skolens styrker og faglighed skal fastholdes og udvikles gennem seks mål (tre for Dagtilbud og tre for folkeskolen):
Folkeskolen | Dagtilbudsområdet |
• Folkeskolen skal udfordre alle Elever, så de bliver så dygtige, de kan | • Fremme børns og unges trivsel, udvikling og læring gennem dag-, fritids- og klubtil- bud samt andre socialpædagogiske fritids- tilbud |
• Folkeskolen skal mindske betydningen af social baggrund i forhold til faglige resulta- ter | • Forebygge negativ social arv og eksklusion ved, at de pædagogiske tilbud er en inte- greret del af tilbuddene |
• Tilliden til og trivslen i folkeskolen skal styrkes blandt andet gennem respekt for professionel viden og praksis | • Skabe sammenhæng og kontinuitet mellem tilbuddene og gøre overgange mellem til- buddene sammenhængende og alderssva- rende udfordrende for børnene |
Samarbejdsplatformen bliver en kommunikationsløsning, der skal sikre et hurtigt overblik og stille relevante oplysninger til rådighed for brugerne. Der vil være en lang række forskellige brugere, der skal anvende Samarbejdsplatformen eksempelvis Pædagogisk personale, Elever, Forældre, skole- ledelse, UU-vejledere, samarbejdspartnere m.v.
Samarbejdsplatform skal således understøtte kommunikation og videndeling mellem alle målgrup- per i folkeskoler og på dagtilbudsområdet. Brugeraktørerne er nærmere beskrevet i kapitel 4 (Aktø- rer og kontekst).
Oplysninger hentes i Samarbejdsplatformens moduler, herunder Beskeder, Opslag, Kalender, Sik- ker fildeling, Galleri, Notifikationer, komme og gå samt administrationsbeskeder, Opslag og Kalen- der. Herudover vil Samarbejdsplatformen kunne udstille andre systemers brugergrænseflader f. eks. fra en Læringsplatform eller fra Google for Education, så pædagogisk personale og elever har én indgang til et overblik.
Samarbejdsplatformen skal understøtte de enhedstyper, som brugere i dag anvender (primært smartphones, tablets og computere) og baserer sig på åbne standarder, så det i videst muligt om- fang bliver muligt at bruge Samarbejdsplatformen fra moderne teknologiske enheder.
Samarbejdsplatformen er illustreret nedenfor. Bemærk at modellen kun indeholder eksempler på brugere, enheder og bagvedliggende systemer og således ikke skal opfattes som udtømmende og at infrastruktur og moduler er indeholdt under Samarbejdsplatformens-niveauet i figuren. Det er værd at bemærke, at Brugeren tilgår det samme Dashboard, men at det kan tage sig forskelligt ud, alt efter hvilken enhed Brugeren anvender. Fra en computer vil det give god mening at vise en ka- lender for en hel uge, mens man fra en smartphone givetvis bedre vil kunne overskue kalender for
en dag af gangen. Der kan også være moduler og Widgets med så kompleks funktionalitet at de ikke præsenteres på mindre skærme.
Figur 2 – En simplificeret model der giver overblik over system og brugere.
Løsningens Brugere anvender en række forskellige lokale løsninger i deres hverdag, i forhold til både administrative, kommunikative og undervisningsmæssige behov. Herunder er det eksemplifi- ceret for Elever og Pædagogisk Personale i Skoler. Nedenstående kan ikke tages til udtryk for væ- rende udtømmende, men alene give læserne et indtryk af mulige lokale løsninger.
Elever i Skoler forventes ved Løsningens idriftsættelse at benytte sig af følgende typer systemer i deres dagligdag;
• Læringsplatformen hvor deres undervisningsaktiviteter administreres
• Samarbejdsplatformen hvor de kommunikerer, læser Opslag og har overblik over deres Ka- lender
• Fildelingsløsning (f.eks. Google Drive eller Microsoft OneDrive) hvor de gemmer dokumen- ter og medier som de bruger i undervisningsaktiviteter1
• Samarbejdsværktøjer (f. eks. Google Apps for Education eller Microsoft Office 365 Educa- tion) der understøtter Elevernes undervisningsaktiviteter.
Pædagogisk Personale i Skoler forventes ved Løsningens idriftsættelse at benytte sig af følgende typer systemer i deres dagligdag;
• Læringsplatformen hvor de planlægger og styrer læringsforløb for deres Elever
• Samarbejdsplatformen hvor de kommunikerer, læser Opslag og har overblik over deres Ka- lender
• Skemalægningssystemer og kommunens administrative systemer hvor skema, arbejdstid, vikardækning mv. foregår
• Fildelingsløsning (f.eks. Google Drive eller Microsoft OneDrive) hvor de gemmer dokumen- ter og medier som deres Elever bruger i undervisningsaktiviteter2
• Samarbejdsværktøjer (f. eks. Google Apps for Education eller Microsoft Office 365 Educa- tion) der understøtter Elevernes undervisningsaktiviteter.
Administrative Medarbejdere bruger derudover en lang række systemer til administrationen af den samlede Institution. Fælles for disse er dog at de ikke vil blive en del af Samarbejdsplatformen, der til gengæld vil udstille brugergrænseflader fra Læringsplatforme, Fildelingsløsninger mv. der hjæl- per den enkelte Bruger til at få overblik.
3 Brugerrejser, begreber og information
I dette kapitel præsenteres brugerrejser, personaer, Begrebsmodel og Informationsmodel.
Personaer og brugerrejser har til formål at introducere Brugere og deres anvendelse af systemet, for at give læseren en kontekstuel forståelse af Løsningen.
Begrebsmodel og Informationsmodel anvendes til at forstå forretningsområdet, og danner grundlag for udarbejdelsen af Løsningens use cases, som beskrives i kapitel 5 og til modellering af Løsnin- gens forretningsarkitektur i kapitel 6.
Der er til projektet udarbejdet personaer og brugerrejser. Personaer er en metode til at anskuelig- gøre de typiske Brugere af Løsningen, og er defineret som Personer med navn, alder, sociale for- hold, interesser m.v. Personaerne dækker ikke alle typer Brugere i Løsningen, men skal agere som referencepunkt for udviklingen af Løsningen, så det i højest muligt omfang sikres at Løsnin- gen implementeres med de vigtigste Brugeres karakteristika for øje.
Xxxxxxxxxxxxxx beskriver en række typiske scenarier der vil udspille sig i Løsningen, og er baseret på personaerne. Brugerrejserne omfatter ikke al funktionalitet i Løsningen, men er udarbejdet for at give et indblik i hvordan de forskellige Brugere vil anvende Løsningen, og hvordan interaktion mel- lem Brugere og Løsning vil være.
Personaer kan ses i bilag 2.1D og brugerrejser i bilag 2.1.E.
1 Alle dokumenter og medier der ikke indeholder personfølsomme oplysninger skal ligge i Institutionens/Kommunens Fildelingsløsning, mens personfølsomme dokumenter og medier håndteres af Samarbejdsplatformen.
2 Alle dokumenter og medier der ikke indeholder personfølsomme oplysninger skal ligge i Institutionens/Kommunens Fildelingsløsning, mens personfølsomme dokumenter og medier håndteres af Samarbejdsplatformen.
Begrebsmodel og begrebsdefinitioner
Begrebs- og Informationsmodellen fokuserer på at afgrænse og introducere konteksten på et for- retningsmæssigt niveau. I designspecifikationsfasen anvendes begrebs- og informationsmodellen til datamodellering, brugergrænseflader og konsistente snitflader til systemaktørerne.
Begrebsmodellen er udarbejdet på baggrund af workshops med Brugere samt med udgangspunkt i Referencearkitekturen for Brugerportalinitiativet. I dette afsnit præsenteres en overordnet begrebs- model der har til formål at introducere Læseren for kravspecifikationens kontekst. I bilag 2.1.A kan læses en mere detaljeret Begrebsmodel.
Informationsmodellen beskriver de forretningsobjekter som Løsningen skal understøtte, samt for- retningsobjekternes relationer og informationsindhold. Informationsmodellen er under udarbejdelse og udsendes ikke som del af reviewfasen.
Herunder ses den overordnede begrebsmodel for Løsningen, som er efterfulgt af en tekstuel be- skrivelse af de enkelte begreber.
Figur 1: Overordnet begrebsmodel for Løsningen. Bemærk at alle relationer mellem begreber (markeret med en fyldt sort pil) som udgangspunkt angiver et ”har” forhold med mindre andet er angivet (eksempelvis Kommune ”har” Forvaltning). Pile med fyldt hvid pil angiver at et Begreb er en type af et andet Begreb (eksempelvis at Dagtilbud er en type Institution).
Tabel 2: Beskrivelse af begreber i Begrebsmodellen
Forretnings- objekt | Beskrivelse |
Bruger | Dækker alle Personer der oprettes som Brugere på Løsningen, og derved har mulighed for at logge ind. Figuren ovenfor indehol- der de centrale aktørtyper der er beskrevet herunder. Brugeraktø- rerne kategoriseres i Aktører, som er beskrevet yderligere i afsnit 4.1. |
Pædagogisk personale | Dækker alle Medarbejdere i Institutioner, der arbejder pædago- gisk med Børnene, herunder pædagoger og lærere. |
Værge | Repræsenterer de voksne, der har Værgemål for et Barn eller en Elev, og vil typisk være Forældre, men kan dog også være andre voksne, der har fået Værgemål for Barnet. |
Elev | Et Barn indskrevet på en Skole. |
Barn | Et Barn indskrevet i et Dagtilbud, typisk i alderen 0-6 år. |
Komme/Gå | Registrering af hvornår et Barn eller en Elev i en SFO/SFO2, er ankommet eller har forladt Institutionen/Afdelingen, samt oplys- ninger om henteansvarlige og fraværsmarkering. |
Besked | En Besked er en tekstuel meddelelse sendt fra én Afsender til en eller flere Modtagere. Beskeder kan videresendes, besvares m.v. |
Opslag | Et Opslag er en nyhed, en artikel eller lignende som publiceres til en gruppe Modtagere, eksempelvis alle Forældre på en Skole. Opslag kan kommenteres efterfølgende. |
Dokument/fil | Typisk vil dokumenter og filer ligge i Skolernes/Kommunernes egne fildelingsløsninger, men visse vil dog optræde i Løsningen, herunder Dokumenter med personfølsomt indhold der kan opret- tes i Løsningen. |
Kalender | Alle Brugere, Hold/Klasse/Gruppe, Ressourcer og Lokaler har en Kalender, hvortil der kan tilknyttes Begivenheder. Der kan endvi- dere vises Kalendere baseret på sygdom, ferieanmodning m.v. |
Begivenhed | En Begivenhed er typisk en lektion eller et møde, og består af et tidspunkt, et tidsrum, en placering (gennem tilknyttet Lokale), et antal deltagere (tilknyttede Brugere) samt eventuelt nødvendige Ressourcer (tilknyttede Ressourcer som eksempelvis it-udstyr, buskort m.v.) |
Skole | En Skole defineres ved at være styret af en skoleleder, og kan findes på en eller flere matrikler. |
Dagtilbud | Et Dagtilbud er for Børn i 0-6 års alderen og kan typisk være en Børnehave, Dagpleje, Vuggestue eller Integreret Institution. |
Andre Instituti- oner/ tilbud | Der findes en række Institutioner og tilbud som ikke kan ses som hverken en Skole eller et Dagtilbud, herunder eksempelvis ung- domsskoler og musikskoler, samt Institutioner der varetager un- dervisning uden at være en Skole (eksempelvis i de tilfælde hvor gymnasier har overtaget ansvaret for 10-klasses undervisning). |
Om- råde/klynge | Institutioner er ofte samlet i større administrative enheder, hvor et antal Skoler eller Dagtilbud hænger sammen i et administrativt fællesskab. Benævnelserne for disse varierer fra Kommune til Kommune, men ofte samles Dagtilbud i klynger eller områder, og Skoler i områder. |
Forvaltning og Kommune | En Institution eller et Område/Klynge er altid en del af en bestemt Forvaltning i en given Kommune, eksempelvis Børne- og Unge- forvaltningen i København Kommune. |
Gruppe (Klasse, hold m.v.) | Begrebet dækker de samlinger Brugere optræder i, og kan samlet set anskues som værende Grupper af forskellige typer. En Klasse er en fast Gruppe over lang tid, mens Eleverne kan tilknyttes Hold får kortere forløb og Brugere generelt kan grupperes i Grupper for at håndtere dem samlet. Brugere knyttes sammen i samlinger som eksempelvis; • Elever i 4.A • Forældre til Elever i 4.A • Engelsklærere i en bestemt Kommune • 5 Elever der arbejder sammen på et projekt Rettigheder kan dermed styres på Gruppe-niveau. |
3.2.1 Krav til begrebs- og informationsmodellen
KOMBIT udarbejder og vedligeholder Begrebs- og Informationsmodellen, som vil være udgangs- punkt for udarbejdelsen af den fysiske datamodel for Løsningen.
Krav # 1 Begrebs- og informationsmodel | |||
Kategori: | (K) | Type: | Non-funktionelt |
Beskrivelse: | Leverandøren skal i sin løsningsbeskrivelse beskrive mulighederne for at Løs- ningens fysiske datamodel fremadrettet kan tilpasses KOMBITs ændringer i Begrebs- og informationsmodellen; herunder tilføjelse af nye begreber, relati- oner og informationer (attributter). | ||
Beriget konceptuel model (informationsmodel)
Se bilag 2.1.A for figurer og attributbeskrivelser. Bemærk at informationsmodellen er under udar- bejdelse, og derfor kun er kravsat i dette afsnit. Informationsmodellen vil blive en del af bilag 2.1.A.
Den udarbejdede informationsmodel er en konceptuel model for Løsningen, beriget med centrale attributter, samt evt. uddybelse af begreberne. Informationsmodellen er udarbejdet som UML klas- sediagram, dog uden egentlig normalisering3.
Modellen viser Løsningens centrale begreber og deres attributter på et overordnet plan. Modellen egner sig som udgangspunkt for dataudveksling, men en fysisk datamodel må nødven-
digvis udarbejdes som del af udviklingen for at håndtere normalisering m.v. Modellen er et udkast,
som Leverandøren benytter som udgangspunkt herfor.
Krav # 2 Løsningens datamodel | |||
Kategori: | (K) | Type: | Non-funktionelt |
Beskrivelse: | Løsningens datamodel skal udarbejdes på baggrund af informationsmodellen og Leverandøren skal dokumentere og vedligeholde en mapning mellem de to. Såfremt Leverandøren i Kontraktens løbetid mener, at der er behov for at æn- dre informationsmodellen på grund af den fysiske datamodel, skal ændrin- gerne varsles og godkendes af KOMBIT. | ||
4 Aktører og kontekst
Løsningen indgår i en kontekst af forskellige it-systemer og Brugere, som har forskellige opgaver i forhold til Løsningen og derfor beskrives som forskellige aktører. De enkelte aktører er beskrevet i dette kapitel.
Aktørerne i Løsningen er opdelt i:
• Brugeraktører, dvs. Brugere som via brugergrænsefladen arbejder med Løsningen.
• Systemaktører/eksterne systemer, dvs. andre it-systemer eller services, som skal interagere med Løsningen.
En Brugeraktør er en rolle i forhold til Løsningen og skal ikke forstås som stillingskategorier. En an- sat i Kommunen kan således have flere roller og vil dermed kunne repræsentere mere end én ak- tør. Da den administrative organisering i Kommunerne derudover kan være forskellig skal det her understreges at aktørbetegnelserne ikke skal tages bogstaveligt i forhold til Kommunernes organi- sation.
De forskellige Brugeraktører er beskrevet herunder.
3 Informationsmodellens metodemæssige opbygning kan ses i KOMBITs Metodehåndbog for Begrebsmodeller, Informationsmodeller og Begrebsdefinitioner (xxxx://xxx.xxxxxx.xx/xxxxx/xxxxxxx/xxxxx/xxxx_xxxxxx/xxxxxxxxx/Xxxxxxxxxxxx/Xxxxxxxxxxxxxx%00xx- grebs%20og%20informationsmodeller.pdf)
Figur 2: Brugeraktører
Navn | Pædagogisk personale |
Rolle | Pædagogisk personale dækker lærere, pædagoger og andre der ar- bejder med Xxxx og Xxxxxx samt undervisning heraf. Pædagogisk personale kan både være i fast ansættelse eller som tilknyttet som vikar. Pædagogisk personale dækker derfor størstedelen af ansatte i Dagtilbud og på Skoler. For det Pædagogisk personale vil Løsningen være deres primære it- applikation i forhold til at kommunikere med Forældre (og Værger) samt Medarbejdere på Skolen. |
Xxxxxx | Xxxxxxxxxx personale er en meget bred Brugeraktør, der spænder fra lærer til pædagoger og ledere, hvorfor deres ansvar også varierer fra undervisning til pasning af Xxxx og ledelse af Institutioner. |
Kategori | |
Organisatorisk placering | Pædagogisk personale vil typisk være ansat på en bestemt Institu- tion, men kan også være ansat kommunalt med behov for at arbejde på flere Institutioner. |
Antal/Kapacitet | 148.000 |
Navn | Elev |
Rolle | Elev dækker alle Børn der går i Skole, og herunder hørende tilbud som SFO og fritidsklub (ofte kaldet SFO 24), i Kommunen. Gruppen er præget af stor diversitet bestående af Elever i Indskoling op til Ele- ver i Udskoling. Deres it-forudsætninger er vidt forskellige, lige som deres sproglige, faglige og sociale forudsætninger dækker hele spekteret i Skolen. |
Ansvar | |
Kategori | |
Organisatorisk placering | En Elev er tilhørende en Skole, samt evt. en hertil hørende SFO eller Klub/SFO 2. |
Antal/Kapacitet | 560.000 |
Navn | Barn |
Rolle | Barn dækker alle Børn der er indskrevet i et Dagtilbud (Vuggestue, Børnehave, Integreret Institution eller Dagpleje). Børn i Dagtilbud vil for de flestes tilfælde ikke blive oprettet som selv- stændige Brugere i Løsningen, men få en Profil indeholdende Stam- data i Løsningen, håndteret af Barnets Værge. Der kan dog være til- fælde hvor man ønsker at lade de ældre Børnehavebørn få adgang til Løsningen, hvorfor de kan optræde som Brugere. |
Ansvar | |
Kategori | |
Organisatorisk placering | Et Barn er tilknyttet et Dagtilbud. |
Antal/Kapacitet | 230.000 |
Navn | Værge |
Rolle | Værge dækker alle myndige Personer med myndighed over eller an- svar for en Elev eller et Barn i en af Kommunens Institutioner. Vær- ger dækker ligeledes støttefamilier. Værger vil som oftest være For- ældre til et Barn eller en Elev. Værger er dog en diverse Gruppe, både ift. it-kompetencer og ambi- tion for involvering i deres Børns gang i Kommunens Institutioner. Samtidigt er der en gruppe Forældre med anden sproglig baggrund, vanskeligheder ved at begå sig skriftligt eller andre udfordringer som kan betyde, at de afviger fra den gennemsnitlige Værge ifm. brug af Løsningen. |
Ansvar | |
Kategori |
4 Stort set alle fritidsklubber er organiseret som SFO 2, hvilket betyder at de er underlagt folkeskolelovgivningen fremfor dagtildslovgiv- ning. Det betyder endvidere at det samlede ansvar for Elevens dag ligger hos Skolelederen, og ikke er delt mellem to ledere og lovgiv- ninger. Der er dog ingen praktisk forskel ifm. Løsningen.
Organisatorisk placering | En Værge kan have Børn i en eller flere Skoler og et eller flere Dag- tilbud (på tværs af kommuneskel). |
Antal/Kapacitet | 1.100.000 |
Navn | Relateret Person |
Rolle | Relaterede Personer til Barnet kan eksempelvis være en bedstefor- ælder, en stedfar/-mor, Forælderens samlever eller en ven af fami- lien. Værgen er ansvarlig for den relaterede persons rettigheder ift. Barnet/Eleven. Til et Barn Relaterede Personer kan have forskellige behov ift. Løs- ningen. Nogle Relaterede Personer er en del af Løsningen primært for at Medarbejdere har et overblik over Barnet/Elevens situation, mens andre agerer på Barnets/Elevens vegne i en Værge-lignende funktion (eksempelvis et Barns mormor der står for al det praktiske omkring Barnet). Relaterede Personer vil derfor have adgang til for- skellig funktionalitet i Løsningen og have differentierede rettigheder. |
Ansvar | |
Kategori | |
Organisatorisk placering | En Relateret Person kan være relateret til flere Børn i flere Institutio- ner, optræde som anden Brugeraktør (f. eks. som Pædagogisk per- sonale på anden Skole) m.v. |
Antal/Kapacitet | 500.000 |
Navn | Officielt Tilknyttet Person |
Rolle | I visse tilfælde tilknyttes en person officielt til Barnet, og denne per- son behøver rettigheder ift. Barnet, eksempelvis: • Pædagog med døgnansvar for et Barn på et hjem • Aflastningsfamilie (person) med ansvar for Barnet på be- stemte dage Hvilke rettigheder personen får bestemmes og sættes af Institutions Administratoren i samarbejde med rette myndighed. |
Ansvar | |
Kategori | |
Organisatorisk placering | En officielt tilknyttet person vil som oftest være ansat af Kommunen. |
Xxxxx/Kapacitet | 11.000 |
Navn | Vejleder |
Rolle | På de enkelte Institutioner er tilknyttet en lang række Vejledere. Gruppen spænder meget bredt, og omfatter bl.a. • It-vejledere • Læringsvejledere/skolebibliotekarer • Inklusionsvejledere • Læsevejledere • Matematikvejledere • Bevægelses- og motionsvejledere • UU-vejleder Vejledere vil ofte have behov for, at kunne kommunikere med og til flere forskellige Brugere, Hold og Klasser på tværs af Institutionen el- ler endda flere Institutioner. Derudover kan der være specifikke be- hov for de enkelte Vejledere, men disse vil ofte omhandle adgang til Widgets. En UU-vejleder vil eksempelvis skulle have adgang til en Elevs Elevplan og portefølje for bedst at rådgive omkring en Elev med særligt fokus. De første seks typer Vejledere vil typisk være ansat i en Institution, mens UU-vejledere oftest er ansat i tværkommunale organisationer og arbejder på tværs af Institutioner i flere Kommuner. |
Ansvar | |
Kategori | |
Organisatorisk placering | Vejledere vil typisk være ansat på en bestemt Institution, men kan også være ansat kommunalt med behov for at arbejde på flere Insti- tutioner. |
Antal/Kapacitet | 17.000 |
Navn | Eksterne aktører |
Rolle | Som del af folkeskolereformen er Skolerne fremover forpligtet til indgå i samarbejder med eksterne aktører disse aktører kan f. eks. være lokale idræts-, kultur- og foreningsliv, herunder de kommunale musik- og kulturskoler, ungdomsskoler og det lokale erhvervsliv, lige- som eksterne medlemmer af en Skolebestyrelse også falder ind un- der Eksterne Aktører. I forbindelse med Løsningen vil disse aktører skulle benytte Løsnin- gen til at kommunikere med Elever fortrinsvis igennem Opslag. |
Ansvar | |
Kategori | |
Organisatorisk placering | Ungdomsskolen, musikskole, billedskole, Pædagogisk Central/ Pæ- dagogisk udviklingscenter, hører under Kommunen, men foreninger, kulturinstitutioner og virksomheder er selvejende. |
Antal/Kapacitet | 17.000 |
Navn | Medarbejder i Forvaltning |
Rolle | I forbindelse med Løsningen har de kommunale Forvaltninger også behov for adgang til at kommunikere med Brugeraktørerne. I Forvaltningen findes tre Grupper, der har behov for adgang: • Faglige konsulenter • Generalist konsulenter • PPR-medarbejdere Faglige konsulenter tilbyder faglig sparring og vejledning indenfor særlige områder. En læsevejleder kan eksempelvis bede om råd og vejledning hos en læsekonsulent, hvis læsevejlederen er i tvivl om, hvordan læsevejlederen skal støtte en Elev gennem Pædagogisk per- sonale. Et andet eksempel kunne være en AKT-konsulent, der tilby- der faglig sparring ifm. trivselsproblematikker. Generalist konsulenter har behov for at kommunikere i bredere for- stand til Pædagogisk personale og Ledere om evalueringer af projek- ter, mødeindkaldelser til arrangementer samt planlægge og koordi- nere. PPR-medarbejdere eksempelvis en skolepsykolog, har behov for at kunne være i dialog med Værger, Elev og Pædagogisk personale om Indstillinger og særlig tilrettelagte forløb. PPR-medarbejdere vil typisk høre under Forvaltningen, men kan dog også være ansat direkte i en Institution. |
Ansvar | |
Kategori | |
Organisatorisk placering | Medarbejdere i Forvaltning er tilknyttet Kommunen og ofte placeret på Rådhuset. |
Xxxxx/Kapacitet | 1600 |
Navn | Leder |
Rolle | På Institutioner er der tilknyttet en række Ledere, der står for den daglige ledelse. Gruppen omfatter: • Områdeledere • Skoleledere • Ledere af Dagtilbud • Afdelingsledere (SFO, indskoling, etc.) • Distriktsskoleledere Ledere af Dagtilbud kan være Klyngeleder dvs. de er Ledere for en række Dagtilbud, ligesom Skoleledere kan være ansvarlige for et om- råde bestående af flere Skoler. Ledere i Institutioner er i forbindelse med Løsningen særligt interes- serede i overblik over flere Institutioner samt aggregerede informatio- ner om f. eks. Brugstal på tværs af Institutioner Lederen er ansvarlig for. |
Ansvar | |
Kategori |
Organisatorisk placering | En Leder kan være tilknyttet en eller flere Institutioner. |
Xxxxx/Kapacitet | 6600 |
Navn | Administrativ Medarbejder |
Rolle | En Administrativ Medarbejder er typisk en skolesekretær, der er an- svarlig for at oprette Brugere i Institutionens Administrative system og varetage opgaver i forbindelse med indberetninger om Børn og Ele- ver samt en række andre administrative opgaver, som kræver adgang til at lave Opslag og kommunikere igennem Beskeder og Kalender med andre Brugere af Løsningen. |
Ansvar | |
Kategori | |
Organisatorisk placering | Den Administrative Medarbejder er tilknyttet en Institution eller en Gruppe af Institutioner (Institutionsgrupper: Områder, Klynger eller Di- strikter eksempelvis). |
Antal/Kapacitet | 1700 |
Navn | Institutionsadministrator |
Rolle | Institutions Administrator opsætter og vedligeholder oplysninger og indstillinger i Løsningen, der er specifikke for den enkelte Institution. |
Ansvar | Institutions Administratoren har ansvaret for at • opsætte og vedligeholde Institutionsspecifikke oplysninger og systemindstillinger. • opsætte og vedligeholde Institutionsspecifikke opsætninger |
Kategori | |
Organisatorisk placering | Den enkelte Institution |
Xxxxx/Kapacitet | 1600 |
Navn | Kommunal administrator |
Rolle | Den Kommunale Administrator opsætter og vedligeholder kommune- specifikke oplysninger og indstillinger i Løsningen. |
Xxxxxx | Xxx Kommunale administrator har ansvaret for at • opsætte og vedligeholde kommunespecifikke oplysninger og systemindstillinger. • opsætte og vedligeholde kommunespecifikke opsætninger |
Kategori | |
Organisatorisk placering | Kommunal Forvaltning |
Antal/Kapacitet | 300 |
Navn | Central administrator |
Rolle | Den Centrale Administrator opsætter og vedligeholder centrale sy- stemindstillinger og Stamdata i Løsningen, dvs. data gældende for alle Kommuner. Den Centrale Administrator opsætter og vedligeholder derudover en central skabelon for Dashboards til brug for de enkelte Institutioner. |
Ansvar | Den Centrale Administrator har ansvaret for at: • opsætte og vedligeholde centrale systemindstillinger • opsætte og vedligeholde centrale Stamdata • opsætte og vedligeholde Dashboard skabeloner • Vedligeholdelse af tekster i Løsningen |
Kategori | |
Organisatorisk placering | Leverandøren. KOMBIT skal også have mulighed for at påtage sig rollen. |
Antal/Kapacitet | 10 |
Navn | Andre Institutionsmedarbejdere |
Rolle | Der er en række øvrige Medarbejdere i en Institution, med behov for at kunne bruge Kalender, Beskeder, Opslag m.v. Der kan eksempel- vis være tale om Skoletandlæge, Sundhedsplejerske eller Teknisk administrativt personale. Teknisk administrativt personale dækker typisk rengøring, kantine, pedeller og it-support på Skoler. TAP´er vil have behov for at kunne tilgå Beskeder, Opslag og Kalender men har ingen pædagogiske el- ler undervisningsmæssige ansvar. Skoletandlæger og Sundhedsplejersker interagerer med Elever ifm. Indkaldelser, og har derfor også behov for at kunne tilgå Beskeder, Opslag og Kalender m.v. |
Ansvar | |
Kategori | |
Organisatorisk placering | Den enkelte Institution |
Antal/Kapacitet | 7500 |
KOMBIT gør opmærksom på at de angivne estimater (Antal/Kapacitet) i ovenstående beskrivelser er baseret på forventede antal Brugere og derfor forbundet med en vis usikkerhed. Estimaterne skal forstås som en hjælp til Leverandøren, og KOMBIT kan ikke holdes ansvarlig, såfremt det fak- tiske antal brugere viser sig anderledes.
Løsningen har behov for at integrere til en række eksterne systemer for at kunne understøtte Bru- geraktørernes behov. Eksterne systemer som initierer kommunikation med Løsningen via Snitfla- der betegnes som systemaktører.
Figur 3: Systemaktører
De forskellige systemaktører er beskrevet herunder.
Navn | Læringsplatforme |
Rolle | Læringsplatformene skal være omdrejningspunkt for en del af det daglige arbejde på Kommunens Skoler, der handler om Elevernes læringsproces. Der er defineret 5 områder, som Læringsplatforme skal understøtte: • Elevplan • Progression • Trivsel • Fælles mål • Læringsforløb Kommuner vil, såfremt der indgås aftale med leverandøren af en Læringsplatform og denne udvikler Widgets, kunne få udstillet disse 5 områder eller del-elementer af områderne i Løsningen. |
Ansvar | Kommune |
Kategori | |
Organisatorisk placering | Kommune |
Antal/Kapacitet | 98 (en per Kommune) |
Navn | Fildelingsløsninger |
Rolle | Institutioner anvender i dag en række forskellige fildelingsløsninger som OneDrive, Google Drive, lokale filservere mv. For at en Bruger kan skabe sig et overblik over Beskeder, Kalender samt filer fra en fildelingsløsning, understøtter Løsningen, at en Kommune kan indgå en aftale med leverandøren af filløsningen for at få udstillet en Widget indeholdende de filer Brugeraktøren har gemt i Kommunens fildelingsløsning. |
Ansvar | Kommune |
Kategori | |
Organisatorisk placering | Kommune |
Antal/Kapacitet | 98 kommuner, 4-10 forskellige systemer. |
Navn | Uni-Login |
Rolle | UNI-Login er Børn, Elever, Værger og Medarbejderes personlige lo- gin til systemer i undervisningssektoren. Uni-Login giver adgang til tjenester, læremidler og systemer fra en lang række leverandører. UNI-Login giver adgang til at logge ind med NemLog-in, således at Brugere enten kan bruge UNI-Logins eget login til at se visse dele af Løsningen, eller logge ind med NEMID for at få adgang til alle dele af Løsningen. |
Ansvar | Styrelsen for IT og Læring (STIL) |
Kategori | |
Organisatorisk placering | Styrelsen for IT og Læring (STIL) |
Antal/Kapacitet | 1 |
Navn | NemLog-in |
Rolle | Den fællesoffentlige NemLog-in /Web SSO komponent leverer en gratis log-in tjeneste, hvormed borgere og Medarbejdere i virksom- heder eller myndigheder kan logge på offentlige selvbetjeningsløs- ninger og portaler som eksempelvis Xxxxxx.xx, Xxxx.xx, Xxxxxxx.xx. I Løsningen benyttes NemLog-in til at understøtte, at Værger kan få adgang til personfølsomme oplysninger, og login sker gennem UNI- Logins løsning. |
Ansvar | |
Kategori | |
Organisatorisk placering | Digitaliseringsstyrelsen |
Antal/Kapacitet | 1 |
Navn | Skemalægningssystemer |
Rolle | Skemaplanlægningssystemer benyttes på Institutioner til skemaplan- lægning og vikardækning. I dag anvender de fleste Kommuner ske- maplanlægningsværktøjer fra enten KMD eller IST(Tabulex). Løsningen har behov for at modtage disse skemaer og vikardækning i forbindelse med Kalenderen. |
Ansvar | Kommune |
Kategori | |
Organisatorisk placering | Kommune |
Antal/Kapacitet | 2-4 systemer på markedet. 1 Leverandør i hver Kommune. |
Navn | Brugeradministrative systemer |
Rolle | Brugeradministrative systemer anvendes til oprettelse og administra- tion af Børn, Elever, Værger og Medarbejdere og håndteres på de enkelte Institutioner. De administrative systemer er ISTs Tabulex og KMDs Educa. Stam- data om Brugere benyttes af UNI-Login til at tildele Brugere et Uni- Login. De Brugeradministrative systemer kan opdeles i systemer til Skole og systemer til Dagtilbud. |
Ansvar | Kommune |
Kategori | |
Organisatorisk placering | Kommune |
Antal/Kapacitet | 2 systemer på markedet. Kommuner bruger generelt det ene system, men der findes Kommuner der har skemalægningssystem fra den ene leverandør og skoleadministrative løsninger fra den anden. |
Navn | Bibliotekssystem |
Rolle | I dag anvendes Bibliotekssystemet blandt andet til reservation af for- skellige materialer til brug i undervisningen. I Bibliotekssystemet lå- ner Brugere bøger, magasiner, multimedier og netbaserede materia- ler som bruges i undervisningsøjemed, og lån vil typisk være over en længere periode, i modsætning til de Ressourcer Løsningen indehol- der der kan bookes til specifikke Lektioner. Bibliotekssystemet forventes at ville udstille en eller flere Widgets i Løsningen. |
Ansvar | Kommune |
Kategori | |
Organisatorisk placering | Kommune |
Antal/Kapacitet | 1-2 systemer i 98 kommuner |
Navn | NemSMS |
Rolle | NemSMS giver mulighed for at påminde borgere og virksomheder via sms om bl.a. aftaler med det offentlige. I Løsningen benyttes NemSMS til at sende Notifikationer til Brugere. |
Ansvar | Kommune |
Kategori | |
Organisatorisk placering | Digitaliseringsstyrelsen |
Antal/Kapacitet | 1 |
LIS Systemer | |
Rolle | LIS Systemer dækker over Ledelses Informations Systemer i Kom- munerne, herunder den fælleskommunale løsning FLIS (Fælles Le- delses Informations System). Ledelsesinformation udstilles til LIS Systemer gennem Serviceplat- formen. |
Ansvar | Kommune |
Kategori | |
Organisatorisk placering | Kommune |
Xxxxx/Kapacitet | 1-2 systemer pr. Kommune (men kun udstilling igennem Serviceplat- formen) |
5 Funktionelle krav
I Løsningen er der behov for en bred vifte af funktionalitet. Nedenfor er samlet og kort præsenteret de væsentligste funktionalitetsområder, der er kravstillet i Kapitel 5. Under figuren er de enkelte områder uddybet.
Funktionalitet i Løsningen
Komme/gå
Søgning
Galleri
Opslag
Administration
Infotavle
Notifikationer
Kontakter
Beskeder
Samtykke
Hjemmeside
Sikker fildeling
Kalender
Profil
Figur 4 Funktionalitet i Løsningen
Profil: Alle Brugere i Løsningen tildeles en Profil, hvorfra Stamdata og evt. et profilbillede fremgår.
Beskeder: Beskeder dækker over funktionalitet som muliggør redigering og udsendelse af Beske- der både mellem Brugere af Løsningen, men også med Personer udenfor Løsningen – dette kræ- ver dog, at disse Personer har en e-mailadresse.
Opslag: I de tilfælde, hvor der er behov for at kunne offentliggøre nyheder f. eks. sommerfest på Skolen er kravstillet funktionalitet under navnet opslag, der understøtter, at en leder på en Skole vil kunne oprette en nyhed, hvori information om sommerfesten indgår og publicere denne til alle Medarbejdere, Forældre og Elever på Skolen.
Kalender: Kalender dækker over funktionalitet, der modsvarer basal funktionalitet i en digital Ka- lender, som i dag findes på de fleste telefoner. Dog med mindre forskelligartede behov, så som skole hjem-samtaler og at der skal kunne bookes Ressourcer, så som Lokaler og buskort.
Kontakter: Kontakter dækker over en liste af Personer en Bruger kan skrive til. Kontakter dækker både over Brugere af Løsningen samt Personer udenfor, som brugeren kan tilføje.
Galleri: Galleri dækker over muligheden for at brugere vha. deres telefon kan tage Billeder eller optage Video og udstille dem/den igennem Løsningen til andre Brugere. Det er endvidere kravstil- let, at en Klasse eller en Stue i et Dagtilbud får deres eget Galleri, som Brugere (Forældre, Elever, pædagoger mv.) kan tilgå. Naturligvis afgrænset af, hvilke rettigheder de enkelte Brugere er givet og hvilke Samtykker der er givet mht. offentliggørelse af Billeder.
Sikker fildeling: Sikker fildeling dækker over Medarbejderes mulighed for at kunne oprette Doku- menter indeholdende personfølsom information. Eksempler på sådanne Dokumenter er referater fra teammøder, observationer af en Klasse, noter om en Elev eller et Barn. Dokumenterne kan de- les og det er kravstillet, at der kan samarbejdes om dem.
Notifikationer: Notifikationer dækker over, at en Bruger skal kunne oprette en Notifikation til sig selv eller en anden Bruger f. eks. i forbindelse med en Begivenhed i Kalenderen eller at Brugeren har modtaget en Besked eller et Opslag.
Søgning: Søgning dækker over søgning i Løsningen, herunder søgning på f. eks. Beskeder, op- slag, andre Brugere, Begivenheder i Kalendere mv.
Hjemmeside: Hjemmeside dækker over, at administratorer skal kunne opsætte og administrere Hjemmesider for Institutioner f.eks. et Dagtilbud, en klynge eller en Skole.
Infotavle: Infotavle dækker over, at en administrator skal kunne udarbejde indhold (Opslag, Kalen- der, Komme/gå registering mv), der kan udstilles på skærme, der er placeret på en Skole eller et Dagtilbud.
Komme/gå: Komme/gå dækker over funktionalitet, der bl.a. tillader Forældre at angive at deres Barn er afleveret i børnehaven og at de har afhentet Barnet.
Samtykke: Samtykke dækker over, at det er kravstillet, at løsningen skal understøtte at Brugere kan og i visse tilfælde skal give Samtykke til brug af f. eks. Billeder. Samtykke til Billeder omhand- ler bl.a. Forældres Samtykke til at offentliggøre Billeder af deres Børn på Skolens Hjemmeside el- ler til andre Forældre.
Administration: Administration dækker bl.a. over tildeling af rettigheder til Brugere, indstilling af Dashboards og dækker over både administration centralt, på kommunalt plan og på den enkelte Institution.
Ud over ovenstående er det kravstillet, at Løsningen skal muliggøre, at andre systemer kan få ind- lejret en del af deres brugergrænseflade. Dette koncept kaldes for Widgets og beskrives nærmere nedenfor. For Brugerne betyder det, at de kan blive mødt af et samlet overblik, såfremt deres Kom- mune har fået f. eks. deres leverandør af en Læringsplatform til at udvikle en Widget.
Løsningen indgår i sammenhæng med administration af lovbestemte offentlige ydelser og Løsnin- gen skal derfor opfylde lovkrav. De lovkrav som Leverandøren ved sin Ydelse er forpligtet til at overholde fremgår af afsnit 6.6 Lovkrav. De lovkrav som KOMBIT på Kommunernes vegne er an- svarlig for at overholde gennem Løsningens administrative funktioner er kravsat herunder:
• Bekendtgørelse af lov om folkeskolen
• Bekendtgørelse af lov om dag-, fritids- og klubtilbud m.v. til børn og unge (dagtilbudslo- ven)
• Bekendtgørelse af lov om gennemsigtighed og åbenhed i uddannelserne m.v.
• Bekendtgørelse om tilsynet med folkeskolens Elever i skoletiden
• Bekendtgørelse af forvaltningsloven
• Bekendtgørelse af lov om Det Centrale Personregister
• Offentlighedsloven – LBK 606 af 12. juni 2013
Ovenstående love og bekendtgørelser er omsat til funktionelle krav og use cases i de følgende af- snit.
Ud over ovenstående er der i afsnit 0 angivet lovkrav, herunder krav til overholdelse af Personda- taloven.
Nedenfor kravstilles igennem Use cases og krav funktionalitet i Løsningen. For alle Use cases føl- ger en forklarende tekst, der beskriver behovet for den enkelte Use case.
5.3.1 Opslag (nyheder)
I forbindelse med Løsningen er der behov for, at Brugere kan publicere Opslag rettet mod be- stemte Grupper af Brugere f. eks. ”alle Elever på Skolen”, ”4.B.” eller Værger til Børn i et Dagtilbud. Opslag skal forstås som værende både helt korte tekster på få linjer og længere tekster, der kan have form som en artikel.
Et eksempel fra et Dagtilbud kunne være, at Pædagogisk personale fra en stue skriver et Opslag om, at Børnene ikke behøver at medbringe madpakke den næste dag, da de skal til fødselsdag hos en af Børnene på stuen. Medarbejdere i Dagtilbud forventes også, at skrive korte Opslag om, hvilke aktiviteter Børnene har foretaget den pågældende dag og indsætte Billeder af aktiviteterne.
I forbindelse med oprettelsen af Opslag er der behov for at kunne rette disse mod Grupper eller via bestemte kommunikationskanaler, herunder Institutionens Hjemmeside eller en Infotavle. En Insti- tutions Administrator og en Kommunal Administrator vil bl.a. have behov for, at kunne publicere Opslag på henholdsvis en Institutions Hjemmeside eller alle Institutioners Hjemmesider jf. afsnit
6.5 om rettigheder. Herudover vil visse Administratorer jf. afsnit om rettigheder have behov for at kunne publicere Opslag direkte til en Infotavle.
For at understøtte dialog mellem Afsender af et Opslag og Modtagere af et Opslag er der endvi- dere behov for at understøtte kommentering af Opslag. Om et Opslag skal kunne kommenteres afgøres af Afsenderen.
5.3.2 Publicer Opslag
Use case UC-01 | Navn: Publicer Opslag |
Igangsættende aktør | Alle Brugeraktører |
Formål, beskri- velse og af- grænsning | Brugeraktøren skal kunne skrive, formatere og publicere et Opslag til en eller flere Modtagere. En Modtager kan være Eleverne i 3.b, Værger Forældre i 3.b eller Værger til Børn på en bestemt stue i en Vuggestue. I forbindelse med Opslag er der behov for, at vise Modtagerne, Billeder, Vide- oer samt linke til f. eks. filer i Kommunens lokale fildelingsløsning. Der er der- udover behov for at kunne vedhæfte filer. For at kunne åbne op for debat og input fra Brugere skal Afsenderen af et Opslag kunne vælge at åbne op for kommentering på det pågældende Op- slag. Afsendere skal herudover kunne vælge, at Opslaget er vigtigt og dermed har en højere prioritet end andre Opslag. |
Hændelse | |
Forudsætninger | |
Handlinger | |
Bruger 1. Vælger Modtager 2. Indstiller Notifikation om Opslaget (se afsnit 5.9) 3. Skriver og formaterer tekst (jf. krav) 4. Indsætter fil fra Galleri (jf. UC-23) 5. Vedhæfter fil 6. Vælger kommenteringsmuligheder 7. Vælger prioritet (kun Ledere, Administratorer og Administrative Medarbejdere jf. afsnit 6.5) 8. Vælger prøvevisning 9. Tilknytter Notifikation (se afsnit 5.9) Løsningen | |
10. Generer prøvevisning Bruger 11. Publicerer Opslag | |
Slutresultat | Opslag er publiceret |
Alternativer: | |
1a-9a: Brugeren redigerer et allerede eksisterende Opslag publiceret af Brugeren og publicerer det opdaterede Opslag 11*: Brugeren sletter Opslaget | |
Sluttilstand | |
Bemærkninger: | |
Prioritering af Opslag kan eksempelvis gøres ved, at Opslaget ’låses’ øverst i en Brugers liste over Opslag i en periode, at Brugeren ud over Opslag modtager en Besked om, at der er publice- ret et vigtigt Opslag eller på anden vis ved at ændre design af Opslaget. | |
Krav # 3 Use case UC-01: Publicer Opslag | |||
Kategori: | (K) | Type: | Funktionelt |
Beskrivelse: | Løsningen skal opfylde Use case UC-01. | ||
5.3.3 Åbn, kommentér og skjul Opslag
Navn: Åbn, kommentér og skjul Opslag | |
Igangsættende aktør | Alle Brugeraktører |
Formål, beskri- velse og af- grænsning | Brugeren skal kunne tilgå en liste over Opslag, hvorfra Brugeren kan åbne evt. forkortede Opslag, kommentere på Opslag som Afsendere har tilladt jf. UC-01 samt skjule Opslag, der ikke har Xxxxxxxxx interesse. |
Hændelse | |
Forudsætninger | |
Handlinger | |
Bruger 1. Åbner et Opslag 2. Kommenterer Opslag 3. Skjuler Opslag | |
Slutresultat | Opslag er åbnet/kommenteret/skjult |
Alternativer: | |
Sluttilstand | |
Bemærkninger: | |
Kommentering af Opslag kan f. eks. håndteres ved at Brugeren kan kommentere en tidligere Kommentar, hvorefter denne potentielt nye dialog visuelt markeres (som bl.a. Facebook gør det), som værende en selvstændig del af den samlede mængde Kommentarer.
Krav # 4 Use case UC-14: Åbn, rediger og kommentér Opslag | |||
Kategori: | (K) | Type: | Funktionelt |
Beskrivelse: | Løsningen skal opfylde Use case UC-14. | ||
5.3.4 Beskeder
Beskeder dækker over funktionalitet som understøtter, at Brugere kan indgå i dialog. Dialogen vil foregå både en-til-en eller en-til-mange. Behovet for Beskeder kan bedst sammenlignes med den indbakke, der i dag følger med hos udbydere af e-mails. Beskeder i Løsningen forventes, som det er tilfældet med e-mails, at skulle flyde internt imellem en Institutions Medarbejdere, men også mellem Institutionen og Kommunen, Institutioner og andre Institutioner i andre Kommuner. Herud- over også mellem f. eks. Forældre på en Skole eller et Dagtilbud eller Elever på en Skole samt til alle, der har en e-mail adresse, hvilket kan være særligt relevant ifm. Åben skole.
Et eksempel fra et Dagtilbud kan være, at Pædagogisk personale tilknyttet en stue ønsker at gøre stuens Værger opmærksomme på, at de skal huske at rydde op i Barnets garderobe.
At etablere den korrekte balance mellem sikkerhed og brugervenlighed er en af de primære udfor- dring i forhold til Beskeder, da Beskeder mellem bl.a. Forældre og Pædagogisk personale kan in- deholde fortrolige eller personfølsomme informationer. Disse vil derfor kræve et højere niveau af sikkerhed jf. afsnit 6.5.
5.3.4.1 Opret og send Besked
Use case UC-02 | Navn: Opret og send Besked |
Igangsættende aktør | Alle Brugeraktører |
Formål, beskri- velse og af- grænsning | Brugeren skal kunne skrive, formatere og sende Beskeder til Modtagere. Herudover skal Brugeren kunne sende Beskeden til en e-mailadresse samt modtage e-mails fra aktører udenfor Løsningen. |
Hændelse | |
Forudsætninger | |
Handlinger | |
Bruger 1. Vælger Modtager 2. Indstiller Notifikationer om Beskeden 3. Skriver og formaterer tekst (jf. Krav # 86) 4. Indsætter fil fra Galleri (jf. UC-23) 5. Vedhæfter fil 6. Tilknytter Notifikation (se afsnit 5.9) 7. Sender Besked | |
Slutresultat | Besked er sendt |
Alternativer: | |
1a-7a: Brugeren redigerer en tidligere afsendt Besked og sender en ny og opdaterede Besked. 7a: Brugeren markerer om Beskeden indeholder personfølsom information og sender Beskeden til en Bruger indenfor Løsningen. 7b: Brugeren markerer at Beskeden indeholder personfølsom information og sender Beskeden til en aktør udenfor Løsningen. Løsningen informerer Xxxxxxxx om, at det kan være i strid med gæl- dende lovgivning, at sende Beskeden til aktører udenfor Løsningen, hvorefter Brugeren sender Beskeden. 7c: Brugeren markerer at Beskeden indeholder personfølsom information og sender Beskeden til en aktør udenfor Løsningen. Løsningen informerer Xxxxxxxx om, at det kan være i strid med gæl- dende lovgivning, at sende Beskeden til aktører udenfor Løsningen, hvorefter Brugeren sletter Beskeden. 7*: Brugeren sletter Beskeden. | |
Sluttilstand | |
Bemærkninger: | |
Krav # 5 Use case UC-02: Opret og send Besked | |||
Kategori: | (K) | Type: | Funktionelt |
Beskrivelse: | Løsningen skal opfylde Use case UC-02. | ||
Krav # 6 Synlige eller usynlige Modtagere | |||
Kategori: | (K) | Type: | Funktionelt |
Beskrivelse: | Løsningen skal, i forbindelse med afsendelse af Beskeder, understøtte, at Af- senderen af Beskeden kan vælge at gøre en eller flere Modtagere synlige eller usynlige for den enkelte Modtager af Beskeden. En sammenlignelig funktion kendes i dag fra e-mails, hvor der benyttes tre felter til at indtaste Modtagere: Til, CC samt BCC. | ||
5.3.4.2 Håndter Beskeder
Use case UC-03 | Navn: Håndter Beskeder |
Igangsættende aktør | Alle Brugeraktører |
Formål, beskri- velse og af- grænsning | Brugeren skal kunne besvare Beskeder og herigennem indgå i dialog samt vi- dendele med en eller flere Afsendere og Modtagere af Beskeder. Brugeren skal også kunne se detaljer på Beskeder f. eks. Afsender, Modtager, dato og tidspunkt og om og hvornår Modtager har åbnet en afsendt Besked. Denne funktion er særlig væsentlig for Pædagogisk personale, der, hvis Beskeder ikke læses, kan tage kontakt til Værger på anden vis. Brugeren skal kunne Opmærke om Beskeder indeholder personfølsomt ind- hold, så Løsningen kan håndtere disse Beskeder korrekt jf. 6.5 og krav 12. For at kunne danne sig et overblik over Xxxxxxxx skal Brugeren kunne mar- kere Beskeder som værende vigtige eller ikke-vigtige. Sidst, men ikke mindst, skal Brugeren kunne besvare modtagede Beskeder. |
Hændelse | |
Forudsætninger | |
Handlinger | |
Bruger 1. Vis Besked 2. Marker Besked (Enkeltvis elle flere af ganger) 3. Vis detaljer 4. Opmærk Besked 5. Markér som vigtig 6. Svar Besked | |
Slutresultat | Besked(erne) er besvaret, flyttet eller undersøgt. |
Alternativer: | |
1a-2a: Brugeren sletter Besked(er) 1b-6b: Brugeren kan udføre handlingerne på vegne af Fællespostkasser de har rettigheder til. | |
Sluttilstand | |
Bemærkninger: | |
Krav # 7 Use case UC-03: Håndter Besked | |||
Kategori: | (K) | Type: | Funktionelt |
Beskrivelse: | Løsningen skal opfylde Use case UC-03. | ||
Krav # 8 Indbakke funktionalitet | |||
Kategori: | (K) | Type: | Funktionelt |
Beskrivelse: | Løsningen skal understøtte, at • Brugeren tydeligt kan skelne mellem ulæste og læste Beskeder • Besked korrespondancer hvor Xxxxxxx besvarer og videresender Beskeder, skal være sammenhængende eller trådes så det bliver overskueligt for Brugeren at se historik. • Afmærke Beskeder, så de adskiller sig fra øvrige Beskeder (f. eks. med stjerne, farve eller flag) | ||
Xxxx # 0 Inkludere tidligere mail i besvarelser | |||
Kategori: | (K) | Type: | Funktionelt |
Beskrivelse: | Løsningen skal, i forbindelse med afsendelse af Beskeder, understøtte at der ved oprettelse af en besvarelse, automatisk inkluderes teksten fra den modta- get mail under besvarelsen (som f. eks. i Outlook eller Gmail) | ||
Krav # 10 Spam og uønsket beskedfiltrering | |||
Kategori: | (K) | Type: | Funktionelt |
Beskrivelse: | Løsningen skal, i forbindelse med Beskeder, filtrere spam og uønskede Be- skeder fra, så de ikke modtages i Brugernes indbakker. Derudover skal Bru- geraktørerne have mulighed for at Opmærke Beskeder som uønskede, så de tilføjes til filteret. Hvilke regler der skal gælde for filtrering af spam og uøn- skede Beskeder afklares med Leverandøren i afklaringsfasen. | ||
Krav # 11 Automatisk besvarelse | |||
Kategori: | (K) | Type: | Funktionelt |
Beskrivelse: | Løsningen skal, i forbindelse med afsendelse af Beskeder understøtte, at Bru- gerne kan opsætte automatisk svar når de modtager Beskeder (eksempelvis hvis Brugeren er på ferie eller er syg). Brugeren skal kunne skrive en svar tekst og angive perioden hvor automatisk besvarelse er aktiv. Administratorer skal kunne opsætte automatisk besvarelse på de Brugere og fællespostkasser, som de har rettigheder til jf.5.11.10. Dette er f. eks. relevant ved sygdom. | ||
Krav # 12 Beskeder indeholdende Personfølsomt indhold videresendes ikke | |||
Kategori: | (K) | Type: | Funktionelt |
Beskrivelse: | Løsningen skal understøtte, at Beskeder der jf. UC-02 og UC-03, er markeret som indeholdende personfølsomt indhold ikke videresendes automatisk (jf. UC-04 og muligheden for at opsætte automatisk videresendelse). Løsningen skal i tilfælde, hvor en Besked ikke videresendes underrette Bru- geren om, at der er modtaget en Besked, som ikke kan videresende pga. per- sonfølsomt indhold. | ||
Krav # 13 Indbakke funktionalitet | |||
Kategori: | (K) | Type: | Funktionelt |
Beskrivelse: | Løsningen skal understøtte, at • Brugeren tydeligt kan skelne mellem ulæste og læste Beskeder • Besked korrespondancer hvor Xxxxxxx besvarer og videresender Beskeder, skal være sammenhængende eller trådes så det bliver overskueligt for Brugeren at se historik. • Afmærke Beskeder, så de adskiller sig fra øvrige Beskeder (f. eks. med stjerne, farve eller flag) | ||
Krav # 14 Se om afsendt Besked er åbnet | |||
Kategori: | (K) | Type: | Funktionelt |
Beskrivelse: | Løsningen skal understøtte at Medarbejdere skal kunne se, om og hvornår Brugere har åbnet en afsendt Besked. Denne funktion er særlig væsentlig for Pædagogisk personale, der, hvis Be- skeder ikke læses, kan tage kontakt til Værger på anden vis. I situationer hvor der kræves hurtig dialog mellem Pædagogisk personale og Værger er denne funktionalitet nødvendig. | ||
Krav # 15 Fællespostkasse | |||
Kategori: | (K) | Type: | Funktionelt |
Beskrivelse: | Løsningen skal understøtte, at Institutioner og Afdelinger kan benytte Fælles- postkasser. Fællespostkasser benyttes bl.a. af Institutioner for at kunne give en kontakt- adresse på Institutionens Hjemmeside, der kan håndteres af flere Brugere, så en enkelt Bruger f. eks. en Leder ikke bliver flaskehals i behandling af Beske- der. | ||
Opsætning af Profil og Kontakter
Opsætning dækker over den enkelte Brugers opsætning af egen Profil, herunder indtastning eller opdatering af Stamdata jf. bilag 2.1.A Informationsmodel, Samtykke, styring af indstillinger samt opsætning af Kontakter som Brugeren kan benytte ifm. publicering af Opslag og afsendelse af Be- skeder og Begivenheder til Modtagere.
Første gang Brugerne tilgår Løsningen er der behov for, at Brugeren vælge hvilke Samtykke og Tilladelser de ønsker at give jf. 44Krav # 19, at de indtaster de Stamdata, som tilknyttede Institutio- ner har behov for og som ikke udfyldes automatisk jf. bilag 2.1.A Informationsmodel.
Da Børn og Xxxxxx ikke selv kan indtaste Stamdata og give Samtykke er der i Løsningen behov for, at Værger i Løsningen kan tilgå de Børn og Elever, de er Værge for jf. bilag 2.1.A Informationsmo- del.
5.4.1 Administrer Profil
Use case UC-04 | Navn: Administrer Profil |
Igangsættende aktør | Alle Brugeraktører |
Formål, beskri- velse og af- grænsning | Brugeren skal kunne administrere en Profil eller flere Profiler, hvoraf der frem- går Stamdata f. eks. navn, Billede og Kontaktoplysninger jf. bilag 2.1.A Infor- mationsmodel. Hvis Brugeren er Værge skal denne kunne administrere en Profil for deres Barn/Børn og/eller Elev/Elever. |
Brugeren skal endvidere kunne registrere eller afvise Samtykke og Tilladelse, så Løsningen kan håndtere eksempelvis billeder af Xxxxxxxx eller dennes Barn i henhold til lovgivningen. Herudover skal de kunne angive om de foretrækker at få Notifikationer via App, browser, e-mail eller sms jf. afsnit Krav # 43 samt vælge om de ønsker at få videresendt Beskeder til deres personlige e-mailadresse (f. eks. en Gmail eller en Outlook). | |
Hændelse | Brugeren tilgår Løsningen første gang Brugeren ønsker at ændre i oplysninger eller indstillinger under Profilen |
Forudsætninger | |
Handlinger | |
Løsningen 1. Præsenterer Profil for Bruger inkl. de Stamdata, der kan hentes fra Uni-login jf. bilag 2.1.B Integrationer og Snitflader Bruger 2. Administrerer Stamdata (se bilag 2.1.A Informationsmodel) 3. Vælger hvilke Stamdata, der skal være synlige for hvilke Brugere eller på Institutionens Hjemmeside (Navn, Billede, kontaktoplysninger, fødselsdag) 4. Udfylder Samtykke og Tilladelser 5. Ændre Profilbillede 6. Angiver foretrukken kommunikationskanal til Notifikationer (jf. afsnit Krav # 43) 7. Angiver e-mailadresse som Beskeder skal videresendes til Løsningen 8. Opdaterer Løsningen på baggrund af Brugeraktørens indtastninger og indstillinger 9. Præsenterer opdateret Profil | |
Slutresultat | Profil er opdateret |
Alternativer: | |
4a. Brugeraktøren trækker et Samtykke tilbage, hvorefter Løsningen håndterer eventuelle ændrin- ger heraf (f. eks. fjerner Billeder fra Institutionens Hjemmeside) jf. bilag 2.1.C Regler. 4b: Brugeraktøren trækker en Tilladelse tilbage, hvorefter Løsningen informerer Lederen af Insti- tutionen. | |
Sluttilstand | |
Bemærkninger: | |
I de tilfælde, hvor der er flere Værger f. eks. to Forældre skal Løsningen sikre, at begge Værger kan administrere et Barns eller Elevs profil. Ifm. handling 3 skal en Værge kunne vælge, hvilke Stamdata andre Værger skal kunne se. | |
Krav # 16 Use case UC-04: Administrer Profil | |||
Kategori: | (K) | Type: | Funktionelt |
Beskrivelse: | Løsningen skal opfylde Use case UC-04. | ||
Krav # 17 Beskrivelse af medlemmer af Bestyrelsen | |||
Kategori: | (K) | Type: | Funktionelt |
Beskrivelse: | Løsningen skal understøtte, at medlemmer af Bestyrelsen skal kunne tilføje en beskrivelse af sig selv under deres Profil. Beskrivelsen kan herefter blive vist på Skolens Hjemmeside og for Kontaktforældre jf. afsnit 5.11.3 og afsnit 5.12.2. Hvilke Brugere, der i Løsningen angives som værende medlemmer af Besty- relsen, angives af Intuitionens Administrator i UC-06. |
Flere af behovene beskrevet i Kravspecifikation vil ofte vedrøre personfølsomme og fortrolige op- lysninger. Det betyder at Løsningen skal overholde specifikke love og regler ifm. dette. For at Løs- ningen kan overholde disse love og regler, skal der indhentes Samtykkeerklæringer og Tilladelser fra Værger.
Fælles for Samtykke og Tilladelser er at der er tale om tilkendegivelser eller tilladelser. Ofte skel- nes der mellem disse tilladelser, og følgende vil derfor definere forskellen på de to, som er med til at danne den generelle opfattelse i Institutionerne.
Samtykke sikrer at Brugerne ved hvilken form for oplysninger der bliver udvekslet mellem hvem og vedrører personfølsomme og fortrolige oplysninger. Samtykkeerklæringer der indhentes ved insti- tutionsstart drejer sig f. eks. om udveksling af private og andre fortrolige oplysninger, eller Sam- tykke til at dele Portrætfoto af Børn/Elever, i Løsningen og/eller på sociale medier. Det er specielt vigtigt at reglerne om Samtykke i lovgivningen honoreres (Samtykke skal være specifikt, frivilligt, informeret, utvetydig viljestilkendegivelse osv.) og at de kan trækkes tilbage ligeså let som de er afgivet.
Tilladelser omhandler alt det som ikke er omfattet af Samtykke. Det drejer sig generelt om mere specifikke tilkendegivelser ift. særlige situationer, som ikke vedrører private og personfølsomme oplysninger. Det kan f. eks. være en Elev der tillades at forlade Skolens område i skoletiden, eller Barn der godt må køres i Ladcykel i Børnehaven.
De generelle regler om offentlige myndigheders adgang til at videregive fortrolige oplysninger fin- des i forvaltningslovens §§ 28-32 og sundhedsloven §§ 41-44. Generelle regler for behandling af personoplysninger findes i persondataloven §§ 5-14.
Der er behov for at Løsningen understøtter at Brugere kan afgive Xxxxxxxx og Tilladelser på deres Profil og at Institutionerne kan se om der er givet Samtykke og Tilladelse.
Nedenstående Samtykke gør sig gældende for alle Brugere:
1. Samtykke til udveksling af private og andre fortrolige oplysninger: Denne er f. eks. relevant ved Institutionsskifte: Hvis Institution har oprettet Data om Bruger i Løsningen (ob- servationer eksempelvis), kan denne data være eller ikke være tilgængelig for den nye In- stitution, afhængigt af Samtykket.
2. Samtykke til deling af Fotos og video: Relevant for om Institutionen må dele portrætfotos og eller situationsbilleder, samt video af Bruger, Barn eller Elev, i selve Løsningen.
3. Samtykke til at se Brugerindtastede oplysninger: Når Xxxxxxx selv registrerer oplysnin- ger om Barn eller Elev, som f. eks. Helbredsforhold, særlige kosthensyn eller modersmål, er der ikke behov for at indhente Samtykke. Disse oplysninger vil dog ikke indgå under punkt 1, da det ikke er oprettet af Institutionen. Værger skal derfor spørges ved Institutions- skifte om de oplysninger de selv har registreret, må gøres tilgængelige for den modtagende Institution.
Nedenstående Tilladelser gør sig gældende for Værger:
4. Generelle Tilladelser: Relevante Tilladelser Værger har behov for at kende ifm. pasning og opsyn med Børn/Elever. Disse dækker f.eks. at Barn/Elev må køres i ladcykel, afhentes af andre end Værger, forlade Institutionens område mm. Tilladelser vedrører ikke Medar- bejdere.
For specifikation af ovenstående Samtykke og Tilladelser henvises der til bilag om Samtykke og Tilladelse.
Kategori: | (K) | Type: | Funktionelt |
Beskrivelse: | Løsningen skal understøtte at; • Værger skal kunne se hvilke Samtykke og Tilladelser de har givet for tilknyttede Børn og hvilke der ikke er besvaret • Medarbejdere skal kunne se hvilke Samtykke og Tilladelser de har gi- vet og hvilke der ikke er besvaret | ||
Kategori: | (K) | Type: | Funktionelt |
Beskrivelse: | Løsningen skal understøtte, at Brugere der tilgår Løsningen for første gang, bliver pålagt at udfylde nødvendige Stamdata jf. bilag 2.1.A samt Samtykker og Tilladelser. Brugeren kan f. eks. tvinges til at udfylde Stamdata og Samtykke ved at Løs- ningen ikke åbner op for yderligere funktionalitet før oplysningerne er givet. Leverandøren skal i samarbejde med KOMBIT i Analyse og designfasen af- klare, hvordan det første login bedst håndteres. | ||
Krav # 20 Personfølsomt indhold i videresendte Beskeder | |||
Kategori: | (K) | Type: | Funktionelt |
Beskrivelse: | Løsningen skal understøtte at Beskeder indeholdende personfølsomt indhold ikke videresendes til en e-mailadresse udenfor Løsningen (f. eks. Gmail eller Hotmail). Løsningen skal på anden vis informere Xxxxxxxx om, at der er mod- taget en Besked med personfølsomt indhold. Dette kan f. eks. gøres ved at Løsningen generer og sender en Besked til Brugerens e-mail udenfor Løsningen, hvori det fremgår, at Brugeren vil skulle tilgå Løsningen for at læse Beskeden med personfølsomt indhold. | ||
5.4.2 Håndter Kontakter
I forbindelse med bl.a. Åben skole har Medarbejdere i Institutioner behov for, at kunne indgå i dia- log med Personer udenfor Løsningen. Dette kan understøttes igennem Beskeder, da der ifm. UC- 02 er kravstillet at Løsningen skal kunne modtage e-mails.
Pædagogisk personale, der ønsker at arrangere et undervisningsforløb for udskolingen om lån, renter og gebyrer kan derfor igennem Løsningen kontakte den lokale bank og aftale at en Medar- bejder herfra med viden om dette kommer på besøg og underviser Eleverne. Et andet eksempel kan være en aftale med et initiativ som Coding Class, som er et samarbejde mellem IT-Branchen, en række medlemsvirksomheder, Københavns Kommune, Vejle Kommune og Styrelsen for IT- og Læring, som skal understøtte bedre introduktion til programmering og it i Skolen. I den forbindelse vil der være behov for kommunikation mellem en række Medarbejdere og Personer udenfor Løs- ningen. Disse Personer udenfor Løsningen er der behov for, at kunne oprette som Kontakter, så deres e-mail og Kontaktoplysninger ikke skal opbevares udenfor Løsningen.
Use case UC-05 | Navn: Håndter Kontakter |
Igangsættende aktør | Medarbejder, Værge |
Formål, beskri- velse og af- grænsning | Brugeren skal kunne oprette og redigere Kontakter. Det skal være muligt, at tilføje e-mailadresser og navne på Kontakter, der ikke er Brugere af Løsningen. |
Hændelse | |
Forudsætninger | |
Handlinger | |
Bruger 1. Opretter Kontaktperson 2. Indtaster Kontaktoplysninger på Kontakt (jf. bilag 2.1.A Infomationsmodel) | |
Slutresultat | Kontakt er oprettet eller redigeret |
Alternativer: | |
1a: Brugeren vælger at redigere eller slette en eksisterende Kontakt 1b: Brugeren søger en Bruger i Løsningen og tilknytter denne til sine Kontakter | |
Sluttilstand | |
Bemærkninger: | |
Krav # 21 Use case UC-04: Administrer Profil | |||
Kategori: | (K) | Type: | Funktionelt |
Beskrivelse: | Løsningen skal opfylde Use case UC-05. | ||
Krav # 22 Tilgængelige Modtagere | |||
Kategori: | (K) | Type: | Funktionelt |
Beskrivelse: | Løsningen skal understøtte, at relevante Modtagere er tilgængelige for den enkelte Bruger under Kontakter sammen med de Kontakter Brugeren har op- rettet. Relevante Modtagere for en Værge kan f. eks. være Forældre til Børn og Pæ- dagogisk personale på den Stue i det Dagtilbud, hvor Værgens Barn også er tilknyttet. Kravet er underlagt de begrænsninger, i forhold til kommunikation, der er sat af Administratorer UC-06, UC-08, UC-10. |
5.4.3 Overblik over Samtykke og Tilladelse
Pædagogisk personale, Ledere og Administrative Medarbejdere vil ofte have behov for at under- søge hvilke Samtykke og Tilladelser Værger har afgivet. De har derfor behov for at kunne se Sam- tykke og Tilladelser for den enkelte bruger, men også for alle Brugere i en Gruppe. Når det drejer sig om Gruppe, har de behov for en oversigt for alle, fremfor at skulle åbne hver enkelte Brugers Profil. På denne måde kan de f. eks. hurtigt undersøge om alle Elever kan deltage i svømning, el- ler hvilke Børn der ikke må køre i ladcykel.
Der er derfor behov for at Løsningen understøtter Institutionerne, så de kan se hvilke Samtykke og Tilladelser, tilknyttede Brugere har afgivet jf. Krav # 18, ud fra de tilgængelige Samtykke og Tilla- delser Administrator har fastlagt jf. Krav # 59.
Krav # 23 Se Samtykke og Tilladelse | |||
Kategori: | (K) | Type: | Funktionelt |
Beskrivelse: | Løsningen skal understøtte, at Pædagogisk personale, Ledere og Administra- tive Medarbejdere kan se hvilke Samtykker og Tilladelser der er givet fra Vær- ger. Medarbejdere skal kunne se en oversigt over Samtykke og Tilladelser for Børn og Xxxxxx for en Gruppe som de rettigheder til at se jf. 0. | ||
For at sikre at alle Institutioner sikkert kan arbejde med og opbevare filer, der indeholder personføl- somme oplysninger er der behov for, at kunne uploade Dokumenter til Løsningen jf. krav 79, men også at oprette Dokumenter direkte i Løsningen jf. UC-12.
Deling af filer og Dokumenter, der ikke indeholder personfølsomme oplysninger vil skulle ske i Kommunens eller Institutionens egen fildelingsløsning f. eks. Google Drive, Microsoft Onedrive el- ler en lokal løsning.
Sager, og Dokumenter som relaterer sig hertil, skal håndteres i Kommunens ESDH system og ikke i Løsningen. Løsningen understøtter dog at Dokumenter om et Barn eller en Elev kan oprettes i Sikker Fildeling, hvorefter disse kan sendes til en sagsbehandler jf. UC-12.
5.5.1 Opret Dokument
I forbindelse med Løsningen er der behov for at oprette Dokumenter. Dokumenter i Løsningen kan være af to forskellige typer, henholdsvis:
• Tomt Dokument
• Pædagogisk Note
Et Tomt Dokument kan være et referat fra et Teammøde, hvor der, ud over en gennemgang af Ele- ver i Klassen f. eks. Også kan indgå ansvarsdeling og planlægning. Referater vil derfor ofte inde- holde både personfølsom men også ikke-personfølsom information. Et Tomt Dokument kan dog også omhandle en fælles aftale, aftalt på et Teammøde, hvor der f. eks. er aftalt en ændret praksis overfor 4b, der altid kommer for sent ind efter frikvarter. Referater vil altid være interne, hvorfor der ikke er behov for at give Værger adgang til at se referatet.
En Pædagogisk Note oprettes af Medarbejder, der i forbindelse med deres arbejde har behov for, at kunne oprette korte beskrivelser (Pædagogiske Noter) om en eller flere Børn eller Elever. No- terne er tænkt som en intern kilde til videndeling mellem eksempelvis Pædagogisk personale til- knyttet en Klasse samt som referater af møder i det team, der er tilknyttet f. eks. en Klasse.
Use case UC-12 | Navn: Opret Dokument |
Igangsættende aktør | Medarbejder |
Formål, beskri- velse og af- grænsning | Brugere skal kunne oprette eller tilføje (uploade) Dokumenter til Løsningen in- deholdende personfølsomme oplysninger og dele disse med andre Brugere samt angive tilladelser til at se og/eller redigere et Dokument. For at understøtte overblik og søgning er der behov for, at Brugeren angiver en kategori for hvert Dokument eksempelvis Referat. Det er ligeledes vigtigt, at der tilknyttes en Bruger eller Gruppe af Brugere til et Dokument og at Do- kumenter synliggøres for Værger og/eller Barnet/Eleven Dokumentet om- handler. For at sikre at Brugerne kan skabe overblik over Dokumenter med personføl- somt indhold skal Løsningen understøtte, at Dokumenter kan overføres til Løsningen samt at der tilknyttes type og kategori til alle Dokumenter i Sikker fildeling. |
Hændelse | |
Forudsætninger | |
Handlinger | |
Bruger 1. Opret nyt Dokument 2. Vælg type (Tomt Dokument eller Note jf. bilag 2.3 Informationsmodel) 3. Angiv kategori (Observation, referat, elevfravær, målsætning, iagttagelse, notat, Indstilling) 4. Vælg tilknytning (Barn eller Elev, Gruppe) 5. Vælg synlighed (Eleven og/eller Værger) | |
6. Tilknytter Notifikation (se afsnit 5.9) Løsningen 7. Tilknyt oplysninger om Dokumentet (dato, informationer om Bruger, der har oprettet Doku- mentet) | |
Slutresultat | Dokument er oprettet |
Alternativer: | |
1a-4a: Brugen overfører en fil til Løsningen, vælger type, søger Brugere filen ønskes delt med og deler filen med Brugere 1b: Brugeren vælger et eksisterende Dokument og redigerer dette 2a: Brugeren vælger et tomt Dokument, vælger tilknytning, Søg Brugere dokumentet ønskes delt med samt angiver tilladelser ved deling (se eller adgang til redigering) | |
Sluttilstand | |
Bemærkninger: | |
Ungdomsskoler og specialskoler vil som en del af deres virke benytte funktionalitet oftere end an- dre Institutioner. Udgangspunktet for disse to Institutioner er netop, at dokumentation og dialog med Værger og sagsbehandlere er intensiveret i forhold til andre Institutioner understøttet af Løs- ningen. | |
Krav # 24 Use case UC-12: Opret Dokument | |||
Kategori: | (K) | Type: | Funktionelt |
Beskrivelse: | Løsningen skal opfylde Use case UC-12. | ||
Krav # 25 Overblik over adgang til Dokumenter | |||
Kategori: | (K) | Type: | Funktionelt |
Beskrivelse: | Løsningen skal understøtte, at Medarbejdere kan få indblik i og overblik over, hvilke andre Medarbejdere, der har adgang til Dokumenter oprettet eller over- ført af Medarbejderen. | ||
Kategori: | (K) | Type: | Funktionelt |
Beskrivelse: | Løsningen skal understøtte, at Medarbejdere kan se revisionshistorik på Do- kumenter. Både Dokumenter Medarbejderen har oprettet, men også Doku- menter Medarbejderen har adgang til. Revisionshistorikken skal indeholde information om, hvilke andre Medarbej- dere der har åbnet Dokumentet eller redigeret det samt dato og tidspunkt for redigering eller åbning. | ||
Krav # 27 Send Dokumenter til sagsbehandler | |||
Kategori: | (K) | Type: | Funktionelt |
Beskrivelse: | Løsningen skal understøtte, at Medarbejdere kan vedhæfte og sende Doku- menter fra Sikker fildeling til en sagsbehandler ved brug af en e-mail adresse. I forbindelse med afsendelse af Dokumenter fra Sikker fildeling skal Løsnin- gen bede Medarbejderen bekræfte, at det er den korrekte e-mail adresse, så Dokumenter fra Sikker fildeling ikke sendes til en forkert e-mail adresse. Ved modtagelse af Dokumentet vil sagsbehandleren kunne tilknyttet Doku- mentet til en sag i Kommunens ESDH system (dette foregår udenfor Løsnin- gen). |
Kategori: | (K) | Type: | Funktionelt |
Beskrivelse: | Løsningen skal understøtte, at Medarbejdere kan gøre Noter synlige for Vær- ger samt fjerne Noten igen, så Værgen ikke længere kan se den. Dette kan f. eks. ske ved, at Noten knyttes til et Barn eller Elevs Profil, hvoref- ter Værgen vil kunne gå ind under Profilen og se den eller de Noter en eller flere Medarbejdere har gjort synlige for Værgerne. | ||
Kalenderen vil være indgangsvinkel for Løsningens Brugere til alt hvad der drejer sig om tidsplan- lagte Begivenheder. Alle Brugere og Ressourcer kan knyttes til en Begivenhed og har dermed sin egen Kalender. Det skal desuden være muligt at visse Grupper (f. eks. en klasse eller en hel Insti- tution) også har egen Kalender. Personer (med en e-mailadresse) udenfor Løsningen kan desuden inviteres til Begivenheder, men har ikke en Kalender i Løsningen så længe de ikke er oprettede Brugere.
Kalendere kan deles med andre Brugere og Ressourcer i Institutionen og på tværs af Institutioner, således at Ressourcer, der deles mellem flere Institutioner er tilgængelige for Brugere fra alle rele- vante Institutioner.
For Grupper gælder det at såfremt en Gruppe (f. eks. 7.B) er indkaldt til en Begivenhed, vil en Bru- ger kunne åbne Gruppens Kalender og se denne Begivenhed. Det giver mulighed for at Brugere kan arbejde med Kalendere på mere overordnet niveau så en Leder eksempelvis vil kunne over- skue Kalender for en eller flere Stuer i en Børnehave.
Krav # 29 Kalender for Brugere, Grupper og Ressourcer | |||
Kategori: | (K) | Type: | Funktionelt |
Beskrivelse: | Løsningen skal understøtte, at alle Brugere og Ressourcer har deres egen Kalender og kan inviteres til Begivenheder, samt at Grupper kan have egen Kalender. I de tilfælde, hvor en Gruppe er inviteret til en Begivenhed skal Begivenheden både være synlig i Gruppens Kalender men også i hver enkelt Brugeres Ka- lender. | ||
Krav # 30 Kalender for Brugere, Grupper og Ressourcer | |||
Kategori: | (K) | Type: | Funktionelt |
Beskrivelse: | Løsningen skal understøtte, at Medarbejdere kan give andre Medarbejdere råderet over deres Kalender. Det kan f. eks. være relevant for en Skoleleder at give Skolesekretæren fuld råderet til at styre Skolelederens Kalender. |
5.6.1 Opret og rediger Begivenhed
En Begivenhed dækker lektioner, møder og alle andre aktiviteter, der præsenteres i en Kalender, defineret ved at foregå i et bestemt tidsrum involverende en række Brugere (Elever, Pædagogisk personale m.v.) samt eventuelt Ressourcer (Lokaler og Materialer). Der er behov for at Brugerens Xxxxxxxx skal indeholde alt hvad der er relevant i relation til Skole og hertil hørende aktiviteter, hvorfor også Eksterne parter (eksempelvis idrætsforeninger) kan gives mulighed for at invitere Bru- gere af Løsningen til Begivenheder ’udenfor’ Løsningen f. eks. fodboldtræning (se bilag 2.1.E).
Use case UC-13 | Navn: Opret og Rediger Begivenhed |
Igangsættende aktør | Alle Brugeraktører |
Formål, beskri- velse og af- grænsning | Use casen dækker alle Brugeres arbejde med deres Kalender, i relation til oprettelse, ændring og sletning af Begivenheder. I Løsningens Kalender administreres alle kalender-relevante Begivenheder, undtaget de der administreres som del af Brugerens skema (for Pædagogisk personale og Elever). Skemalægningssystemerne eksporterer skemaer til Løsningen, som herefter håndterer skemaer som en almindelig Kalender. I Løsningens Kalender må man dog ikke lave ændringer i data om Begivenhe- der modtaget fra skemalægningsysstemerne (eksempelvis ændre tidsrum for en skemalagt Begivenhed, ændre Lokale eller lignende). Use casen dækker tilmed den situation hvor en Medarbejder ønsker at reser- vere tid i sin Kalender, så man eksempelvis reserverer forberedelsestid. I nogle tilfælde planlægges Begivenheder, der strækker sig over flere tidsrum, som de inviterede herefter tilmelder sig på en gang. Dette kan eksempelvis være tre Begivenheder tre onsdage i forskellige tidsrum, der tilsammen dæk- ker teammøder. |
Hændelse | |
Forudsætninger | |
Handlinger | |
Bruger: • Opretter Begivenhed • Angiver information om tid, sted og varighed • Tilføjer tekst til Begivenheden • Inviterer Modtagere • Booker Ressourcer (inkluderer use case Fejl! Henvisningskilde ikke fundet.) • Markerer Begivenheden som ”åben” eller ”lukket” således at kun inviterede kan se indhol- det af Begivenheden | |
Slutresultat | |
Alternativer: | |
1a Finder Begivenhed der skal redigeres 3a Bruger indkalder til en Begivenhed, hvor det ikke er frivilligt for den indkaldte. Dette skal dog styres rettighedsmæssigt så kun de rette Brugere har mulighed for at indkalde, mens flere kan in- vitere. 3b Involverer use casen en ændring der har konsekvens for Brugerens undervisningsaktiviteter (det skemalagte), kan Brugeren der indkalder markere at den inviterede Medarbejders Leder skal godkende på vegne af den inviterede. 3b Brugeren vælger at Begivenheden ikke kræver accept, men blot skal vises i Modtageres Ka- lendere. 1-6c: Brugeren laver en Møderække som en samlet Begivenhed, der indeholder to eller flere tids- rum hvor alle inviterede skal deltage. Hvert tidsrum skal kunne have forskellige Ressourcer til- knyttet, samt forskellige Brugere (ikke de inviterede, men eventuelle oplægsholdere). | |
Sluttilstand | |
Bemærkninger: | |
Markering af, om en Begivenhed er ’åben’ eller ’lukket’ kan som i Outlook bruges til at angive pri- vate Begivenheder i ens Kalender. | |
Krav # 31 Use case UC-13: Opret og rediger Begivenhed | |||
Kategori: | (K) | Type: | Funktionelt |
Beskrivelse: | Løsningen skal opfylde Use case UC-14. | ||
Krav # 32 Godkende booking af Ressource | |||
Kategori: | (K) | Type: | Funktionelt |
Beskrivelse: | Løsningen skal, såfremt en Bruger ikke har ret til at booke en Ressource, un- derstøtte at Brugeren kan anmode om at få lov til at booke. Løsningen skal herefter notificere den Bruger der har ansvar for Ressourcen som stilles over- for at kunne afvise eller godkende bookingen. I den tid hvor godkendelse eller afvisning afventes, skal Begivenheden kunne eksistere og være synlig i de in- viteredes Xxxxxxxx men uden af blokere denne. | ||
Krav # 33 Responsmuligheder på invitationer til Begivenhed | |||
Kategori: | (K) | Type: | Funktionelt |
Beskrivelse: | Brugeren der indkalder til et møde eller en Møderække skal kunne angive hvordan de inviterede skal kunne respondere på invitationen, herunder; • Den inviterede accepterer • Den inviteredes leder accepterer på dennes vegne • Den inviterede accepterer, men dennes leder skal godkende inden det bliver endeligt • Arrangøren accepterer på vegne af de inviterede – bruges eksempel- vis når en restGruppe ikke har tilmeldt sig et obligatorisk kursus I forbindelse med en skole hjem-samtale, vælger Brugeren et af de indkaldte Tidsrum, hvorefter tilmeldingen gælder for Barnet/Elevens værger samt for Barnet. Såfremt værger har flere Børn i samme klasse eller på samme stue, vælger Brugeren (en af værgerne) et tidsrum for hvert Barn/Elev | ||
Krav # 34 Opdatering af inviteredes Kalender | |||
Kategori: | (K) | Type: | Funktionelt |
Beskrivelse: | Løsningen skal understøtte, at alle inviteredes Xxxxxxxx opdateres når en Be- givenhed ændres En Begivenhed kan f. eks. ændres ved at Brugeren der har oprettet Begiven- heden vælger at ændre i tidspunktet eller i en tilknyttet Ressource. | ||
Krav # 35 Udsende rykkere for manglende svar | |||
Kategori: | (K) | Type: | Funktionelt |
Beskrivelse: | Den Bruger der har oprettet Begivenheden, kan udsende rykkere for mang- lende svar til de Brugere der endnu ikke har svaret på invitationen. | ||
5.6.2 Se Kalendere og kalendervisninger
Der vil være mange forskellige behov for at skabe overblik vha. Kalenderen, f. eks.:
1) En Medarbejder åbner tre andre Medarbejderes Kalendere, samt et Lokales Kalender, for at finde næste mulige mødetidspunkt
2) En Leder i et Dagtilbud ønsker at se en samlet Kalender for en af Dagtilbuddets Stuer
3) En Leder på en Institution ønsker at se alt registreret ferie (som Brugere har oprettet som Begivenheder af typen ”Ferie”)
Krav # 36 Se Kalendere og kalendervisninger | |||
Kategori: | (K) | Type: | Funktionelt |
Beskrivelse: | Løsningen skal understøtte, at en Bruger i sin Kalender kan; • Se andre Brugeres Kalendere samt fremsøge bestemte Typer af Begi- venheder f. eks. ferie. • Se om Begivenheder er accepteret, ikke behandlet eller tentativ (delvis accepteret) • Se Kalendere der ikke er en del af Løsningen (f. eks. en Bruger der ”abonnerer” på sin Outlook eller Google el. lign.) • Skelne mellem flere Kalendere, så det tydeligt fremgår hvem en Ka- lender tilhører (f. eks. med farver). • Oprette en Begivenhed direkte fra visningen ved at klikke eller mar- kere et tidsrum. • Trække i en Begivenhed fra visningen for at ændre dens varighed. • Se det aktuelle tidspunkt, dvs. hvilken ugedag, dato, uge, måned og år. • Vælge daglig, arbejdsugentlig, ugentlig og månedlig visning af Kalen- der. • Se en miniatureoversigt over en måned ved siden af standardvisnin- gen (f. eks. som i Outlook eller Google). • Se døgn-begivenheder (Begivenheder med varighed på mere end et døgn, f. eks. ferie) på separat vis. f. eks. så de ligger som en bjælke i toppen af dagene (som f. eks. i Outlook eller Google) | ||
5.6.3 Få et forslag til næste mulige mødetidspunkt
For at lette en Brugers arbejdsbyrde ved planlægning af en Begivenhed med mange Brugere og potentielt en eller flere tilknyttede Ressourcer er der i Løsningen behov for, at Løsningen præsen- terer Brugeren for et forslag til næste mulige mødetidspunkt, hvor alle markerede Brugere og Res- sourcer er ledige.
Krav # 37 Næste mulige mødetidspunkt | |||
Kategori: | (K) | Type: | Funktionelt |
Beskrivelse: | Løsningen skal være i stand til at foreslå det næste mulige tidsrum med ud- gangspunkt i de valgte mødedeltageres Kalendere samt valgte Ressourcers Kalendere. | ||
5.6.4 Indkald til skole hjem-samtale og forældresamtaler
Skole-hjem- og forældresamtaler repræsenterer et behov der går udover almindelig kalenderfunkti- onalitet. Planlægning heraf sker ved at Pædagogisk personale markerer et antal tidsrum, som Værger kan tilmelde sig. Der gælder et først-til-mølle princip. Medarbejderen skal kunne arbejde med en samlet Begivenhed for et tidsrums samlede samtaler (eksempelvis alle samtaler en be- stemt eftermiddag mellem 14 og 16), hvortil Ressourcer knyttes (Lokale) samt de Medarbejdere, der skal deltage i samtalerne. Indenfor den samlende Begivenhed vil hver skole hjem-samtale fin- des, hvortil Værger og Elever er knyttet. Denne funktion bruges endvidere også ifm. indkaldelse til MUS samtaler for Medarbejdere. Nedenfor gives et eksempel på, hvad det er for et behov Løsnin- gen skal dække:
En Klasselærer er ansvarlig for 20 Elever og planlægger derfor to eftermiddage med hver 10 skole- hjem samtaler af 30 min varighed mellem kl.13 og 18. Klasselæreren opretter en Begivenhed, der dækker kl.13-18 hvortil der knyttes et Lokale samt en anden Medarbejder, der skal deltage i samt- lige samtaler, for hver dag. Herefter angives de Elever, der samlet set skal arrangeres samtaler for (eksempelvis en klasse). Værgerne til disse Børn og Xxxxxx inviteres til at tage et af de 20 samtale- tidspunkter fordelt på de to dage, hvilket de gør efter et først-til-mølle princip.
Use case UC-16 | Navn: Indkald til skole-hjem eller forældresamtaler |
Igangsættende aktør | Pædagogisk personale, Administrativ Medarbejder |
Formål, beskri- velse og af- grænsning | Brugeren ønsker at indkalde til skole-hjem eller forældresamtaler med Barn/Elever og Værger. Brugeren angiver ligeså mange mulige tidsrum (håndteret som en Begivenhed per tidsrum) som der er Børn og Elever, ofte fordelt over flere dage, hvorefter Værger vælger en tid per Barn/Elev. |
Hændelse | |
Forudsætninger | |
Handlinger | |
Bruger 1. Arrangerer en samlet Begivenhed 2. Knytter alle relevante Ressourcer (Lokaler kan eksempelvis være forskellige for de for- skellige dage), Medarbejdere og Elever 3. Angiver hvor lang tid der skal afsættes for hver samtale | |
Løsningen 5. Xxxxxxxx disse samtaler 6. Giver Børnenes eller Elevernes Værger mulighed for at booke et tidsrum per Barn (se use case ”Tilmeld eller frameld Begivenhed”) | |
Slutresultat | |
Alternativer: | |
6a: Såfremt de inviterede er Xxxxxxx der selv kan administrere tilmeldelse, booker de selv tilmel- ding 6b: Såfremt Inviterede ikke har svaret, kan arrangøren tilmelde Værger til bestemte samtaler (tidspunkter) | |
Sluttilstand | |
Bemærkninger: | |
Jf. 6A kan funktionaliteten også bruges ved indkaldelse til MUS-samtaler hvor Medarbejderne selv kan vælge et tidsrum og der ikke er nogen Værge involveret | |
Krav # 38 Use case UC-16: Indkald til skole-hjem eller forældresamtaler | |||
Kategori: | (K) | Type: | Funktionelt |
Beskrivelse: | Løsningen skal opfylde Use case UC-16. | ||
5.6.5 Håndter Ressourcer
Løsningen vil indeholde en række forskellige Ressourcer som Brugerne skal kunne booke til Begi- venheder, som strækker sig over;
• Lokaler (eksempelvis mødelokaler, undervisningslokaler, sportsplads m.v.)
• Materialer (eksempelvis buskort, indkøbskort, materialesamlinger til undervisningsbrug m.v.)
Ressourcer skal kunne deles internt på Institutionen, deles mellem flere Institutioner eller være til- gængelig på kommunalt niveau.
Use case UC-18 | Håndter Ressourcer |
Igangsættende aktør | Medarbejder |
Formål, beskri- velse og af- grænsning | En Bruger (oftest en Medarbejder med ansvar for at Institutionens/kommu- nens Ressourcer) skal kunne oprette og vedligeholde de Ressourcer andre Brugere kan booke til deres Begivenheder. |
Hændelse | |
Forudsætninger | |
Handlinger | |
Bruger 1. Opretter Ressource 2. Angiver navn, beskrivelse og antal (såfremt Ressourcen består af flere dele, eksempelvis ved sæt af tablets) 3. Angiver kategori og tilretter rettigheder 4. Uploader billede af Ressourcen (hvis relevant) | |
5. Angiver status for Ressourcen (eksempelvis hvis et Lokale er under renovering) | |
Slutresultat | |
Alternativer: | |
1a. Fremfinder eksisterende Ressource der skal redigeres | |
Sluttilstand | Ressource oprettet/redigeret |
Bemærkninger: | |
Krav # 39 Use case UC-18: Håndter Ressource | |||
Kategori: | (k) | Type: | Funktionelt |
Beskrivelse: | Løsningen skal opfylde Use case UC-18: Håndter kursus. | ||
Krav # 40 Håndter Ressourcekategorier og rettigheder | |||
Kategori: | (k) | Type: | Funktionelt |
Beskrivelse: | Løsningen lader Brugeren oprette og redigere kategorier for Ressourcer, samt angive rettighedsforhold for alle Ressourcer af den givne kategori. | ||
5.6.6 Instruktioner til vikar
Det skal være muligt for en Medarbejder, der ikke kan være på arbejde at knytte en Kommentar til lektionerne til brug for en vikar. Når Medarbejderen melder sig syg kan de samtidigt fra Kalenderen åbne dagens lektioner og tilknytte en Kommentar til vikaren (som på dette tidspunkt potentielt ikke er kendt). Vikaren skal, når denne er sat på lektionen, kunne se tilknyttede Kommentarer. Selve vikardækningen sker i Institutionens administrative system, mens videnoverlevering kan ske via Løsningen.
Krav # 41 Instruktioner til vikar | |||
Kategori: | (K) | Type: | Funktionelt |
Beskrivelse: | Løsningen skal understøtte, at en Medarbejder kan knytte en forklaring eller instruks til en lektion (Begivenhed), som den pågældende vikar kan se. Kun Brugere for hvem instruksen er relevant (fraværende Pædagogisk personale, vikar samt evt. Leder) kan se instruksen. | ||
Der er behov for i Løsningen at Brugerne kan registrere tidspunkter for hvornår et Barn eller Elev er kommet eller gået fra en Institution. Bemærk at Komme/Gå registrering understøtter de behov der er i Dagtilbud og SFO/SFO2, mens fraværsregistrering i Skolerne foretages i eksterne syste- mer.
Komme/gå registrering vil både være relevant at foretage i Institutionen (eksempelvis når Værge ankommer med Barn) og andetsteds fra (eksempelvis at melde et Barn sygt hjemmefra om morge- nen). Derfor skal Komme/gå funktionalitet bruges både fra Brugernes Dashboards og fra Infotavler opsat i Institutionerne.
5.7.1 Registrer Komme/gå for Barn/Elev
Det skal være muligt for Værger, Pædagogisk personale, og i visse tilfælde Xxxxxx, at registrere om et Barn eller en Elev er tilstede, herunder at angive hvornår Barn/Elev er ankommet og har for- ladt Institutionen, samt evt. tilknytte Kommentarer hertil.
Use Case UC-15 | Navn: Registrer Komme/gå for Barn/Elev |
Igangsættende aktør | Værge, Pædagogisk personale eller Elev |
Formål, beskri- velse og af- grænsning | For Børn og Elever der er tilknyttet et Dagtilbud eller en SFO/SFO2 (fritids- ordning/-klub) skal Løsningen understøtte at Institutionen kan holde styr på Komme/gå tider for Børn/Elever. Alt efter omstændigheder kan det være Pædagogisk personale der registrerer (eksempelvis ved ankomst til fritidsordning efter Skole), Værger (eksempelvis når et Barn afleveres i Børnehave om morgenen) eller Eleven (eksempelvis ved ankomst eller afgang fra fritidsklub) der registrerer Komme/gå. Det er samtidigt et behov at der kan tilknyttes Kommentarer til en dag, ek- sempelvis hvis en forælder angiver at sit Barn hentes af en anden person på den pågældende dag. Kommentarer skal samtidigt kunne tilknyttes med en fast gentagelse, eksempelvis i de tilfælde hvor en fritidsordning skal sende et Barn hjemad på et bestemt tidspunkt hver mandag. Registreringer skal kunne foretages på dagen eller ud i fremtiden, således at det også er muligt at registrere om et givent Barn/Elev er tilstede i en ferie. Registrering foregår typisk i Institutionen på en Infotavle, hvor Barn, Værge eller Pædagogisk Personale registrerer, men det sker dog også fra Brugernes egne enheder, når en Værge eksempelvis melder ferie eller sygdom for et Barn. |
Hændelse | |
Forudsætninger | |
Handlinger | |
Bruger 1. Fremfinder det rette Barn/Elev der skal registreres for 2. Angiver at være ankommet eller ved at forlade Institutionen 3. Værge eller Pædagogisk personale angiver en Kommentar til dagen Løsningen 4. Markerer grafisk at Barn/Elev er ankommet/ har forladt Institutionen | |
Slutresultat | |
Alternativer: | |
2a: Værge eller Pædagogisk personale angiver at et Barn/Elev er ankommet eller har forladt Insti- tutionen 2b: Værge eller Pædagogisk personale angiver at Barn/Elev slet ikke kommer, hvilket registreres med ”Syg”, ”Ferie” eller lignende. 2-3c: Værge eller Pædagogisk personale angiver for den specifikke dag, når en anden end Værge skal være henteansvarlig | |
3a: Værge eller Pædagogisk personale angiver en Kommentar der skal gentages med en fast fre- kvens (eksempelvis hver dag, en gang om ugen etc.) | |
Sluttilstand | |
Bemærkninger: | |
Krav # 42 Use case UC-15: Registrer Komme/gå for Barn/Elev | |||
Kategori: | (K) | Type: | Funktionelt |
Beskrivelse: | Løsningen skal opfylde Use case UC-15. | ||
Kategori: | (K) | Type: | Funktionelt |
Beskrivelse: | Løsningen skal tilbyde Medarbejdere at kunne se en oversigt over Komme/gå registreringer for Børn og Elever. Oversigten skal kunne ses for en Gruppe (f.eks. en hel Institution eller en Stue i en Børnehave), og tilbyde oversigter for den pågældende dag, en anden dag, eller sammenstillinger af registreringer over længere perioder (ex for en uge eller måned) | ||
Der er i Løsningen behov for et Galleri hvor Brugere kan gemme og dele Medier med hinanden. Det kan f. eks. være Billeder som Pædagogisk Personale tager ifm. en udflugt og efterfølgende vil dele med Forældre. Medier dækker udover Billeder også Lydfiler og Videoer.
Der er behov for, at Medier kan Opmærkes med informationer f. eks. hvilke Brugere der er på/i Me- diet samt en titel, et emne eller album, der kan benyttes til at gruppere Medierne. Derudover er det vigtigt at Opmærkning, Visning og Deling af Medier styres vha. Rettigheder, herunder hvilke Grup- per Brugere er medlem af og hvilken Brugeraktør de tilhører.
5.8.1 Håndter Medie
I Løsningen er der behov for at importere og håndtere Medier, da Pædagogisk Personale ofte kommunikerer med Værger via Billeder. Brugerne kan forventes at få adgang til mange Medier og vil i den forbindelse have behov for en oversigt over Medier, der er tilgængelige for den enkelte Bruger. Derudover er der behov for at Medier kan opmærkes med Brugere og Grupper. Opmærk- ning af Brugere er nødvendigt hvis det drejer sig om Medier af personfølsom karakter.
Som udgangspunkt skal alle Medier opmærkes når de importeres til Løsningen. Hvis der ikke op- mærkes en Bruger på Mediet, betragtes Mediet som værende ikke personfølsomt. Hvis en eller flere Bruger bliver Opmærket på et Medie, betragtes Mediet derimod som personfølsomt.
Samtykke spiller en stor rolle ifm. Medier. Hvis der f. eks. ikke er findes Samtykke jf. 5.4.1, til at dele Billeder eller Video, fra de Opmærkede Brugere, må Mediet ikke deles med andre. Løsningen skal derfor igennem Opmærkning styrer hvilke Brugere Medier bliver tilgængelige for.
Tilgængeligheden af Medier styres yderligere vha. Grupper og de gruppehierarkier der opbygges i Kommunerne.
Use Case UC-22 | Navn: Håndter Medie |
Igangsættende aktør | Medarbejdere, Værger, Børn og Elever |
Formål, beskri- velse og af- grænsning | En Bruger skal kunne importere Medier til Løsningen og Opmærke dem med de nødvendige Metadata, herunder Bruger, Grupper, titel, emne og/eller al- bum. |
Hændelse | |
Forudsætninger | |
Handlinger | |
Bruger 1. Overfører et Medie fra en Enhed 2. Opmærker Medie 3. Indtaster Brugere Medie | |
Slutresultat | |
Alternativer: | |
1a: Xxxxxxxx overfører flere Medier på en gang og Opmærker disse med Brugere og Grupper 1b: Brugeren ændrer navn og Opmærkninger på et Medie *: Brugeren sletter et Medie | |
Sluttilstand | |
Bemærkninger: | |
Regler om visninger af Medier og Opmærkninger fremgår af bilag 2.1.C. | |
Krav # 44 Use case UC-22: Håndter Medie | |||
Kategori: | (K) | Type: | Funktionelt |
Beskrivelse: | Løsningen skal opfylde Use case UC-22 – Håndter Medie. | ||
Krav # 45 Direkte import fra Enhed | |||
Kategori: | (K) | Type: | Funktionelt |
Beskrivelse: | Løsningen skal understøtte, at en Bruger fra en Enhed med kamera kan tage Billeder eller optage Video (f. eks. med en ”kamera knap” der tilgår enhedens kamera og/eller galleri), der automatisk importeres i Løsningen. Løsningen skal i forbindelse med importering af Billedet eller Videoen præ- sentere Brugeren for muligheder for Opmærkning. | ||
Krav # 46 Eksport til Enhed | |||
Kategori: | (K) | Type: | Funktionelt |
Beskrivelse: | Løsningen skal understøtte, at en Bruger kan downloade et eller flere Medier til sin Enhed, forudsat at Mediet ikke er Personfølsomt. I tilfælde af at Medie er Personfølsomt, kan de kun downloades af Brugeren der er Opmærket, såfremt ingen andre er Opmærket. Når Medier downloades, skal Metadata slettes fra Mediet, herunder også Op- mærkninger. |
Krav # 47 Åbne medier | |||
Kategori: | (K) | Type: | Funktionelt |
Beskrivelse: | Løsningen skal understøtte, at Brugerne kan afspille og/eller vise Medier Løsningen indeholder. Der henvises til Krav # 78 for beskrivelse af de formater og filtyper, der skal understøttes. | ||
En Notifikation er jf. bilag 2.1.A en kortfattet meddelelse, der er relevant for Brugeren, leveret på den måde Xxxxxxxx har valgt jf. UC-04.
Notifikationen skal varsle Brugeren om noget denne bør huske eller handle på baggrund af. Ek- sempler på Notifikationer jf. bilag 2.1.A kan være:
• En påmindelse om at man har skolehjem-samtale den efterfølgende dag
• En påmindelse om at ens Barn skal huske gummistøvler den efterfølgende dag
• En påmindelse om at der er kommet en Besked som man bør læse
En Notifikation består af tre dele; en hændelse der igangsætter den, en tekstuel meddelelse samt udsendelsen af denne meddelelse via en prædefineret kanal. En hændelse opstår når en bestemt situation opstår i Løsningen, eksempelvis
1. En Bruger foretager en bestemt handling (eksempelvis Opretter og sender en Begivenhed med aktiveret Notificering jf. UC-13)
2. Et tidspunkt er nået (f. eks. onsdag aften udsendes påmindelser til Værger om at Eleverne skal huske svømmetøj til dagen efter)
Til alle Notifikationer er knyttet en skabelon indeholdende tekst samt flettefelter (markeret med kur- siv);
1. ”Du har modtaget en ny Besked fra ”Xxxx Xxxxx” med emnet ”Fødselsdagsfejring i morgen” ””Kære ”Xxxx Xxxxx”. Vi har i dag registreret Fravær for din datter ”Xxxx Xxxxx”, som bety- der at hun har mere end 20 % Fravær i denne måned. ”Herefter kort tekst fra Skolen til Værgen””
2. ”Kære Værger – Husk at Børnene skal have svømmetøj med i morgen. Kh Jytte”
Notifikationer skal udsendes så de tager hensyn til hvordan de bedst præsenteres (eksempelvis kort eller lang tekst), hvordan Modtageren helst vil modtage Notifikationer, f. eks.;
1. SMS
2. E-mail
3. Notifikation i App
4. Pop-up på computerskærm
I nogle tilfælde kan Institutionen ønske at tvinge Notifikationen igennem en bestemt kanal. Der er gode erfaringer med at nå flest Værger gennem SMS, hvorfor en Bruger skal have mulighed for at gennemtvinge at en Notifikation udsendes via SMS eksempelvis.
Krav # 48 Tilknyt Notifikation | |||
Kategori: | (K) | Type: | Funktionelt |
Beskrivelse: | Løsningen skal understøtte, at Brugere kan oprette en Notifikation til sig selv eller en anden Bruger. Notifikationen skal indeholde den tekst (evt. Baseret på en skabelon) Brugeren ønsker, samt en (eller flere) relationer til et objekt i Løsningen, eksempelvis et tidspunkt, en Bruger, Besked, en Begivenhed eller et Opslag. En Notifikation skal kunne gentage sig i et fast interval, såfremt hændelsen der igangsætter den er dato/tidspunkt. Såfremt Xxxxxx har rettighederne hertil, skal Xxxxxxxx kunne definere hvilken kommunikationskanal Notifikationen udsendes igennem. Ellers vil Modtageren få Notifikation gennem sin foretrukne kommunikationskanal. | ||
Krav # 49 Udsend Notifikation | |||
Kategori: | (K) | Type: | Funktionelt |
Beskrivelse: | Løsningen skal understøtte at udsende Notifikationer som beskrevet i afsnit Krav # 43). | ||
Brugerne af Løsningen har behov for at kunne fremsøge data oprettet i Løsningen. Eksempler på behov for søgning;
• Fremsøge Brugere eller Grupper i forbindelse med oprettelse af en Besked, et Opslag eller en Begivenhed (se Use case UC-01, UC-02 og UC-13)
• Fremsøge bestemte Beskeder eller Opslag
• Fremsøge Medier (billeder, videoer og lydfiler) en Bruger ønsker at knytte til en Besked, Opslag eller Begivenheder (se Use case UC-01, UC-02 og UC-13)
• Fremsøge Ressourcer administreret i Løsningen (eksempelvis it-udstyr, buskort, Lokaler m.v.) når en Begivenhed skal planlægges (se Use case UC-13)
Det er samtidigt et behov at Brugere har adgang til visninger af præ-definerede søgninger, eksem- pelvis en side der viser alle Værger til Børn på en bestemt stue i et Dagtilbud.
Krav # 50 Søgning i Løsningen | |||
Kategori: | (K) | Type: | Funktionelt |
Beskrivelse: | Løsningen skal understøtte, at Brugere kan fremsøge data, der findes i Løs- ningen og som Brugeraktøren har rettigheder til at se (se afsnit 6.5). Søgemu- ligheder og -resultater skal præsenteres for Brugeraktøren på en, for denne, forståelig og overskuelig måde og præsentere Stamdata nødvendige for at forstå søgeresultatet. Relevante søgemuligheder er eksempelvis; • Find Profil (Bruger) • Søgeresultat: Liste over Brugere, hvorfra der kan navigeres til Stamdata om Brugeraktøren • Find Kontakter (jf. Afsnit 5.3.4.1 og 5.4.2) og Grupper • Søgeresultat: Liste over Brugeraktørens egne Kontakter med relevante Stamdata • Find Gruppe • Søgeresultat: Liste over Grupper med relevante opsumme- rende data, hvorfra der kan navigeres til Gruppens Dashboard • Find Kursus • Søgeresultat: Liste over Kurser, hvorfra der kan navigeres til Kursets beskrivelse • Find Ressource • Søgeresultat: Liste over Ressourcer (Lokaler, Materialer m.v.), hvorfra der kan navigeres til Ressourcens beskrivelse • Find Opslag • Søgeresultat: Liste over Opslag, hvorfra der kan navigeres til selve Opslaget • Find Besked • Søgeresultat: Liste over Beskeder, hvorfra der kan navigeres til selve Beskeden • Find Notifikation • Søgeresultat: Liste over Notifikationer, hvorfra der kan navige- res til selve Notifikationen • Find Dokument/Fil • Søgeresultat: Liste over Dokumenter, hvorfra der kan navige- res til selve Dokumentet • Find Medie • Søgeresultat: Liste over Medier (eksempelvis Billeder), hvorfra der kan navigeres til selve Mediet Søgemuligheder og –resultater afhænger af Brugeraktørens rettigheder. Søgemuligheder og visning af søgeresultat skal afklares med udgangspunkt i bilag 2.1.A i samarbejde med KOMBIT i Afklaringsfasen. |
| |||
Kategori: | (K) | Type: | Funktionelt |
Beskrivelse: | Løsningen skal understøtte at lave visninger med præ-definerede søgninger, så som eksempelvis en liste over 1.A´s lærere. | ||
Kategori: | (K) | Type: | Funktionelt |
Beskrivelse: | Løsningen skal understøtte at Brugere kan bruge alle typer trunkering samt boolske operatorer i søgefelter. | ||
| |||
Kategori: | (K) | Type: | Ikke funktionelt |
Beskrivelse: | Løsningen skal give Brugerne en hjælpende hånd ved at tilbyde suggestive search ved indtastningsfelter, hvor det giver mening, så det øger kvaliteten af Brugerens indtastninger. Suggestive search kan være en af følgende typer eller en blanding heraf: •Populære søgninger •Minisøgeresultatet •Registeropslaget (auto complete) •Søgehistorik Populære søgninger viser f. eks. Profiler rangeret efter, hvor ’populære’ de er, minisøgeresultat indeholder yderligere information (f. eks. billede eller detalje- rede oplysninger), registeropslaget indeholder en liste (f. eks. Kontakter op- delt alfabetisk), søgehistorik viser f. eks. tidligere søgninger eller indtastnin- ger. | ||
| |||
Kategori: | (K) | Type: | Ikke funktionelt |
Beskrivelse: | Løsningen skal understøtte inkremental søgning, hvor Løsningen søger for hvert tegn Brugeren indtaster. Xxxxxxxx præsenteres for søgeresultater efter- hånden som der indtastes tegn. Løsningen skal derudover præsentere forslag til hvad det komplette ord kunne være (når en Bruger indtaster ”Bø” viser Løsningen resultater for ”Bø” og foreslår Brugeren de oftest søgte ord startende med ”Bø”, eksempelvis ”Børn”, ”Børge” og ”Bølle”) | ||
Systemadministration foregår i tre niveauer i Løsningen:
Centralt i det fælles Driftsmiljø, hvor en Central Administrator kan foretage ændringer, som omfat- ter og påvirker hele Løsningen.
I hver enkelt Kommune, hvor en Kommunal Administrator kan foretage Kommunespecifikke tilpas- ninger.
På hver enkelt Institution, hvor en Institutions Administrator kan foretage Institutionsspecifikke til- pasninger.
I afsnit 5.11.5, 5.11.9 og 5.11.13 nedenfor gennemgås use cases for de enkelte administrations- områder.
Administratorerne har ansvaret for at administrere Løsningens Grupper og tilknytte dem hierarkier. Hvilke hierarkier og Institutioner Grupper kan knyttes til afhænger af Administratorens niveau.
Indledningsvis gennemgås nedenfor generelle krav, som er gældende på tværs af de tre niveauer (Institution, Kommunalt, Centralt). Herefter gennemgås krav til Hjemmesider og Infotavler for Insti- tutioner, da opsætning heraf styres af Administratorer.
5.11.1 Håndter Grupper
Kommentar omkring Grupper ifm. reviewfasen: Nedenstående præsenterer de behov KOMBIT ser for at håndtere Grupper, der nødvendigvis ses som en meget central del af løsningen. Det er pt ikke afklaret med STIL (som er ansvarlig for Uni-login) hvor meget af denne funktionalitet der vil forefindes i Uni-login og hvor meget der skal implementeres som en del af Samarbejdsplatformen.
Alle Brugere i Løsningen kan inddeles i Grupper, der har fælles behov f. eks. for at se en fælles Kalender eller modtage de samme Opslag. Der er derfor behov for at Løsningen understøtter Grupper, så Brugere kan knyttes til hinanden og håndteres samlet. Eksempler på Brugere der har samme behov kunne f. eks. være alle Værger med tilknytning til en klasse, eller alle Medarbejdere med tilknytning til en Institution.
Grupper vil gøre Kommunikation mellem Brugerne lettere, da Grupper kan benyttes som Modta- gere af Beskeder, Opslag og Begivenheder, samt opmærkes på Medier og gives adgang til Sikker fildeling. Grupper vil kunne have et fælles Dashboard (se afsnit 6.1.2.1) så Grupperne har lettere ved at samarbejde. På denne måde vil Grupper understøtte at Brugere kan sende og modtage målrettet information. Derudover vil Grupper gøre det lettere at filtrere og tilgængeliggøre Medier. Hvis en Gruppe f. eks. er Opmærket på Medier, vil Brugere, der er en del af Gruppen kunne tilgå Mediet jf. afsnit
GalleriKrav # 43. For Administratorer vil Grupper gøre det lettere at håndtere rettighedsstyring, da de vha. Grupper kan indstilles for flere af gangen.
A
Forvaltning
Skole
A
Skole
B
Dagtilbud
A
stratorer
Mellem-
skole
1.
5.
7.
9.
8.
Udskole
2b
2a
1b
1a
3.
2.
Indsko- ling
B
4.
Alle Lærere
Alle Værger
6.
Figur 5 Eksempel på Gruppe hierarki A
Til Forvaltningen er der tilknyttet flere Grupper f. eks. Institutioner, som indeholder yderligere Grup- per. Figur 6 er et eksempel på Indskolingen under en af Forvaltningens Skoler (Figuren tager ud- gangspunkt i firkant B fra ovenstående figur).
B
Indskoling
1.
Indskolings
lærere
1a
1a For-
ældre
Lærer- team
Elever
Projekt
Alle indsko- lings foræl- dre
Figur 6: Eksempel på Gruppe hierarki B
Use case UC-17 | Navn: Håndter Grupper |
Igangsættende aktør | Administratorer |
Formål, beskri- velse og af- grænsning | Administratorer skal kunne Oprette Grupper og tilknytte Brugere. Brugere kan benytte Grupperne i forbindelse med Beskeder, Opslag, Begivenheder, Sik- ker fildeling, Galleri og Søgning. Institutionens Administrator skal kunne danne Grupper, der kan benyttes af Brugere tilknyttet Institutionen. Den Kommunale Administrator skal kunne danne Grupper på tværs af Kom- munen, der kan benyttes af alle Brugere i Kommunen. Den Centrale Administrator skal kunne danne Grupper på tværs af Kommu- ner, der kan benyttes af alle Brugere i alle Kommuner. Ved at have en hierarkisk struktur for Grupper, kan grupperettigheder lettere styres. En Gruppe kan nedarve specifikke rettigheder fra en anden Gruppe. Derudover vil en hierarkisk struktur give Administratorerne bedre overblik over Grupperne og deres sammenhæng. Grupper skal også kunne oprettes udenfor hierarki, dvs. uden relationer, f. eks. 8 Elever fra forskellige klasser der laver et projekt sammen. Se ovenstående figur for et eksempel på et hie- rarki for en Skole i en Forvaltning. Ved at opsætte regler for Grupper, kan Administratorer styre hvilke Brugere der kan og ikke kan, være medlemmer af Gruppen, hvilke Brugere der skal og ikke skal være medlemmer, samt hvilke regler der skal og ikke skal kunne nedarves. En Gruppe ”Forældre 1a” kunne f. eks. have en regel der automa- tisk tilknyttede alle Værger til Elever i 1a til Gruppen, samt alle Grupper der nedarver fra ”Forældre 1a”. Grupperettigheder vil gøre det lettere at administrere Brugere og deres ret- tigheder i Løsningen. Specifikt indhold kan eksempelvis gøres tilgængeligt for alle medlemmer af en eller flere specifikke Grupper, og evt. de Grupper der nedarver fra de valgte Grupper. Til nogle Grupper skal der kunne tilknyttes en fælles postkasse. Fællespost- kasser benyttes bl.a. af Institutioner for at kunne give en kontaktadresse på Institutionens Hjemmeside, der kan håndteres af flere Brugere, så en enkelt Bruger f. eks. en Leder ikke bliver flaskehals i behandling af Beskeder. |
Hændelse | |
Forudsætninger | |
Handlinger | |
Bruger 1. Opretter Gruppe 2. Angiver gruppeinformation 3. Angiver hierarkisk placering ift. andre Grupper 4. Angiver regler 5. Angiver rettigheder 6. Tilknytter Brugere 7. Angiver om Gruppen skal have egen Kalender og hvem der må oprette Begivenheder i denne | |
8. Angiver om Gruppen skal have eget Gruppe-dashboard 9. Angiver om Gruppen skal have tilknyttet en Fællespostkasse | |
Slutresultat | Gruppe oprettes |
Alternativer: | |
1a-6a: Redigér og nedlæg Grupper 6b: Fjern Tilknytning | |
Sluttilstand | |
Bemærkninger: | |
Krav # 56 Use Case UC-17: Håndter Grupper | |||
Kategori: | (K) | Type: | Funktionelt |
Beskrivelse: | Løsningen skal opfylde Use case UC-17. | ||
Krav # 57 Gruppeadministrator | |||
Kategori: | (K) | Type: | Funktionelt |
Beskrivelse: | For at undgå at Administratorerne skal benytte unødigt meget tid på at admi- nistrere Grupper, f. eks. med at tilknytte nye medlemmer, opstille rettigheder eller regler, slette upassende Opslag mm. er der behov for at de kan uddele- gere noget af dette ansvar til udvalgte Brugere i Grupperne. Administrator skal kunne tildele gruppemedlemmer rettigheder, til at admini- strere Grupper. | ||
Krav # 58 Automatisk Tilknytning og Grupperettigheder | |||
Kategori: | (K) | Type: | Funktionelt |
Beskrivelse: | Løsningen skal understøtte at tilknytning, fjern tilknytning og tildeling af ret- tigheder, kan automatiseres vha. af regler. Hvilke regler og parametre der skal gælde for dette indstilles af Administratorer, eller Gruppeadministrator udvalgt af Administrator. Det kunne f. eks. være at Værger automatisk skiftes fra en Gruppe til en anden når tilknyttede Barn/Elev, skifter fra Indskoling til Mellem- skole. Dette ville mindske det administrative arbejde i Grupperne. | ||
5.11.2 Generelle krav til administration
Kategori: | (K) | Type: | Funktionelt |
Beskrivelse: | Der er behov for at Administratorer kan styre hvilke Samtykke og Tilladelser der skal påkræves udfyldt fra Brugere. Løsningen skal understøtte, at Administratorer kan styre hvilke Samtykke og Tilladelser der er obligatoriske og skal besvares af Brugere, og hvilke der opti- onelle. | ||
Krav # 60 Styring af Gallerirettigheder | |||
Kategori: | (K) | Type: | Funktionelt |
Beskrivelse: | For at forhindre at Galleri ikke bliver benyttet uhensigtsmæssigt, er det nød- vendigt at Medarbejdere kan styre Kontaktforældre, Børn og Elevers rettighe- der til at uploade Medier. Samt slette Medier (hvis det f. eks. er uploadet ved en fejl, eller er upassende), og gendanne slettede Medier. Løsningen skal understøtte, at Medarbejdere kan: • Fratage og tildele Kontaktforældre, Børn og Elevers rettighed til at uploade Medier • Slette og gendanne Medier uploadet af Kontaktforældre, Børn og Ele- ver Løsningen skal understøtte, at Institutionsadministrator kan: • Fratage og tildele alle Institutionstilknyttede Brugeres rettighed til at uploade Medier • Slette og gendanne Medier uploadet af alle Institutionstilknyttede Bru- gere Løsningen skal understøtte, at Kommunaladministrator kan: • Fratage og tildele alle Kommunens Brugeres rettighed til at uploade Medier • Slette og gendanne Medier uploadet af alle Kommunens Brugere Løsningen skal understøtte, at Centraladministrator kan: • Fratage og tildele alle Løsningens Brugeres rettighed til at uploade Medier • Slette og gendanne Medier uploadet af alle Løsningens Brugere | ||
5.11.3 Hjemmesider
Institutioner har af flere årsager behov for at kunne opsætte og redigere en Hjemmeside tilgænge- lig på Internettet. Behovet udspringer både af lovkrav, men også af et behov for at kunne informere Forældre, der står foran at skulle vælge Dagtilbud eller Skole.
Ifølge Bekendtgørelse af lov om gennemsigtighed og åbenhed i uddannelserne jf. afsnit 6.4 har In- stitutioner pligt til at udstille visse informationer. I praksis udstilles disse informationer på Hjemme- sider for Dagtilbud og Skoler. I forbindelse med lovgrundlaget er der bl.a. tale om, at Institutionerne skal udstille informationer som:
• Institutionens udbud af uddannelser og fagudbud
• Institutionens aktuelle værdigrundlag og pædagogiske udgangspunkt
• Institutionens gennemsnit af de afsluttende afgangsprøvekarakterer
• Institutionens resultater af evalueringer af kvaliteten af undervisningen
Herudover vil der typisk indgå alt fra Kontaktoplysninger, oplysninger om bestyrelsens arbejde til ledige stillinger på Hjemmesiderne. En udtømmende liste fremgår af bilag 2.1.H samt i bilag 2.3 Informationsmodel.
Ud over de lovmæssige informationer benytter Institutioner Hjemmesider som information til kom- mende Børn og deres Værger, både Værger der allerede har Børn på Institutionen men også til Værger, der overvejer forskellige Institutioner. I den forbindelse er det væsentligt, at der på den en- kelte Institution kan foretages tilpasninger af Hjemmesiden. Der er dog ikke tale om at understøtte et behov for meget avancerede Hjemmesider, hvorfor det forventes at langt hovedparten af Institu- tioner vil benytte Den Centrale Hjemmesideskabelon evt. med få tilpasninger foretaget af den Kommunale Administrator jf. UC-06 og UC-07.
Som det fremgår af UC-01 er der behov for, at bl.a. Ledere kan væge at publicere Opslag rettet mod en Institutions Hjemmeside frem for 4.b og på den måde publicere indhold offentligt.
Use case UC-19 | Navn: Administrer Hjemmesider |
Igangsættende aktør | Institutionens Administrator |
Formål, beskri- velse og af- grænsning | Institutions Administratoren skal kunne administrere en Hjemmeside der kan gøres tilgængelig på Internettet. Første gang Institutionens Administrator skal opsætte Hjemmesiden tages der udgangspunkt i den eller de skabelon(er), der er stillet til offentliggjort af den Kommunale Administrator jf. Fejl! Henvisningskilde ikke fundet. I arbejdet med Hjemmesiden skal Institutionens Administrator kunne tilpasse menuer og sider, samt tilføje tekst og Medier til sider. Med tilpasning af me- nuer menes at der skal kunne tilføjes nye og ændres i eksisterende. Herudover skal Institutionens Administrator kunne tilføje Moduler fra Løsnin- gen jf. afsnit 6.1.2.2.1 samt Widgets jf. afsnit 6.1.2.2.2, da disse kan have værdi for Værger eller andre, der tilgår Hjemmesiden. |
Hændelse | |
Forudsætninger | |
Handlinger | |
Bruger 1. Vælger Hjemmeside 2. Tilpasser menuer 3. Administrerer nye sider under menupunkter 4. Administrerer tekst, links og Medier til sider 5. Administrerer Moduler på Hjemmesiden (jf. afsnit 6.1.2.2.1) 6. Administrerer Widgets på Hjemmesiden (jf. afsnit 6.1.2.2.2) 7. Vælger at offentliggør den opdaterede Hjemmeside Løsningen 8. Offentliggør Hjemmeside på internettet | |
Slutresultat | Hjemmeside er offentliggjort |
Alternativer: | |
1a: Institutionens Administrator vælger en skabelon første gang Institutionens Hjemmeside skal sættes op. | |
Sluttilstand | |
Bemærkninger: | |
Krav # 61 Use case UC-19: Administrer Hjemmeside | |||
Kategori: | (K) | Type: | Funktionelt |
Beskrivelse: | Løsningen skal opfylde Use case UC-19. | ||
Kategori: | (K) | Type: | Funktionelt |
Beskrivelse: | Løsningen skal understøtte, at der stilles Hjemmeside skabeloner til rådighed for den Centrale Administrator. Hjemmeside skabelonerne kan herefter tilpasses af den Kommunale Admini- strator jf. Use case 19. I forbindelse med Hjemmeside skabelonerne skal der tages udgangspunkt i bilag 2.1.H, hvoraf typiske menuer og forventet indhold fremgår. Leverandøren skal i samarbejde med KOMBIT i Afklaringsfasen fastlægge designmuligheder for Hjemmesider samt detaljer for indholdet på Hjemmesi- der. | ||
Krav # 63 Søgemaskineoptimering for Hjemmesider | |||
Kategori: | (K) | Type: | Funktionelt |
Beskrivelse: | Løsningen skal understøtte, at Hjemmesider kan optimeres til søgemaskiner (SEO - Search Engine Optimization). | ||
Krav # 64 Sekretæradgang til Hjemmeside | |||
Kategori: | (K) | Type: | Funktionelt |
Beskrivelse: | Løsningen skal understøtte, at Sekretæren i Bestyrelsen jf. afsnit 5.12.2 kan publicere referater eller andre Dokumenter til Institutionens Hjemmeside. | ||
5.11.4 Infotavler
Infotavler skal forstås som det indhold der findes på skærme, der f. eks. findes på væggen inden for døren i et Dagtilbud, hvor der kan udstilles Opslag jf. afsnit 5.3.1 eller Komme/Gå jf. afsnit 5.7.
I forbindelse med Infotavlerne er der behov for at kunne udarbejde forskellige visninger rettet mod forskellige Brugere f. eks. Værger eller Pædagogisk Personale, da disse Brugere har forskellige behov. Pædagogisk Personale har f. eks. behov for at se Opslag rette mod Medarbejdere og Vær- ger har behov for Opslag omhandlende Børn og Xxxxxx.
I dag benyttes Infotavler primært til at udstille information om aktiviteter i Kalenderen samt gene- relle informationer f. eks. at gymnastiksalen er lånt ud eller at pædagogisk læringscenter (skolebib- lioteket) er lukket og vil med Løsningen stadig være behov, der skal understøttes igennem Opslag, der udstilles på Infotavler.
Som det fremgår af UC-01 er der behov for, at bl.a. Ledere kan væge at publicere Opslag rettet mod en Infotavle frem for 4.b og på den måde publicere indhold rettet mod en af nedenstående Grupper.
Eksempler på placering af Infotavler (de fysiske skærme):
• Personalerummet hos Pædagogisk Personale
• Pædagogisk læringscenter (skolebibliotek)
• SFO
• I åbne rum på Skoler eller Dagtilbud (ofte ved indgangen eller udenfor hver stue i Dagtil- bud)
Use case UC-20 | Navn: Administrer Infotavler |
Igangsættende aktør | Institutionens Administrator |
Formål, beskri- velse og af- grænsning | Institutionens Administrator skal kunne administrere indhold på Infotavler. Første gang Institutionens Administrator skal opsætte en Infotavle tages der udgangspunkt i den eller de skabelon(er), der er stillet til offentliggjort af den Kommunale Administrator jf. Fejl! Henvisningskilde ikke fundet.. I arbejdet med Infotavler skal Institutionens Administrator kunne tilpasse me- nuer og sider, samt tilføje tekst og Medier til sider. |
Hændelse | |
Forudsætninger | |
Handlinger | |
Bruger 1. Vælger Infotavle 2. Tilføjer tekst og Medier 3. Administrerer Moduler på Infotavlen (jf. afsnit 6.1.2.2.1) 4. Administrerer Widgets på Infotavlen (jf. afsnit 6.1.2.2.2) 5. Gemmer den tilpassede Infotavle | |
Slutresultat | Infotavle er administreret og gemt |
Alternativer: | |
1a: Institutionens Administrator vælger en skabelon første gang Institutionens Infotavler skal sæt- tes op, opsætter denne og giver den et sigende navn. * Institutionens Administrator ændrer navnet på en eksisterende Infotavle | |
Sluttilstand | |
Bemærkninger: | |
Krav # 65 Use case UC-20: Administrer Infotavle | |||
Kategori: | (K) | Type: | Funktionelt |
Beskrivelse: | Løsningen skal opfylde Use case UC-20. | ||
Krav # 66 Infotavle skabelon
Kategori: | (K) | Type: | Funktionelt |
Beskrivelse: | Løsningen skal understøtte, at der stilles Infotavle skabeloner til rådighed for den Centrale Administrator. Infotavle skabelonerne kan herefter tilpasses af den Kommunale Administra- tor jf. use case 20. Leverandøren skal i samarbejde med KOMBIT i Afklaringsfasen fastlægge designmuligheder for Infotavler samt detaljer for indholdet på Infotavler. | ||
Krav # 67 Udstilling af Infotavler | |||
Kategori: | (K) | Type: | Funktionelt |
Beskrivelse: | Løsningen skal understøtte, at Infotavler kan udstilles på fysiske skærme der findes på Institutioner og har adgang til internettet. Dette kan f. eks. gøres ved at danne en URL og et login, som knyttes til Info- tavlen. Herefter vil en Bruger kunne tilgå URL’en på et skærm med forbin- delse til internettet. | ||
5.11.5 Central administration
5.11.6 Administrer indstillinger
Use case UC-10 | Navn: Administrer indstillinger |
Igangsættende aktør | Central Administrator |
Formål, beskri- velse og af- grænsning | Den Centrale Administrator opsætter hvilke Stamdata Brugere skal indtaste og hvilke der er valgfri jf. bilag 2.1.A. Herudover skal Administratoren kunne opsætte centrale indstillinger om kom- munikationskanaler, der er åbne f. eks. Værger til Pædagogisk Personale og Værger til Elever. Som udgangspunkt forventes alle kommunikationskanaler åbne og administreret af henholdsvis den Kommunale og Institutions- Admini- stratorerne. Der kan dog komme lovændringer eller ændringer af praksis, der skal gennemføres på landsplan. Disse ændringer skal kunne foretages af den Centrale Administrator. Lovændringer eller ændringer af praksis kan også føre til et behov for nye indtastningsfelter, hvorfor den Centrale Administrator skal kunne tilføje så- danne i Løsningen. |
Sidst skal den Centrale Administrator kunne administrere hvilke Brugere jf. 4.1, der skal have adgang til Sikker fildeling jf. 5.5. | |
Hændelse | |
Forudsætninger | |
Handlinger | |
Bruger 1. Indstiller hvilke Stamdata der er valgfri og hvilke der er krævede 2. Tilføjer indtastningsfelter til Stamdata (som ikke findes i dag) 3. Administrerer kommunikation mellem Brugere 4. Administrerer indstillinger for Sikker fildeling | |
Slutresultat | Indstillinger er opdaterede |
Alternativer: | |
Sluttilstand | |
Bemærkninger: | |
Krav # 68 Use case UC-10: Administrer indstillinger | |||
Kategori: | (K) | Type: | Funktionelt |
Beskrivelse: | Løsningen skal opfylde Use case UC-10. | ||
5.11.7 Opsæt Centralt-definerede Dashboards
Som del af projektet udarbejdes en række Dashboards (se afsnit 6.1.2.1) der skal dække de en- kelte Brugergruppers behov for information. Disse Dashboards kan efterfølgende administreres centralt (ved ændringer der skal gælde for alle Brugere af Løsningen), i Kommunen (eksempelvis at tilføje de Widgets Kommunen har adgang til fra deres leverandører) eller på Institutionen. Såle- des skal det forstås at Dashboard for Pædagogisk Personale på Skole X er baseret på Institutio- nens Dashboard for Pædagogisk Personale, der er baseret på kommunens Dashboard for Pæda- gogisk Personale som igen er baseret på et centralt defineret Dashboard for Pædagogisk Perso- nale.
Use case UC-11 | Navn: Opsæt centralt-definerede Dashboards |
Igangsættende aktør | Central Administrator |
Formål, beskri- velse og af- grænsning | Løsningen skal understøtte, at der fra centralt hold kan opsættes Dashboards der fungerer umiddelbart, men som kan viderebearbejdes i Kommune eller In- stitution. Den Centrale Administrator skal kunne vedligeholde disse Dashboards (se afsnit 6.1.2.1), så de understøtter behovet for Dashboards for Brugeraktørgrupper f. eks. Pædagogisk Personale jf. krav 91. Den Cen- trale Administrator vælger bl.a. hvilke delelementer, der skal være enten fast- låste eller kunne redigeres samt hvilke elementer den Kommunale og Institu- tions Administratorerne skal kunne opsætte. |
Hændelse |
Forudsætninger | |
Handlinger | |
Bruger 1. Tilpas centralt-definerede Dashboards 2. Vælg hvilke elementer der er låst og hvilke der er valgbare 3. Publicer de centralt-definerede Dashboards | |
Slutresultat | Centralt-definerede Dashboards er publiceret |
Alternativer: | |
1a-2a: Brugeren vælger et af de eksisterende centralt-definerede Dashboard og tilpasser denne. 3a: Brugeren vælger at gemme det pågældende Dashboard uden at publicere det. | |
Sluttilstand | |
Bemærkninger: | |
Krav # 69 Use case UC-11: Opsæt centrale Dashboard skabeloner | |||
Kategori: | (K) | Type: | Funktionelt |
Beskrivelse: | Løsningen skal opfylde Use case UC-11. | ||
5.11.8 Opsæt nye Widget-leverandører og Widgets
Den Centrale Administrator har ansvar for at sikre at nye Widget-leverandører og Widgets som Kommuner har indgået aftaler med og om, gøres tilgængelige via Løsningen. Når den Centrale Ad- ministrator har gjort den nye Widget-leverandørs Widgets, eller nye Widgets fra en eksisterende Widget-leverandør, tilgængelig, kan Kommuner og Institutioner tilføje Widgets til kommunalt-defi- nerede Dashboards og Institutions-definerede Dashboards.
Use case UC-21 | Navn: Opsæt nye Widget-leverandører og Widgets |
Igangsættende aktør | Central Administrator |
Formål, beskri- velse og af- grænsning | Når nye Widgets skal tilbydes i Løsningen, skal den Centrale Administrator indtaste de nødvendige oplysninger om Widget-leverandør og Widgets, for at Widgets kan gøres tilgængelig for Brugerne. |
Hændelse | Ny Widget-leverandør eller Widget ønskes ibrugtaget |
Forudsætninger | |
Handlinger | |
Bruger 1. Indtaster oplysninger om Widget-leverandør 2. Indtaster tekniske oplysninger (adresse på Widget m.v.) 3. Udgiver Widget Løsningen 4. Gør Widget tilgængelig for Brugerne (der har rettigheder til at se den pågældende Widget, se afsnit 6.5) | |
Slutresultat | Widget(s) fra Widget-leverandør udgivet og tilgængelige |
Alternativer: | |
1a: Ændrer i oplysninger om Widget-leverandør 2b: Ændrer i eksisterende tekniske oplysninger om Widget | |
Sluttilstand | |
Bemærkninger: | |
Oplysninger om Widget-leverandør og tekniske oplysninger afdækkes når et teknisk koncept fore- ligger for Løsningen. | |
Krav # 70 Use case UC-21: Opsæt nye Widget-leverandører og Widgets | |||
Kategori: | (K) | Type: | Funktionelt |
Beskrivelse: | Løsningen skal opfylde Use case UC-21. | ||
5.11.9 Kommunal Administration
I forbindelse med Løsningen er der behov for, på kommunalt niveau, at administrere Stamdata for Kommunen og håndtere Dashboard skabeloner på tværs af kommunale Institutioners Dashboards. Herudover skal der vælges en standardopsætning for de enkelte Brugere.
5.11.10 Administrer Stamdata og indstillinger for Kommunen
Use case UC-08 | Navn: Administrer Stamdata og indstillinger for Kommunen |
Igangsættende aktør | Kommunal Administrator |
Formål, beskri- velse og af- grænsning | Den Kommunale Administrator skal kunne inddatere Stamdata om Kommu- nen i Løsningen til brug for bl.a. Hjemmesiden jf. afsnit 5.11.3. Herudover skal den Kommunale Administrator kunne opsætte kommunespecifikke ind- stillinger som eksempelvis, hvilke kommunikationskanaler der er åbne, herun- der Værger til Pædagogisk personale og Værger til Elever, Værger til Vær- ger, Værger til Elever, Elever til Værger, Elev til Elev samt lukke for en Gruppe. Behovet udspringer af, at der er forskellige kanalstrategier fra Kommune til Kommune. Styring af kommunikationskanaler er endvidere væsentlig i forbin- delse med f. eks. legeaftaler, sociale eller faglige arrangementer, hvor Bru- gere har behov for at kunne se Profiler og Stamdata samt skrive Beskeder til Brugere, der er tilknyttet en anden Klasse eller Stue på Institutionen. Løsningen opererer med sit eget lokale brugerkatalog jf. afsnit 6.5, hvor til- delte roller og dataafgrænsninger kan gemmes per Bruger. Der er derfor be- hov for, at Administratoren kan håndtere rettigheder for Brugere i Kommunen. I forbindelse med Fællespostkasser skal den Kommunale Administrator kunne tildele Brugerrettigheder til at se og sende Beskeder fra en Fællespost- kasse. |
Hændelse | |
Forudsætninger | |
Handlinger | |
Bruger 1. Indtaster Stamdata (Jf. bilag 2.1.A Begrebs- og Informationsmodel) 2. Administrer rettigheder for Brugere 3. Administrer kommunikation mellem Brugere 4. Administrer indstillinger for Sikker fildeling 5. Administrer Fællespostkasser jf. afsnit 5.11.1Fejl! Bogmærke er ikke defineret. | |
Slutresultat | Stamdata og indstillinger for Kommunen er indtastet og indstillet |
Alternativer: | |
1a: Brugeren opdaterer Stamdata samt indstillinger for Kommunen, hvorefter Løsningen opdate- rer Stamdata og udstiller de opdaterede Stamdata. | |
Sluttilstand | |
Bemærkninger: | |
Krav # 71 Use case UC-08: Administrer Stamdata og indstillinger for Kommunen | |||
Kategori: | (K) | Type: | Funktionelt |
Beskrivelse: | Løsningen skal opfylde Use case UC-08. | ||
5.11.11 Opsæt kommunalt-definerede Dashboard skabeloner
Use case UC-09 | Navn: Opsæt kommunalt-definerede Dashboard skabeloner |
Igangsættende aktør | Kommunal Administrator |
Formål, beskri- velse og af- grænsning | Det er forskelligt fra Kommune til Kommune, hvor meget arbejde der forven- tes lagt i Dashboards for Institutioner og om design og indhold styres fra Kommunen eller den enkelte Institution. Der er derfor behov for, at en Kom- munal Administrator kan fastsætte et design og indhold, herunder hvilke Widgets og moduler samt hvordan de grupperes på et Dashboard. Den Kommunale Administrator forventes at tager udgangspunkt i de centralt- definerede Dashboards i forbindelse med implementeringen af Løsningen og gradvist overgå til at tilpasse et kommunalt Dashboard (alternativ 1a) Design skal i denne Use Case forstås som placering af Widgets og moduler i brugergrænsefladen, samt generelle designelementer som baggrundsfarve, Institutionens logo/symbol m.v. |
Hændelse | |
Forudsætninger | |
Handlinger | |
Bruger | |
1. Redigerer og tilpasser centralt-defineret Dashboard, herunder indsættes Widgets fra Widget-leverandører 2. Vælger prøvevisning Løsningen 3. Henter Stamdata indtastet i Løsningen (se UC-08) 4. Præsenterer prøvevisning for Bruger Bruger 5. Vælger hvilke elementer Institutions Administratoren skal kunne tilpasse 6. Publicerer kommunalt-defineret Dashboard | |
Slutresultat | Kommunalt-defineret Dashboard |
Alternativer: | |
1a-2a: Brugeren vælger et eksisterende kommunalt-defineret Dashboard og tilpasser dette. 7a: Brugeren vælger at gemme det pågældende Dashboard uden at publicere det | |
Sluttilstand | |
Bemærkninger: | |
I alternativ 1a vil en Bruger både kunne vælge et Centralt-defineret Dashboard eller et Dashboard Brugeren tidligere har gemt (se alternativ 6a). | |
Krav # 72 Use case UC-09: Opsæt kommunalt-definerede Dashboards | |||
Kategori: | (K) | Type: | Funktionelt |
Beskrivelse: | Løsningen skal opfylde Use case UC-09. | ||
5.11.12 Frigiv nye Widget-leverandører og Widgets til brug i Kommunens Institutioner
For at kommunale Dashboards kan opbygges skal der være adgang til de rette Widgets. Både den funktionalitet Løsningen udstiller og Widgets fra de rette eksterne systemer (eksempelvis Lærings- platform, fraværsregistreringssystem m.v.), vil være tilgængelige til at opbygge Dashboards af.
Krav # 73 Opsæt adgang til ny Widget-leverandør | |||
Kategori: | (K) | Type: | Funktionelt |
Beskrivelse: | Løsningen skal understøtte, at den Kommunale Administrator kan registrere de nødvendige lokale oplysninger nødvendige for at kalde Widget-leverandø- rens Widgets, så den pågældende Widget bliver tilgængelig for Administrato- rerne i Kommunen. Herefter kan Widget tilføjes til et Dashboard, enten af Kommunen eller Institu- tionen (ifm. UC-07 og UC-09). | ||
5.11.13 Administration på den enkelte Institution
I forbindelse med Løsningen er der behov for, for hver Institution, at administrere Stamdata for In- stitutionen og opsætte Dashboards.
5.11.14 Administrer Stamdata og indstillinger for Institutionen
Use case UC-06 | Navn: Administrer Stamdata og indstillinger for Institutionen |
Igangsættende aktør | Institutionens Administrator |
Formål, beskri- velse og af- grænsning | Institutions Administratoren skal kunne inddatere Stamdata om Institutionen i Løsningen til brug for bl.a. Hjemmesiden. Stamdata kan f.eks. være Kontakt- oplysninger samt bestyrelsesmedlemmer og medlemmer af Institutionens Forældreråd jf. bilag 2.1.A Begrebs- og Informationsmodel. Institutionens Administrator skal endvidere kunne opsætte kommunespeci- fikke indstillinger som eksempelvis, hvilke kommunikationskanaler der er åbne, herunder Værger til Pædagogisk personale og Værger til Elever, Vær- ger til Værger, Værger til Elever, Elever til Værger, Elev til Elev samt lukke for en Gruppe. Behovet udspringer af, at der er forskellige kanalstrategier fra Kommune til Kommune. Styring af kommunikationskanaler er endvidere væsentlig i forbin- delse med f. eks. legeaftaler, sociale eller faglige arrangementer, hvor Bru- gere har behov for at kunne se Profiler og Stamdata samt skrive Beskeder til Brugere, der er tilknyttet en anden Klasse eller Stue på Institutionen. Institutions Administrator skal også kunne administrere Grupper og oprette el- ler indlæse eksisterende Grupper af Kontakter og gøre disse synlige for Bru- gere i Institutionen. |
Hændelse | |
Forudsætninger | |
Handlinger | |
Bruger 1. Indtast Stamdata (se bilag 2.1.A Begrebs- og Informationsmodel) 2. Administrer rettigheder for Brugere 3. Administrer kommunikation mellem Brugere 4. Administrer Grupper på Institutionsniveau | |
Slutresultat | Stamdata og indstillinger for Institutionen er indtastet og indstillet |
Alternativer: | |
1a: Brugeren opdaterer Stamdata samt indstillinger for Institutionen, hvorefter Løsningen opdate- rer Stamdata og udstiller de opdaterede Stamdata. | |
Sluttilstand | |
Bemærkninger: | |
Krav # 74 Use case UC-06: Administrer Stamdata og indstillinger for Institutionen | |||
Kategori: | (K) | Type: | Funktionelt |
Beskrivelse: | Løsningen skal opfylde Use case UC-06. | ||
Krav # 75 Spærring af kommunikation | |||
Kategori: | (K) | Type: | Funktionelt |
Beskrivelse: | Løsningen skal understøtte, at Institutions Administratorer kan spærre en Bru- gers adgang til at sende Beskeder til andre Brugere eller at kommentere Op- slag. Det kan f. eks. være nødvendigt at forhindre en Forældre i at skrive Beskeder til en, flere eller en Gruppe af Pædagogisk personale. Det kan ligeledes f. eks. være nødvendigt at spærre en enkelt Værges mulighed for at kommentere på Opslag, hvis de ikke kan respektere en Skoles retningslinjer for kommunika- tion. Hvilke Brugere der skal kunne spærres skal afklares i samarbejde med KOM- BIT i Afklaringsfasen. | ||
5.11.15 Opsæt Institutions-definerede Dashboards
Use case UC-07 | Navn: Opsæt institutions-definerede Dashboards |
Igangsættende aktør | Institutionens Administrator |
Formål, beskri- velse og af- grænsning | I forbindelse med opsætning af Dashboards tager Institutions Administratoren udgangspunkt i de centralt-definerede- eller kommunalt-definerede Dashboards og tilpasser herefter disse. Den Kommunale Administrator forventes at tager udgangspunkt i centralt-de- finerede- eller kommunalt-definerede Dashboards i forbindelse med imple- menteringen af Løsningen og gradvist overgå til at tilpasse Dashboard gemt og publiceret af Institutions Administratoren. |
Hændelse | |
Forudsætninger | |
Handlinger | |
Bruger | |
1. Vælger en af de centralt-definerede- eller kommunalt-definerede Dashboards 2. Indsætter og tilpasser Løsningens brugergrænseflader samt relevante Widgets fra Widget- leverandører 3. Vælg prøvevisning Løsningen 4. Henter Stamdata indtastet i Løsningen (se UC-06, UC-08 og UC-10 og bilag 2.1.A Infor- mationsmodel) 5. Præsenter prøvevisning for Bruger Bruger 6. Publicer Dashboard | |
Slutresultat | Institutions-defineret Dashboard er opsat |
Alternativer: | |
1a-2a: Brugeren vælger et eksisterende Dashboard, redigerer og publicerer ændringer 6a: Brugeren vælger at gemme det pågældende Dashboard uden at publicere det | |
Sluttilstand | |
Bemærkninger: | |
I alternativ 1a bør en Bruger både kunne vælge et kommunalt-defineret Dashboard eller et Dashboard Brugeren tidligere har gemt (se alternativ 6a). | |
Krav # 76 Use case UC-07: Opsæt Dashboards | |||
Kategori: | (K) | Type: | Funktionelt |
Beskrivelse: | Løsningen skal opfylde Use case UC-07. | ||
Krav # 77 Simpel kommunikation (Værger med flere Børn eller Elever) | |||
Kategori: | (K) | Type: | Funktionelt |
Beskrivelse: | Løsningen skal understøtte at Værger med flere Børn eller Elever, herunder også Værger med tvillinger, trillinger og firlinger ikke bliver belemret med mange ens Beskeder, Opslag, Begivenheder eller Notifikationer. Kravet gælder naturligvis ikke såfremt der er tale om Begivenheder som f. eks. Skole-hjem-samtaler, hvor to eller flere Børn eller Elever knyttes til for- skellige Begivenheder. Kravet kan f. eks. løses ved at Værger modtager Beskeder, Opslag, Begiven- heder, men at der kun sendes en enkelt samlet Notifikation. I tillæg hertil kan Løsningen evt. markere flere Beskeder og Opslag som læst når Xxxxxxxx har læst en af flere Beskeder sendt til evt. tvillinger. Leverandøren skal i samarbejde med KOMBIT, i Afklaringsfasen, fastlægge konceptet for Simpel kommunikation. | ||
Kategori: | (K) | Type: | Funktionelt |
Beskrivelse: | Løsningen skal understøtte, at der i forbindelse med UC-01, UC-02, UC-12, UC-13 kan henholdsvis vedhæftes og uploades filer. Filformater kan f. eks. være PDF, doc, docx, pptx, pptm, xlsm, xlsp og ODF. Leverandøren skal i samarbejde med KOMBIT, i Afklaringsfasen, fastlægge det endelige omfang af filformater, der understøttes i Løsningen. |
Krav # 79 Advarsel inden afsendelse | |||
Kategori: | (K) | Type: | Funktionelt |
Beskrivelse: | Løsningen skal understøtte, at en Bruger adviseres, hvis denne forsøger at udsende Opslag, Beskeder eller Begivenheder til et større antal Brugere. | ||
5.12.1 Tilknytning til ny Institution
Eksempel for Skole: hvis en familie flytter til et nyt Skoledistrikt, og vil flytte deres Barn til den Skole der er knyttet til distriktet, har Skolen pligt til at modtage Eleven jf. Folkeskoleloven §36. Værger modtager en indmeldelses blanket fra den modtagende Skole. Når den modtagende Skole modtager denne udfyldt, opretter de Eleven i deres administrative system (se afsnit 4.2). Det admi- nistrative system synkroniserer med UNI-login, således Elevens Institution opdateres. Når Løsnin- gen modtager denne ændring ved import, jf. afsnit 6.2.1, er det vigtigt at Brugerens tilknytning til Institution også ændres i Løsningen.
Når den afgivende Skole modtager en Besked fra UNI-Login om at Eleven er blevet tilknyttet en anden Skole, udmelder den afgivende Skole Eleven i deres administrative system, hvorefter Ele- ven og dennes Værger ikke længere har adgang til Løsningen fra den afgivende Skole.
Eksempel for Dagtilbud: Når et Barn skifter fra Dagtilbud til Skole, gør Dagtilbuddet ikke noget aktivt, det foregår automatisk i Pladsanvisningen, som videresender data til de administrative Sy- stemer (se eksemplet ovenfor) hvorefter Barnet oprettes automatisk. I tilfælde af at Barnet starter i Privatskole, skal Værger manuelt udmelde deres Barn i Pladsanvisningen.
Når et Barn skal skifte fra et Dagtilbud til et andet Dagtilbud, foregår dette også via Pladsanvisnin- gen.
Krav # 80 Tilknytning til Institution | |||
Kategori: | (K) | Type: | Funktionelt |
Beskrivelse: | Løsningen skal understøtte at tilknytning til én Institution kan udskiftes med anden Institution. | ||
Når Xxxxxxx tilknyttes Institutioner, er der behov for at tilknyttede Institutioner kan tilgå data, relate- ret til den tilknyttede Bruger. F.eks. en modtagende Institution der skal benytte data, som er opret- tet af en anden Institution Eksempelvis Noter om Barn/Elev.
Krav # 81 Udveksling af Brugerdata | |||
Kategori: | (K) | Type: | Funktionelt |
Beskrivelse: | Løsningen skal sikre at Værger har givet Samtykke til tilknyttede Institution, før personfølsomme data tilgængeliggøres for den modtagende Institution. Den modtagende Institution skal kunne se/tilgå/modtage data relateret til Barn/Elev: Liste over hvilke Institutionsdata der er tale om, er under afklaring. |
5.12.2 Bestyrelser, Kontaktforældre og forældreråd
Folketinget har vedtaget, at der på alle Skoler i Danmark skal være en Skolebestyrelse jf. Bekendt- gørelse om valg af forældrerepræsentanter til skolebestyrelser i folkeskolen. Skolebestyrelsen be- står af Værger, Medarbejdere og Xxxxxx og der vil på mange Skoler være tilknyttet en Leder som sekretær, der ikke er officielt medlem af bestyrelsen. Sekretæren har på mange Skoler til opgave at indkalde til møder, lave referater og sende information ud til Værger.
I Dagtilbud eksisterer en lignende konstruktion med Dagtilbudsbestyrelser beskrevet i Dagtilbuds- lovens §14-16. I forbindelse med Løsningen er eneste praktiske forskel, at der ikke er Børn som medlemmer i Dagtilbudsbestyrelser.
Der er dog undtagelser fra disse to konstruktioner jf. § 24 a. i Folkeskoleloven kan Kommunalbe- styrelsen beslutte, at der for små Skoler og små Afdelinger eller hvor der er tæt tilknytning til et Dagtilbud skal være fælles Leder og fælles Bestyrelse.
Krav # 82 Skole og dagtilbudsbestyrelser | |||
Kategori: | (K) | Type: | Funktionelt |
Beskrivelse: | Løsningen skal understøtte at repræsentanter i Skole- og Dagtilbudsbestyrel- ser har adgang til at kunne oprette og redigere Dokumenter f. eks. dagsorde- ner og referater. Medlemmer af Skole- og Dagtilbudsbestyrelsen skal endvidere kunne tilgå en liste over Kontaktforældre på Institutionen. Institutions Administratoren kan angive om en Bruger er medlem af Bestyrel- sen og hvilken rolle (Formand, medlem, sekretær) de har i Bestyrelsen jf. UC- 06. | ||
Ud over Bestyrelser findes der i Skoler Kontaktforældre, der ikke er nævnt i Folkeskoleloven og ikke har formelle kompetencer som f. eks. medlemmer af Bestyrelsen. De fleste Skoler i Danmark har dog tradition for at vælge 2-5 kontaktforældre fra hver klasse. Kontaktforældre vil ofte gå for- rest i forbindelse med sociale arrangementer og understøtte Skolebestyrelsens arbejde med input.
Krav # 83 Kontaktforældre
Kategori: | (K) | Type: | Funktionelt |
Beskrivelse: | Løsningen skal understøtte at Kontaktforældre i Skoler har adgang til at kunne oprette og redigere Dokumenter f. eks. dagsordener og referater. Institutions Administratoren kan angive om en Bruger er medlem af Bestyrel- sen og hvilken rolle (Formand, medlem, sekretær) de har i Bestyrelsen jf. UC- 06. | ||
5.12.3 Lokal print
Der er i Løsningen behov for at kunne udskrive/printe indhold i et overskueligt format. Dette gælder Pædagogiske Noter jf. afsnit 5.5, Beskeder jf. afsnit 5.3.4, Opslag jf. afsnit 5.3.1, Kalender jf. 5.6, Medier jf. afsnit Krav # 43, Kontakter (xxxxxx) jf. afsnit 5.4.2.
Det kunne eksempelvis være Forældre, der ønsker at printe et Skema for deres Barn/Elev, eller Pædagogisk personale der ønsker at printe et Billede.
Krav # 84 Udskrivning | |||
Kategori: | (K) | Type: | Funktionelt |
Beskrivelse: | Løsningen skal understøtte lokal print af alle oplysninger, der vises i bruger- grænsefladen, samt af alle af følgende informationer: • Noter • Beskeder • Opslag • Kalender • Medier • Kontakter Systemet skal tilpasse ovenstående til et printvenligt format. | ||
5.12.4 Filtrering og sortering
Løsningen skal automatisk kunne filtrere og sortere på både Stamdata og Metadata, og f. eks. styre hvornår indhold skal eller ikke skal præsenteres for en Bruger jf. afsnit 6.5. I andre tilfælde vil det være Brugeren selv, der kan vælge at filtrere eller sortere indhold efter specifikke parametre.
Krav # 85 Filtrering og sortering | |||
Kategori: | (K) | Type: | Funktionelt |
Beskrivelse: | Løsningen skal understøtte filtrering og sortering af indhold, efter flere para- metre. Parametrene kan både være Stamdata og Metadata. Der skal være mulighed for at sortere og filtrere indholdet i Noter jf. afsnit 5.4.3, Beskeder jf. afsnit 0, Opslag jf. 5.3.1, Søgeresultater jf. 5.10, Kalender jf. 0, Medier jf. afsnit Krav # 43 og eventuelle steder hvor det kunne give værdi. F.eks. har en Bruger behov for at kunne sortere sine Beskeder efter modtaget dato, så først eller senest modtaget Beskeder fremgår først eller sidst. Bruge- ren har også behov for at kunne filtrere Beskeder efter f. eks. Afsender, så der kun fremgår Beskeder fra den indtastede Afsender. |
5.12.5 Tekstbehandler
Der er i Løsningen behov for en Tekstbehandler (text editor) til oprettelse og redigering af tekster.
Kategori: | (K) | Type: | Funktionelt |
Beskrivelse: | Løsningen skal understøtte en Tekstbehandler, der er tilgængelig de steder i Løsningen hvor Brugeren har behov for at behandle tekst. Herunder Opslag jf. afsnit 5.3.1, Beskeder jf. 5.3.3, Dokumenter jf. 5.5.1 og Kalender jf. afsnit 5.6.1. Tekstbehandleren skal give Brugeren mulighed for at: • Indstille størrelse på tekst, så der kan skrives med forskellig størrelse tekst • Skrive fed, kursiv, understreget tekst og gennemstreget tekst • Skrive tekst i forskellige farver • Vælge forskellige baggrundsfarver (så tekst kan markeres) • Justere indholds placering, venstrejusteret (Standard), centreret og højre justeret • Lave nummeret liste og punktliste • Lave Mere-eller mindre -Indrykning (ligesom Tab-funktionen i Word) • Benytte en citat funktion, der gør det muligt at angive udvalgt tekst som værende en citation. • Indsætte Humørikoner • Indsæt tabeller | ||
Når Xxxxxxx arbejder i en Tekstbehandler, er der behov for at Løsningen løbende gemmer Bruge- rens arbejde, således der kan arbejdes videre på det, på et senere tidspunkt. Dette sikrer også at arbejde ikke går tabt ved pludselige nedbrud.
Krav # 87 Kladder | |||
Kategori: | (K) | Type: | Funktionelt |
Beskrivelse: | Løsningen skal understøtte en kladdefunktion, der løbende gemmer Bruge- rens arbejde i Tekstbehandleren, således det kan genåbnes på et senere tids- punkt. Xxxxxxxx skal kunne tilgå sine kladder for at arbejde videre i dem eller slette dem. Dette gælder ikke Kalender indkaldelser. |
5.12.6 Brugsstatistik
I forbindelse med Løsningen har flere forskellige Brugere behov for at kunne få indblik i andre Bru- geres adfærd i Løsningen men også på Hjemmesider for Institutioner. Behovet er ikke på individ- niveau, men grupperet. En Leder har f. eks. behov for, at kunne danne sig et overblik over brugen af Løsningen hos Medarbejdere i en Institution. En Leder har ligeledes behov for at et overblik over Værgers brug, som herefter kan kommunikeres til Pædagogisk personale, der så kan tilrettelægge deres kommunikation mod Værger herefter. I forbindelse med Institutionens Hjemmeside, har Medarbejdere i Forvaltningen f. eks. behov for at forstå, hvordan siden bruges og om der er infor- mation på siden der aldrig læses.
Medarbejdere i Forvaltningen i Kommunen og den Kommunale Administrator har også behov for at forstå Brugeres brug af Løsningen, så de kan tilpasse de Kommunale Dashboard skabeloner jf.
UC-09. Behovet kan dækkes af en Brugsstatistik, der f. eks. viser en oversigt over, hvornår Bru- gerne benytter Løsningen, hvilke dele af Løsningen de benytter mest og om der er Brugere, der slet ikke benytter Løsningen samt antal kommenterede Opslag mv.
Den Centrale Administrator har, ligesom den Kommunale samt Institutions Administratoren, behov for at kunne tilgå Brugsstatistik. Den Centrale Administrator kan bl.a. benytte Brugsstatistikken til at foretage ændringer i Standard-dashboards jf. UC-11 for at sikre den bedst mulige oplevelse for Brugerne. Herudover vil Brugsstatistikken kunne benyttes ifm. løbende opdateringer af bruger- grænseflade for at sikre en så brugervenlig Løsning som muligt i hele kontraktens løbetid.
Krav # 88 Brugsstatistik | |||
Kategori: | (K) | Type: | Funktionelt |
Beskrivelse: | Løsningen skal understøtte at Ledere, Forvaltning og Administrativ Medarbej- dere samt Administratorer kan tilgå Brugsstatistik. • En Leder og en Administrativ Medarbejder samt Institutions Admini- stratoren skal kunne tilgå Brugsstatistik for den Institution Lederen er leder for og den Administrative Medarbejder er tilknyttet • Forvaltningen og den Kommunale Administrator skal kunne tilgå Brugsstatistik for alle Institutioner i Kommunen opdelt på Institutionsty- per jf. bilag 2.1.A Informationsmodel samt en Brugsstatistik genereret for alle Institutioner i Kommunen. • Den Centrale Administrator skal kunne tilgå Brugsstatistik for alle Insti- tutioner samt for hver enkelt Institution. I det tilfælde, hvor der er tale om Afdelinger eller Klynger jf. bilag 2.1.A Infor- mationsmodel skal Løsningen understøtte, at Lederen, den Administrative Medarbejder og Forvaltningen kan få vist Brugsstatistik for den enkelte Afde- ling og/eller Klynge. Leverandøren skal i samarbejde med KOMBIT i Afklaringsfasen fastlægge mulighederne for Brugsstatistik. |
5.12.7 Håndtering af aktindsigt
I henhold til forvaltningslovens § 8, kan den, hvis personlige forhold er omtalt i et dokument, med de undtagelser, der er nævnt i §§ 19-29 og § 35, forlange at blive gjort bekendt med oplysningerne herom.
I forbindelse med Løsningen betyder det, at retten til aktindsigt er gældende, hvis en Værge øn- sker aktindsigt i, hvilke personlige forhold, der er omtalt i dokumenter om et Barn eller en Elev.
Aktindsigten omfatter alle oplysninger. Det vil sige at alle Dokumenter, Beskeder og Medier, der vedrører Barnet eller Eleven er omfattet.
Da retten til aktindsigt i øvrigt kan begrænses, jf. lovens § 15, vil det være op til den enkelte Medar- bejder at udvælge relevante dokumenter og andre oplysninger og Løsningen vil derfor kun skulle understøtte Medarbejderens udskrivning, samt registrering af relevante datoer på de relevante Do- kumenter, Beskeder og Medier.
Krav # 89 Registrering af dato for imødekommelse af aktindsigt | |||
Kategori: | (K) | Type: | Funktionelt |
Beskrivelse: | Løsningen skal sørge for, at den behandlende Medarbejder kan registrere da- toen for effektuering af aktindsigten på Dokumenter, Billeder og Medier. | ||
Krav # 90 Håndtering af aktindsigt | |||
Kategori: | (K) | Type: | Funktionelt |
Beskrivelse: | Løsningen skal understøtte Medarbejderen i klargøring af Dokumenter, Be- skeder og Medier til aktindsigt. Leverandøren skal i dialog med KOMBIT i Analyse og designfasen fastlægge endeligt, hvordan klargøring til aktindsigt sker i Løsningen. |
6 Ikke-funktionelle krav
For at Løsningen kan levere den service, Brugeren har behov for, er det nødvendigt at stille en række forskellige tekniske krav. Denne type krav kaldes ikke-funktionelle, idet de ikke direkte rela- terer sig til Brugerens forretningsmæssige behov, men derimod beskæftiger sig med Løsningens servicemæssige kvalitet. De ikke-funktionelle krav er således til stede for at understøtte de funktio- nelle krav i kapitel 0 og koblingen hertil sker gennem Løsningens arkitektur som beskrives i afsnit 6.1.
Afsnit 6.2 indeholder Løsningens integrationer. Her beskrives de typer af integrationer som anven- des i Løsningen, samt de forskellige aktører som der integreres med fra Løsningen.
Afsnit 6.3 indeholder krav til Brugervenlighed og brugerinddragelse i projektet. Her beskrives bl.a. hvordan Løsningen skal designes, så brugerne oplever Løsningen som et godt værktøj i hverda- gen.
Afsnit 6.4 indeholder Lov krav til Løsningen.
Afsnit 6.5 indeholder sikkerheds krav til Løsningen
Afsnit 6.1.1 omhandler hvordan Løsningen hænger sammen med den Fælleskommunale Ramme- arkitektur.
I afsnit 6.1.2 gennemgås målarkitekturen for Løsningen. I underafsnit hertil beskrives hele koncep- tet med Dashboard og Widget som byggeklodser i Løsningen.
I afsnit 6.1.3 beskrives en række tværgående egenskaber for Løsningen i forhold til Den fælles- kommunale infrastruktur. Afsnit 6.1.4 beskriver hvordan området for Løsningen forventes af foran- dre sig i de kommende år, og hvordan Løsningen skal kunne håndtere disse ændringer
Tekniske krav til Løsningen er samlet i afsnit 6.1.5. Her findes generelle krav, Tekniske krav om- kring Brugernes udstyr, samt en liste over de protokoller og standarder der forventes at løsningen skal overholde.
6.1.1 Offentlige strategier og generelle arkitekturprincipper
Som central spiller på det kommunale område tager KOMBIT til enhver tid udgangspunkt i de fæl- les offentligt vedtagne initiativer, principper og strategier.
Disse vil være retningsgivende og beskriver kontekst og rammebetingelser for den konkrete Løs- ning. I denne sammenhæng er den af Kommunernes It-Arkitekturråd godkendte fælleskommunale rammearkitektur relevant.
Krav # 91 Den Fælleskommunale Rammearkitektur skal danne baggrund for udvikling af løsningen | |||
Kategori: | (K) | Type: | Ikke funktionelt |
Beskrivelse: | Leverandøren skal designe og udvikle Løsningen under hensyntagen til Den Fælleskommunale Rammearkitektur, jf. mål og principper angivet på | ||
6.1.2 Målarkitektur
Herunder ses Løsningens Målarkitektur, der beskriver den generelle opbygning af Løsningen, Løs- ningens kapabiliteter og data, samt de parter der integreres til, både igennem integrationer og igennem visning af Widgets fra de eksterne systemer som Løsningen skal integrere med.
Løsningen
Database
Stamdata Personfølsomme dokumenter Billeder/lyd/video Øvrig data
Brugergrænseflade – Dashboards med Widgets
App
Web
Moduler i Løsningen
Komme/gå
Søgning
Galleri
Opslag
Administration
Infotavle
Notifikationer
Kontakter
Beskeder
Samtykke
Hjemmeside
Sikker fildeling
Kalender
Profil
Udstilling af Widgets
Bibliotekssystemet
Integrations- platformen
Kommunal fildeling
Fraværsløsninger
Læringsplatforme
Sikkerhed
NemLogin/NemID
Uni-Login
Dataintegration
Kommunernes adm. systemer
STILs Infotjeneste
LIS systemer f.eks.
FLIS
Skemaplanlægning
Figur 7: Logisk arkitektur for Løsningen (målarkitektur)
Figuren viser en generel opdeling af Løsningen i logiske forretningskomponenter og nederst er in- tegrationerne angivet. Forretningskomponenter er logiske grupperinger af funktionalitet, som mat- cher de, i kapitel 0, beskrevne funktionelle krav til Løsningen.
Øverste på tegningen viser den lilla figur Løsningen som udbydes i dette udbud. Løsningen kan tilgås af brugerne enten gennem Web eller App. Når Brugerne derved tilgår Løsningen bliver Bru- geren mødt af et Dashboard. På Dashboard ser Brugeren Løsningens interne moduler og de eks- terne Widgets som bliver udstillet gennem Dashboard.
Løsningens interne moduler udstiller for brugeren de kapabilliteter som er vist på figuren. Informati- oner til brug for disse kapabiliteter håndteres af Løsningens database, hvor der gemmes Beskeder, filer, Billeder, Video, Opslag, Komme/gå oplysninger osv.
Under den blå figur vises integrationerne. Fra dataintegrationerne hentes data ind i Løsningens da- tabase, hvorfra de kan anvendes i Løsningens interne moduler.
Widget integrationer derimod hverken modtager eller sender data til Løsningen, men udstiller egne Brugergrænseflader i et stykke af Løsningens brugergrænseflader.
Sidste del af Figur 7 viser Sikkerhedsløsningen, hvor UNI-login sikrer at Brugeren autentificeres korrekt, inden der bliver åbnet for adgang til Løsningen.
Det bemærkes at der i Kapitel 7 Optioner, gives mulighed for at bestille yderligere funktionalitet til Løsningen, som ikke er medtaget i målarkitekturen, f. eks. Kursus og Spørgeskema.
6.1.2.1 Dashboards
Løsningens Brugere har behov for nemt at kunne danne sig et overblik over de vigtigste informatio- ner for dem, som eksempelvis;
• Forælderen der skal overskue Beskeder, Opslag og Kalender for sine Børns kommende skoledage
• Pædagogen der ønsker at overskue de seneste Beskeder og Opslag, samt sin Kalender
• Eleven der på en nem og overskuelig måde kan se de seneste Beskeder og Opslag, samt en oversigt over dagens aktiviteter (skema)
Løsningen skal tilbyde hver Bruger (Pædagogisk personale, Værge, Leder, Elev m.v.) et Dashboard tilrettet netop dennes behov. Dashboardet indretter sig efter skærmstørrelse, og udgi- ves både som html5 til brug af browsere samt som Apps på de primære mobile platforme.
Krav # 92 Informationer om flere Børn eller Elever aggregeres i Dashboard | |||
Kategori: | (K) | Type: | Ikke funktionelt |
Beskrivelse: | Løsningen skal understøtte at en Værges Dashboard viser Beskeder, Opslag, Kalender m.v. for alle Børn og Elever tilknyttet Værgen. Det er en essentiel del af ambitionen for Løsningen at en Værge har en sam- let indgang til information om sine Børn, uanset at de går i forskellige Instituti- oner der kan ligge i forskellige kommuner. | ||
Brugerens behov for overblik, der realiseres gennem Dashboard baseret på hvilken Brugeraktør Brugeren er, er desuden at denne ikke oplever forskel på Dashboardet uanset om man tilgår Løs- ningen via Browserløsning eller App. Dashboard kan håndteres af både Leverandøren, men også i selve Løsningen af eksempelvis en Kommunal Administrator eller en Administrator i en Institution jf. UC-06, UC-09 og UC-11.
Opdelingen er nødvendig da eksterne systemer (Læringsplatform, fildelingsløsning, fraværsregi- streringssystem m.v.) vil være forskellige fra Kommune til Kommune og mellem Skoler og Dagtil- bud. Herunder er vist hvordan Løsningens moduler og Widgets fra eksterne systemer tilbydes for Løsningens Brugere.
Figur 8: Overblik over hvordan Widgets tilbydes Brugeren
I figuren ses Brugeren der bruger enten smartphone, tablet eller computer til at tilgå sit Dashboard. Dette sker enten ved at bruge en App på en smartphone eller tablet, eller ved at bruge Løsningens Browserløsning fra en af de tre enheder. Brugerens Dashboard udgives til Browserløsningen som html5, og som Apps til iOS og Android, og samler de relevante moduler fra Løsningen samt Widgets fra eksterne systemer.
Herunder er angivet hvert Dashboard med eksempler på hvilken af Løsningens funktionalitet samt Widgets fra Widget-leverandører Dashboardet kunne indeholde;
- Pædagogisk personale (Skole)Dashboard indeholder
o Løsningen: Oversigt over Beskeder
o Løsningen: Kalender (pågældende uge Løsningen)
o Løsningen: Liste af Opslag
o Widgets: 1-3 Widgets fra Læringsplatform
o Widgets: Widget fra fraværsregistreringsløsning til at registrere Elevers Fravær
o Løsningen: Menu med adgang til at åbne; Lokal fildelingsløsning, andre eksterne Widgets
- Pædagogisk personale (Dagtilbud)Dashboard indeholder
o Løsningen: Oversigt over Beskeder
o Løsningen: Kalender (pågældende uge) – evt. standardsorteret på Stue eller anden relevant gruppering
o Løsningen: Liste af Opslag
o Løsningen: Oversigt over Galleri
a. Løsningen: Widget fra kommunens Fildelingsløsning
o Menu med adgang til at åbne; Lokal fildelingsløsning, andre eksterne Widgets
- Mellemskole/udskolingselevens dashboard indeholder
o Løsningen: Oversigt over Beskeder
o Løsningen: Kalender (pågældende uge)
o Løsningen: Liste af Opslag
o Widgets: 1-3 Widgets fra Læringsplatform
o Løsningen: Menu med adgang til at åbne; Lokal fildelingsløsning, andre eksterne Widgets
- Indskolings/mellemskoleelevens Dashboard indeholder
o Løsningen: Oversigt over dagen (Kalender med simpel visning for kun en dag af gangen)
o Widgets fra Læringsplatform (eksempelvis oversigt over lektier, Læringsforløb eller links til digitale læringsmidler)
- Værgers Dashboard indeholder
o Løsningen: Oversigt over Beskeder (for alle Børn og Elever tilknyttet Værgen ens Børn på tværs af Institutioner)
o Løsningen: Kalender (pågældende uge) (for alle ens Børn på tværs af Institutioner)
o Løsningen: Liste af Opslag (for alle ens Børn på tværs af Institutioner)
o Widgets: 1-2 Widgets fra Læringsplatform for hvert Barn
- Lederens Dashboard indeholder
o Løsningen: Oversigt over Beskeder
o Løsningen: Kalender (pågældende uge)
o Løsningen: Liste af Opslag
o Løsningen: Menu med adgang til at åbne; Lokal fildelingsløsning, andre eksterne Widgets, administrativ funktionalitet
- Øvrige Brugeres Dashboard (generisk Dashboard) indeholder
o Løsningen: Oversigt over Beskeder
o Løsningen: Kalender (pågældende uge)
o Løsningen: Liste af Opslag
Kategori: | (K) | Type: | Ikke funktionelt |
Beskrivelse: | Løsningen skal understøtte Dashboards som listet i afsnit 6.1.2.1. Dashboards indeholder for alle Brugere en menu der giver adgang til Løsnin- gens funktionalitet, justeret ift. den pågældende Brugers rettigheder. Leverandøren skal i samarbejde med KOMBIT i Afklaringsfasen fastlægge hvilke funktionaliteter og Widgets, der forventes tilgængelige for de enkelte Dashboards. | ||
Der er desuden behov for Dashboards, hvori Xxxxxxx tilknyttet en specifik Gruppe jf. afsnit 5.11.1 kan se f. eks. Opslag rettet mod Gruppen, Begivenheder ’tilknyttet’ Gruppen samt have adgang til fælles Dokumenter fra kommunens Fildelingsløsning som Widget. Eksempler på Grupper der har behov for Dashboards er;
- Klasser: Statiske Grupper for en hel klasse, eller Forældre til klassens Elever
- Projektgrupper: Elever arbejder i Grupper sammen om et større projekt. De bruger Grup- pens Dashboard til at overskue Kalender, diskutere Opslag, få adgang til filer i kommunens Fildelingsløsning, samt registrere fremdrift i Læringsplatformen.
- Faglige Grupper: Geografilærerne i Rødovre Kommune har oprettet en Gruppe hvor de øn- sker at videndele. I Dashboardet kan de se fælles arrangementer oprettet som en Begiven- heder i Kalenderen, diskutere Opslag, få adgang til fælles dokumenter og se hinandens Læringsforløb5
- Stuer i Dagtilbud: Pædagogisk personale tilknyttet en bestemt stue i et Dagtilbud bruger gruppe-Dashboard til at overskue fælles Opslag samt stuens Kalender
Krav # 94 Dashboards for Grupper | |||
Kategori: | (K) | Type: | Ikke funktionelt |
Beskrivelse: | Løsningen skal understøtte at Brugere der er tilknyttet en Gruppe kan tilgå et Dashboard for Gruppen Leverandøren skal i samarbejde med KOMBIT i Afklaringsfasen fastlægge hvilke Dashboards, der forventes tilgængelige for Grupper og hvilke Widgets, der skal udstilles på de enkelte Dashboards for Grupper. | ||
6.1.2.2 Løsningens funktionalitet og Widgets
Løsningen vil i Dashboards udstille både den funktionalitet som Løsningen selv tilbyder (Løsnin- gens moduler) samt de Widgets kommunen eller Institutionen anvender fra deres leverandører (Widget-leverandører)
I de følgende afsnit er Løsningens Moduler og Widgets beskrevet. Det er vigtigt for Løsningen at Widgets og Interne Widgets præsentere sig ens i Brugerens brugergrænseflade, både når de præ- senteres i Web og App.
Krav # 95 Layout og responsivitet ifht. Widgets | |||
Kategori: | (K) | Type: | Ikke funktionelt |
Beskrivelse: | Løsningen skal understøtte, at Løsningens moduler og Widgets opfører sig ens når det kommer til layout og responsivitet (i det omfang Widgets er bygget efter Løsningens krav), således at Widgets kan bruges sammen uanset hvil- ken Enhed og i hvilken kontekst de skal vises (se afsnit 6.1.5.3). Altså skal Brugeren ikke opleve at Løsningens moduler og Widgets indretter sig forskel- ligt når Brugeren eksempelvis ændrer tablet fra portræt til landskabs-format. | ||
Krav # 96 Indhold i Løsningens moduler og i Widget indretter sig efter Xxxxxxxxx ret- tigheder | |||
Kategori: | (K) | Type: | Ikke funktionelt |
5 Bemærk at disse eksempler afhænger af hvilke muligheder der er for at integrere Widgets fra fildelingsløsninger og Læringsplatforme
Beskrivelse: | En Widget eller visning af Løsningens moduler vil indrette sig efter hvilke ret- tigheder den der ser siden har, evt. i relation til en anden Bruger som Widget eller Løsningens moduler omhandler. Eksempelvis vil visningen ”Stamdata” om en Elev se forskellig ud alt efter hvem der kigger på siden; - En lærer der underviser Eleven ser alle Stamdata om Barnet, herun- der også Pædagogiske Noter og Dokumenter fra Sikker Fildeling - En Forælder til en Elev kigger på en anden Elev fra klassen, og ser kun Elevens navn, samt Kontaktoplysninger på Elevens Forældre Visningen ”Stamdata” viser altså kun de informationer Brugeren har ret til at se, og skal sørge for at det sker på en brugervenlig måde. Forælderen i oven- stående eksempel skal ikke præsenteres for en tom boks fra Sikker Xxxxxxxxx, når denne ikke har ret til at se disse informationer om et andet Barn. I det til- fælde vil Siden blot indeholde de relevante informationer. |
6.1.2.2.1 Løsningens moduler
Al funktionalitet i Løsningens moduler (jf. afsnit 0 og Målarkitekturen afsnit 6.1.2), som slutbrugere skal anvende, samt funktionalitet til at understøtte Brugerens navigation rundt i Løsningen, udstil- les som brugergrænseflader til brug i både Browserløsning og App. De udstillede moduler opfører sig layoutmæssigt på samme måde som Widgets, med undtagelse af administrationsfunktionalitet (UC-06 til UC-11), der kun bør understøttes af Browserløsning og ikke vil have samme krav til at kunne anvendes bredt på mange enheder.
Ud over at udstille brugerrettet funktionalitet skal Løsningens moduler også understøtte at udstille Løsningens informationer på en Institutions Infotavler (se afsnit 0) og Hjemmeside (se afsnit 0).
Et modul i løsningen kan udstilles som flere visninger, eksempelvis at Besked-modulet udstilles i flere visninger;
• Oversigt over Beskeder
• Opret ny Besked
• Søg i Beskeder
Herunder angives eksempler på brugergrænseflader der viser Løsningens moduler.
Modul (visning) | Beskrivelse |
Ugekalender | Ugekalenderen viser Brugeren en hel uge, med udgangspunkt i Brugeren (eller brugerens Børn) og giver mulighed for at se andre kalendere, uger m.v. |
Dagskalender | Dagskalenderen viser Brugeraktøren én dag, med udgangspunkt i Brugeraktøren (eller Brugerens Børn). |
Gruppekalender | Viser en Gruppes Kalender for dagen, eksempelvis en ugeplan for en SFO. |
Beskeder | Viser oversigt over Beskeder Brugeren har modtaget |
Sikker Xxxxxxxxx | En Bruger kan her se alle personfølsomme Dokumenter Brugeren er tilknyttet, og åbne, kommentere og gemme. |
Opslag | Viser de seneste/vigtigste Opslag som er relevante for Brugeren |
Galleri | Viser Brugeren de Mediefiler (Billeder, Video, Lyd) der er relevant for Brugeren |
Tag Billede til Gal- leri | Giver Brugeren mulighed for gennem Løsningen at tage et Billede, der automatisk gemmes i Løsningen |
Skriv Opslag | Giver bruger mulighed for at skrive et Opslag, herunder at angive relevante modtagere samt tilknytte Billeder, filer, links m.v. |
Tag og upload billede | Giver bruger mulighed for at tage et billede (via smartphone eller tablet) som automatisk lægges op på Løsningen Brugeren har mu- lighed for at lave et Opslag ifm billedet, Tagge hvem der er på det mm. |
Arranger møde | Indeholder al funktionalitet til at planlægge møder, skolehjem-sam- taler, Møderækker/kurser m.v. |
Administrer Profil | Giver Brugeren mulighed for at administrere sine (og sine Børns) Stamdata, Tilladelser m.v. |
Afhentning | Forældre kan se og redigere hvornår deres Barn hentes og af hvem for en uge ad gangen. |
Skolens stam- oplysninger | Viser Institutionens stamdata (adresse, Kontakter etc) til brug på Institutionens Hjemmeside. |
Skolens Kalender | Viser Institutionens overordnede Kalender, som den skal vises på Skolens Hjemmeside. |
Ulæste emner | Viser Brugeren at denne har ulæste Beskeder, Opslag og Begiven- heder. |
6.1.2.2.2 Widgets
Forståelsen af Widgets følger W3C6 definition. En Widget er kode der er lagt på serveren (Leveran- døren af Widget), og fra klienten (Løsningen) henviser man til leverandørens kode. Når en Bruger åbner sit Dashboard, indlæser Løsningen sine egne moduler fra Løsningen selv, mens Widgets indlæses direkte fra Widget-leverandørens server.
Med Widgets kan Løsningen ikke kontrollere det indholdet der leveres. Dette vurderes dog ikke som et problem, da leverandørerne af Xxxxxxx er parter der er kontraktligt bundet til Kommu- nen/Institutionen jf. bilag 2.1.J.
For at Widget-leverandørernes Widgets skal kunne fungere tilfredsstillende er det essentielt at der er et fælles og standardiseret udvekslingsformat som både Løsningen og Widgets understøtter.
Krav # 97 API der sikrer kompatibilitet mellem Løsningen og Widgets | |||
Kategori: | (K) | Type: | Ikke funktionelt |
Beskrivelse: | Løsningen skal kunne understøtte Widget-leverandørers Widgets, hvilket kræ- ver at; Leverandøren af Løsningen skal beskrive et Widget API, som udviklere af Widgets kan anvende under deres programmering af Widgets til Løsnin- gen. Widget APIet skal indeholde funktionalitet, så Brugerens id og evt. dele af Brugerens Profil kan videregives til Widgeten. F.eks. skal der ved load af Widget fra Læringsplatform videregives så mange informationer at Lærings- platform kan vise samme informationer, som hvis Brugeren var logget direkte på Læringsplatform (uden om Løsningen og Widgets). | ||
Krav # 98 Standarder for Widgets | |||
Kategori: | (K) | Type: | Ikke funktionelt |
6 xxxxx://xxx.x0.xxx/XX/Xxxxxxx-xxxx/
Beskrivelse: | Løsningen skal understøtte relevante standarder for Widgets. Eksempel på standarder kan være: JavaScript (ECMAScript), HTML CSS DOM DOM Events XML XMLHttpRequest SVG |
Herunder er beskrevet en række eksempler på Widgets, der forventes udstillet i Løsningen.
Widget | Beskrivelse | Type |
Læringsforløb | Widget giver en oversigt over aktive Læringsforløb en Elev er i gang med p.t. Ved at klikke på et Læ- ringsforløb i Widget, flyttes Brugeren over i Læ- ringsplatformen. | Widget fra Læ- ringsplatform |
Status på Lærings- forløb | Læreren kan i Widget vælge et givet Læringsforløb og se status (eksempelvis ”afleveret”) for hver Elev der er i gang med det | Widget fra Læ- ringsplatform |
Elevens progression | Widget viser et øjebliksbillede af hvor Eleven er ift. alle igangværende Læringsforløb | Widget fra Læ- ringsplatform |
Elevens portfolio | For de Læringsplatforme der indeholder de Doku- menter/filer Eleverne afleverer, skal der udstilles en Widget der viser en given Elevs produkter. | Widget fra Læ- ringsplatform |
Brugerens Doku- menter | Widget der viser Brugerens Dokumenter fra Kom- munens/Institutionens Fildelingsløsning (eksempel- vis OneDrive eller Google Drive) | Widget fra Filde- lingsløsning |
Søgning i Biblioteks- system | Widget der giver Brugeren mulighed for at søge ef- ter materialer i Skolens bibliotek til brug i undervis- ningen. | Widget fra biblio- tekssystem |
Registrer Tilstede- værelse | Læreren kan med denne Widget få et overblik over alle Elever der burde være tilstede en given dag el- ler til en given lektion, og markere Tilstedeværelse for hver enkelt | Widget fra fraværs- registreringssystem |
6.1.3 Tværgående egenskaber for Løsningen
Kommunerne og KOMBIT har på baggrund af den Fælleskommunale Rammearkitektur etableret en række fælleskommunale forretningsservices og komponenter, f. eks. Serviceplatformen og Støttesystemerne.
Da en lang række forretningsservices på Løsningens område allerede er etableret og er en inte- greret del af løsningens omgivelser, f. eks. UNI-login, så anvendes de fælleskommunale forret- ningsservices kun i forbindelse med Løsningen, hvor det giver en fordel.
Det forventes at de fælles kommunale forretningsservices og komponenter med fordel kan anven- des på disse områder:
1) Serviceplatformen kan anvendes til udveksling af data mellem forskellige aktører, f. eks. Løsningen og Kommunernes LIS-løsninger
2) Støttesystemet Adgangsstyring for Brugere anvendes af Medarbejdere, som er ansat i Kommunernes Forvaltning, men i nogle kommuner bruger også Institutionernes ledelse, adm. personale og flere andre Grupper Støttesystemet Adgangsstyring for Brugere. For at kunne give disse Brugere en oplevelse af ”single sign-on”, skal der være en sammenhæng mellem Løsningens sikkerhedsløsning og Støttesystemet Adgangsstyring for Brugere – Det er under afdækning om/og hvordan detteproblem kan løses
3) Støttesystemet Klassifikation indeholder klassifikation der beskriver følsomhed af f. eks. Dokumenter. Det er under afklaring om denne klassifikation med fordel kan anvendes af Løsningen
4) Institutionsregisteret indeholder Stamdata om alle landets Institutioner. Det er under afdæk- ning om disse Stamdata bedst kan hentes af Løsningen i Institutionsregisteret eller i Støtte- systemet Organisation
Krav # 99 Brug af fælles kommunale forretningsservices | |||
Kategori: | (K) | Type: | Ikke funktionelt |
Beskrivelse: | Løsningen skal anvende Serviceplatformen og øvrige relevante fælleskommu- nale forretningsservices | ||
6.1.4 Fremtidig tilpasning af Løsningen
Skole- og Dagtilbudsområdet er et område hvor der sker en konstant udvikling. Udvikling sker både inden for læringsmetoder, opfølgning på læring, trivsel og mange andre områder. Hertil har området desuden en stor politisk bevågenhed, hvilket også medfører udvikling af området. Ofte vil der ske en it-understøttelse af disse ændringer, ligesom nye tekniske muligheder også vil medføre ændringer. Ofte vil disse ændringer medføre et behov for tilpasning af funktionalitet eller tilføjelse af ny funktionalitet i Løsningen. Der er derfor behov for at Løsningen teknisk er opbygget så en høj grad af ændringsparathed er til stede.
Det er vitalt, at Løsningens arkitektur understøtter denne ændringsparathed, så det bliver nemt for Løsningen at understøtte:
• Nye former for kommunikation (evt. afløser for e-mail, SMS osv.)
• Nye standarder på Web-området
• Nye formater (f. eks. inden for tekst og video)
• Nye tiltag på området (f. eks. på baggrund af politiske beslutninger)
• Nye Widget-typer, der f. eks. kan introducere ny funktionalitet for Brugeren
• Nye krav på sikkerhedsområdet
Denne liste er langt fra udtømmende, men er medtaget for at give Leverandøren et indblik i de om- råder, hvor det forventes at løsningen vil ændres.
Det forventes at ovenstående ændringsparathed nemmest kan tilvejebringes ved at anvende stan- dardsystemer og -værktøjer. Leverandøren skal vælge systemer og værktøjer hvor der må forven- tes hurtig (eller tidlig) support af nye features, nye formater osv. ved hjælp af patches el. lign.
Krav # 100 Løsningen skal baseres på Standardsystemer | |||
Kategori: | (K) | Type: | Ikke funktionelt |
Beskrivelse: | Leverandøren skal vælge standardsystemer og -værktøjer til at udgøre ker- nen i løsningen, så ændringsparathed tilvejebringes i den samlede Løsnin- gen. | ||
Da det forventes at Løsningen skal være i drift i en årrække, vil flere af de komponenter som Løs- ningen bygges af potentielt nå ”end-of-life” inden Løsningen udfases. Her skal det være muligt for Løsningen at omlægge disse komponenter uden større gener for Brugerne. Dette er kravsat i bilag 7.
Krav # 101 Løsningen skal være modificerbar | |||
Kategori: | (K) | Type: | Ikke funktionelt |
Beskrivelse: | Løsningens arkitektur skal være opbygget, så ændringsparathed understøttes fleksibelt og omkostningseffektivt. Det gøres f. eks. ved at Løsningen designes og opbygges modulært, så det bliver muligt at udskifte enkelte moduler, f. eks. ved end of support for et mo- dul | ||
6.1.5 Tekniske krav til Løsningen
Dette afsnit beskriver de krav der sættes til Løsningen af mere teknisk karakter. I afsnit 6.1.5.1 be- skrives de mere krav til løsningen, i afsnit 6.1.5.2 beskrives krav til den centrale del af løsningen. Afsnit 6.1.5.3 indeholder krav som stilles til Løsningen, på baggrund af de enheder som Løsningen skal kunne tilgås fra. Afsnit 6.1.5.4 indeholder en liste over protokoller og standarder som Løsnin- gen skal supportere.
6.1.5.1 Generelle krav til Løsningen
Leverandørens samlede leverance består bl.a. af disse miljøer som skal stilles tilrådighed under ikke blot design og udviklingsfasen, men også under forvaltningsfasen:
• Produktionsmiljø
• Præprodmiljø
• Eksternt testmiljø
• Internt testmiljø
• Sandkassemiljø
Produktionsmiljøet vil også skulle dække nogle uddannelsesopgaver, og derfor etableres der ikke et egentligt Uddannelsesmiljø. Produktionsmiljøet skal indeholde en fiktiv Kommune til uddannel- ses formål. Denne fiktive Kommune anvendes af Leverandøren til uddannelse i forbindelse med Implementeringen, se også bilag 12 og bilag 13.
Det forventes tilsvarende at den enkelte Kommune etablerer to fiktive Institutioner til uddannelses og testbrug. Det er tænkt som en fiktiv Skole og en fiktiv daginstitution.
Tilsvarende er det under afdækning om typiske uddannelsesinstitutioner for Medarbejder til områ- dets Institutioner også skal tildeles fiktive Institutioner.
Der etableres også et sandkasse miljø. Dette miljø har kun det formål at Widget leverandørerne kan anvende miljøet til test af Widget under udvikling. Alt andet funktionalitet og data skal ikke im- plementeres i dette miljø.
Krav til etableringstidspunkt for ovenstående miljøer kan findes i bilag 1 og bilag 7.2.J.
Minimumskrav til konfiguration af disse miljøer er beskrevet i bilag 7.2.C og bilag 7.2.C.1-4. I bilag 6 er det beskrevet hvilke test, der skal gennemføres i hvilke miljøer.
Ligesom ibrugtagningen af Produktionsmiljøet er beskrevet i bilag 13 Implementering og bilag 14 Uddannelse.
Krav # 102 Leverandøren skal levere disse miljøer | |||
Kategori: | (K) | Type: | Ikke funktionelt |
Beskrivelse: | Leverandøren skal levere disse miljøer, som en del af leverancen: • Produktionsmiljø • Præprodmiljø • Ekstern testmiljø • Intern testmiljø • Sandkassemiljø Krav til etableringstidspunkt for ovenstående miljøer kan findes i bilag 1. Disse miljøer skal beskrives i bilag 7.2.C.1-4 | ||
Leverandøren skal beskrive hvordan Widget leverandørerne udvikler en Widget, der kan testes i Sandkassemiljøet og efterfølgende kan sættes i drift af Kommunerne. Denne beskrivelse skal ud- gøre en drejebog for udvikling og idriftsættelse af Widgets til udstilling på Løsningen.
Krav # 103 Leverandøren skal udarbejde en drejebog for udvikling og idriftsættelse af Widgets | |||
Kategori: | (K) | Type: | Ikke funktionelt |
Beskrivelse: | Leverandøren skal udarbejde en komplet drejebog med alle de oplysninger som er nødvendig for at en widget-leverandør kan udvikle en ny Widget, teste Widget i sandkassemiljøet, få godkendt Widget og sætte Widget i drift. Drejebogen skal også indeholde rådgivning omkring udvikling af Widgets, f. eks. om hvordan Widget leverandøren bedst sikre god performance i Widget. Dog skal afsnit omkring godkendelse af Xxxxxxx udarbejdes i samarbejde med KOMBIT, da KOMBIT vil afdække governance proces omkring godken- delse af Widgets. Drejebogen vil være del af bilag 4 Dokumentation | ||
Løsningen skal designes og udvikles, så det bliver muligt at tredele forvaltningsleverancen. Detal- jerne omkring tredeling kan findes i bilag 7.1.
Krav # 104 Løsningen skal understøtte krav om tredeling | |||
Kategori: | (K) | Type: | Ikke funktionelt |
Beskrivelse: | Design af Løsningen skal understøtte KOMBITs krav om tredeling, så Løsnin- gen i forvaltningsfasen skal kunne deles op i tre leverancer: Infrastrukturdrift, Applikationsdrift og Applikationsvedligehold. Det skal være muligt, at de enkelte dele kan leveres uafhængigt af de øvrige. Dette skal afspejles i Leverandørens leverancer f. eks. Dokumentation. | ||
Der er behov for at Løsningen logisk adskiller Kommunerne fra hinanden. Tilsvarende skal der også være en logisk adskillelse mellem Kommunens Institutioner, så Opslag og lign. kan adskilles mellem Institutioner.
Løsningen forventes derfor at eksistere i én logisk instans per Institution. Institution dækker her også administrative inddelinger, såsom at en række dagplejemødre hører administrativt sammen og har en instans af Løsningen.
Krav # 105 Løsningen skal give mulighed for en logisk instans per Institution | |||
Kategori: | (K) | Type: | Ikke funktionelt |
Beskrivelse: | Løsningen skal designes så en logisk instans svarer til en Institution. Kommu- nen bestemmer hvordan Institutioner opdeles. Leverandøren skal i samarbejde med KOMBIT i Afklaringsfasen afdække, hvordan Institutioner opdeles. | ||
Da den enkelte Kommune er databehandler og derfor ansvarlig for data om Kommunens borgere, er det vigtigt at data i Løsningen kan afgrænses per Kommune.
Krav # 106 Data i Løsningen skal afgrænses per Kommune | |||
Kategori: | (K) | Type: | Ikke funktionelt |
Beskrivelse: | Løsningen skal muliggøre isolering af data mellem de enkelte Kommuner. | ||
Løsningen må ikke opbevare data som med sikkerhed ikke skal anvendes senere af Løsningen. Desuden har alle data en maksimal tid som de må gemmes, og derfor er det vigtigt at Løsningen sørger for oprydning af data med jævne mellem rum. De nøjagtige regler for sletning af data fast- lægges i afklaringsfasen.
Krav # 107 Løsningen skal sikre sletning af data | |||
Kategori: | (K) | Type: | Ikke funktionelt |
Beskrivelse: | Løsningen skal sikre at data i databasen, som ikke senere skal anvendes af Løsningen, bliver slettet. Løsningen skal indeholde oprydningskørsler som gennemfører disse sletnin- ger i alle Løsningens databaser (inkl. Logning) | ||
6.1.5.2 Tekniske krav til Løsningens centrale infrastruktur
Løsningens miljøer som er beskrevet i afsnit 6.1.5.1, skal etableres på baggrund af beskrivelsen i bilag 7.2.C og underbilag.
Krav # 108 Leverandøren skal overholde krav til central infrastruktur | |||
Kategori: | (K) | Type: | Ikke funktionelt |
Beskrivelse: | Løsningens miljøer etableres på baggrund af krav til central infrastruktur, som er beskrevet i bilag 7.2.C. | ||