UDKAST TIL GENEREL KRAVSPECIFIKATION

Transkript

1 BPI UDKAST TIL KRAVSPECIFIKATION FOR LÆRINGSPLATFORM BPI UDKAST TIL GENEREL KRAVSPECIFIKATION Læringsplatform - BPI

2 BPI Side 2 af 53 1 Om dette dokument Dette dokument er et udkast til en generel kravspecifikation til læringsplatformen, under Brugerportalsinitiativet. Dokumentet er til review og kan ikke anvendes til kravspecifikation eller til besvarelse af krav. Dokumentet er første version af den kravspecifikation, som Kommunerne kan anvende, når de skal anskaffe læringsplatform. Dokumentet sendes til kommentering hos følgende interessenter: Leverandører af Læringsplatforme (Learning Management Systems) BPI-kontaktpersoner hos kommunerne Pædagogisk Personale, der har deltaget i kravspecificeringsarbejdet Styregruppen for læringsplatformen STIL Styrelsen for IT- og Læring Foreningen Skole og Forældre Formålet med at udsende dokumentet i en ufærdig form er, at kvalificere dokumentet, med hjælp fra de relevante brugergrupper, for at sikre dets anvendelighed i praksis. Kommunerne, der skal anvende dokumentet til at stille krav til deres leverandører. Leverandørerne, der skal anvende dokumentet til, at sikre at deres løsning opfylder relevante krav. Beslutningstagere, der skal godkende kravene. Slutbrugere, der i den sidste ende skal anvende læringsplatformen. Dokumentet vil danne udgangspunkt for den endelige kravspecifikation, der udsendes ved udgang af Bilag Bilag vedlagt dette dokument er, User Stories - katalog til review. 1.1 Om formen på den endelige kravspecifikation Den endelige kravspecifikation, som KL leverer, vil kunne danne grundlag for kommunens indkøb, men det er vigtigt, at slå fast, at hver enkelt kommune, skal justere dokumentet sådan at det passer til netop deres kommune. Den endelige kravspecifikation, vil bestå af minimumskrav og krav. Minimumskrav er krav det er nødvendigt at opfylde, for at læringsplatformen, for eksempel vil kunne integrere til de andre systemer i Brugerportalsinitiativet eller som er nødvendige at opfylde for at overholde lovgivningen. Alle andre krav skal af kommunen til/fravælges, evt. omformuleres og vægtes i forhold til tilbudsevaluering. En stor del af de funktionelle krav, er udarbejdet på baggrund af User Stories, der er blevet til i workshops med slutbrugere. Det anbefales, at kommunerne hver især gennemgår dem med deres slutbrugere og tilføjer samt justerer derefter. Der kan være andre af kommunens systemer og værktøjer, der skal kunne anvendes sammen med læringsplatformene, disse er vigtige også at beskrive særskilt. Krav til dokumentation og projektstyring, vil ligeledes skulle justeres efter lokale modeller.

3 BPI Side 3 af Læsevejledning af dette dokumentet Dette dokumentet har i de efterfølgende kapitler, den samme struktur som den endelige kravspecifikation vil have Afsnit der udelades fra review Nogle afsnit bedes I som læsere at se bort fra, idet, det først færdigskrives efter første reviewrunde der slutter den 20 november. Dette gælder en del af de indledende afsnit, samt om dokumentation og projektstyring, der lægges til sidst. De udeladte afsnit, bliver indledt med en grå boks, med mål for afsnittet angivet og/eller med teksten: udarbejdes frem mod endelig kravspecifikation Afsnit til kommentering Det er ikke alle afsnit i kravspecifikationen, der er lige relevant for alle at kommentere på. Følgende brugergrupper vil kunne nøjes med at kommentere på funktionelle krav og User Stories Pædagogisk personale Foreningen Skole og Forældre BPI-kontakter, der primært beskæftiger sig med pædagogik, didaktik og ledelse Følgende vil kunne nøjes med at kommentere på non-funktionelle krav: IT-Teknikere hos kommunerne og hos leverandører af læringsplatforme Følgende vil med fordel kunne kommentere på begge afsnit: Leverandører af læringsplatforme Styrelsen for IT og Læring BPI-kontakter Styregruppen for læringsplatformen 1.3 Kommentarer til dette dokument For at lette arbejdet med kommentarer og spørgsmål, både for reviewere og for det videre arbejde frem mod den endelige kravspecifikation, præciseres det her, hvilke områder der er relevante at kommentere og spørge til og hvilke der ikke er Ikke til kommentering Kommentarer om grundlaget for Brugerportalsinitiativet, der blev besluttet juni 2014 med aftale mellem regeringen og KL Valg af standarder, der blev vedtaget i sommeren Referencearkitekturen, der blev udarbejdet og godkendt i juni Stavning eller syntaks, med mindre det giver anledning til semantisk forvirring. Der gøres opmærksom på, at de systemer, kommuneren anvender i det daglige, som ikke er en del af referencearkitekturen, ikke er beskrevet i dette udkast. I den version af kravspecifikationen, som kommuneren udsender til

4 BPI Side 4 af 53 deres leverandører, skal kommunerne selv indføje, de systemer, som indgår i deres arkitektur Til kommentering User Stories o Review User Stories med fokus på at tilrette eksisterende og indskrive nye Funktionelle krav, er de fyldestgørende? o For leverandører: Vurder gerne potentialer og udfordringer ved de beskrevne funktionelle krav ift jeres Læringsplatform Non-funktionelle krav, er de fyldestgørende? o For leverandører: Vurder gerne potentialer og udfordringer ved de beskrevne ikke-funktionelle krav ift jeres Læringsplatform Kommentarer i forhold til afsnit der ikke er beskrevet fyldestgørende Form på kommentarer For at kunne anvende kommentarer og spørgsmål effektivt, i det fremadrettede arbejde med kravspecifikationen, bedes kommentarer indskrives i en tabel med angivelse af afsnit, underafsnit og kommentaren, som illustreret nedenfor. Afsnitnummer Kommentar [f.eks: 3.1.4] [f.eks: der mangler en præcisering af xx ] Kommentarer bedes fremsende kommentarer skriftligt til projektleder; Gitte Stoltenberg på mail gist@kl.dk senest den 20/11 klokken Efterbehandling Alle indkomne kommentarer og nye forslag til User Stories, vil blive samlet, gennemgået og vurderet. Kravspecifikationen vil i videst muligt grad blive justeret i forhold til kommentarerne. User Stories vil i videst muligt omfang medtages i User Story-kataloget og knyttes til krav. Kommentarer og forslag til User Stories kan blive syntetiseret og omformuleret og kan derfor ikke nødvendigvis findes i sin oprindelige form, imens andre helt kan udelukkes. Efter justering og gennemskrivning af dokumentet, vil den endelige kravspecifikation udkomme ved udgangen af 2015.

5 BPI Side 5 af 53 Indhold 1 Om dette dokument...2 Bilag Om formen på den endelige kravspecifikation Læsevejledning af dette dokumentet Afsnit der udelades fra review Afsnit til kommentering Kommentarer til dette dokument Ikke til kommentering Til kommentering Form på kommentarer Efterbehandling...4 Indhold Indledning Kravspecifikationens indhold Bilag til standardkontrakt og underbilag Klassifikation af krav Feltet Krav Feltet Navn Feltet Kategori Feltet Type Feltet Beskrivelse Beskrivelse af User Stories Om User Stories User Stories i dette dokument Leverandørens besvarelse af kravspecifikation Delleverancer Kravskemaer Løsningsbeskrivelse Definitioner Baggrund, formål, målgruppe og succeskriterier Baggrund og formål med læringsplatformen Målgruppen for Læringsplatformen Business Case Succeskriterier Aktører og kontekst Kontekstdiagram Brugeraktører... 14

6 BPI Side 6 af 53 Systemaktører Funktionelle krav Læringsforløb Elevplan Progression Evaluering Trivsel Ledelse Deling Administration af læremidler Skoleskift Portefølje Brugere og rettigheder Systemadministration Ikke funktionelle krav Arkitekturstrategier og principper Specifikke arkitekturkrav (to-be målarkitektur) for Læringsplatformen Dataudveksling og integration til andre it-systemer Dataudveksling og integration til Samarbejdsplatform Dataudveksling og integration til Integrationsplatformen (STIL Integrationsplatform) Unilog-in Web Single Sign On (WebSSO) Unilog-in øvrige services Dataudveksling og integration til Kommunale systemer indeholdende fraværsoplysninger Dataudveksling og integration til andre Kommunale systemer Dataudveksling og integration til kommunale fildelingsløsninger Dataudveksling og integration til Digitale Læremidler og producenter heraf Dataudveksling og integration til biblioteker Eksport og import af læringsforløb Standarder for læringsindhold DK-LOM DK-Cartridge DK-LTI Brugervenlighed og look and feel Lovmæssige krav Bekendtgørelse om krav til digitale elevplaner i folkeskolen: BEK 704 af 23. juni Persondataloven: Lov 429 af 31. maj

7 BPI Side 7 af Informationssikkerhed: ISO Sikkerhed... 53

8 BPI Side 8 af 53 2 Indledning Mål: Formålet med kravspecifikationen beskrives udarbejdes frem mod endelig kravspecifikation 2.1 Kravspecifikationens indhold Mål: Læsevejledning udarbejdes frem mod endelig kravspecifikation 2.2 Bilag til standardkontrakt og underbilag Mål: Beskrive hvilken samling af dokumenter dette dokument indgår i, på hvilken måde og lister øvrige bilag. udarbejdes frem mod endelig kravspecifikation 2.3 Klassifikation af krav Alle kravene i denne kravspecifikation er angivet ved et unikt fortløbende nummer og vil være angivet i tabeller som vist her: [Navn] Kategori: Type: Feltet Krav Alle krav er i kravspecifikationen angivet ved et unikt fortløbende nummer Feltet Navn Alle krav har et unikt sigende navn Feltet Kategori I feltet Kategori kravets kategori med en af følgende kategorier: Minimumskrav Krav Option Feltet Type I feltet Type kravets type med en af følgende typer:

9 BPI Side 9 af 53 Funktionelt krav Ikke-funktionelt krav Lov og politik (lovmæssige og politiske krav til løsningen) Feltet Beskrivelse I feltet Beskrivelse gives en tekstbeskrivelse af kravet. 2.4 Beskrivelse af User Stories Der er udført et omfattende arbejde med udarbejdelse af User Stories. De er udarbejdet i samarbejde med: En gruppe lærere fra Den Danske Folkeskole Styrelsen for IT og Læring Skoleelever (indføjes efter udkast 1) Forældre (indføjes efter udkast 1) Formålet med at inddrage interessenter i arbejdet med User Stories var at: Sikre at ønsker fra pædagogisk personale og andre kommunale aktører høres og medtænkes De krav der stilles er relevante i forhold til den praksis de skal understøtte Give aktørerne medansvar og understøtte forankring Deltagerne vil blive ambassadører for løsningen hos kommunerne At løsningen afspejler brugspraksis den skal anvendes i At løsningen bliver anvendt af de fremtidige brugere Om User Stories En user story er en kort simple beskrivelse af anvendelse af en komponent eller funktionalitet. Historien om anvendelsen er fortalt fra brugerens perspektiv, oftest af brugeren selv. Typisk har en user story formen: Som [bruger] kan jeg [funktion] for at [værdi] Anvendelsen af User Stories giver et anvendeligt format, der ud over at beskrive den praktiske anvendelse af funktionaliteten også beskriver den værdi den føjer til forretningen.på den mådebidrager rækken af User Stories til den samlede forretningsbegrundelse. En af styrkerne ved User Stories er at de er lette at skrive og at forstå. Det simple format gør dem forståelige, både for brugere, beslutningstagere og teknikere. Historierne gør det mulig for de brugergrupper, der kender og forstår den praksis løsningen skal indgå i, at kommunikere klart om deres behov til de leverandører der skal levere dem. Man arbejder typisk med User Stories i grupper af brugere. Man kan sige at man kollektivt brainstormer over værdien af funktionaliteten og på en struktureret måde beskriver hvad produktet skal kunne og hvad man skal kunne gøre ved hjælp af det. User Stories flytter fokus fra det skrevne og hen på konversationen og dette er en vigtig egenskab. Fordi disse konversationer gør det muligt at have en mere alsidig form for udveksling af information og samarbejde, for at sikre at de rette krav er udtrykt og forstået af alle. Konversation giver flere personer mulighed for at fremkomme med deres forståelse af situationen og af den historie der skrives. Dermed kan historien justeres og præciseres, hvilket kan være en fordel i forhold til at få flere aspekter med. Verbal, gensidig konversation har den fordel, at der hurtigt kan gives feedback, hvilket gør det lettere og hurtigere at opnå en fælles forståelse. Gensidig konversation

10 BPI Side 10 af 53 fremmer dynamik og nye ideer, nye vinkler på problemer og muligheder diskussioner, der ikke lige så let opstår ud fra et skrevet dokument User Stories i dette dokument Hver User Story hører til et funktionelt krav. User Stories, tjener til uddybelse af kravenes, funktion og forretningsværdi. En User Storie vil altid, uden undtagelse være koblet til et krav, men er ikke i sig selv et krav. 2.5 Leverandørens besvarelse af kravspecifikation Mål: Beskrivelse af hvordan leverandøren skal besvare krav og i hvilke dokumenter udarbejdes frem mod endelig kravspecifikation 2.6 Delleverancer Mål: Beskrivelse hvordan leverandøren skal beskrive delleverancer udarbejdes frem mod endelig kravspecifikation 2.7 Kravskemaer Mål: Beskrive hvordan leverandøren skal besvare kravskemaer der er beskrevet ovenfor udarbejdes frem mod endelig kravspecifikation 2.8 Løsningsbeskrivelse Mål: Beskrive hvordan leverandøren skal beskrive løsningen udarbejdes frem mod endelig kravspecifikation 2.9 Definitioner Læringsplatformen Kunden Leverandør It-systemer Fælles mål Betegnelse for det it-system som kravspecifikationen vedrører og som skal indkøbes. Betegnelsen Løsningen anvendes ikke. Den pågældende kommune, der udbyder opgaven og som bliver kontraktpart. Kan også være et indkøbsfællesskab. Anvendes generelt til at beskrive Tilbudsgiver og senere Kontraktpart. Generel betegnelse for it-systemer. Erstatter bl.a. også it-løsninger, der ikke anvendes. Under udarbejdelse Kompetencemål/ Målpar Under udarbejdelse

11 BPI Side 11 af 53 Færdighedsmål Under udarbejdelse Vidensmål Under udarbejdelse Læringsmål Under udarbejdelse Udbygges løbende

12 BPI Side 12 af 53 3 Baggrund, formål, målgruppe og succeskriterier I dette afsnit beskrives formålet med kravspecifikationen, så det er klart hvad den skal og i hvilken kontekst den skal indgå. Det beskrives endvidere hvem den er rettet imod og hvordan man kan vurdere projektets succes 3.1 Baggrund og formål med læringsplatformen I juni 2014 aftalte regeringen og KL at realisere initiativet om en brugerportal for folkeskolen som følge af aftalen om kommunernes økonomi i Aftalen udsprang af folkeskolereformen og har til formål at understøtte folkeskolereformen, ved hjælp af konkrete digitale initiativer. Målene for folkeskolereformen lyder: Det faglige niveau i folkeskolen skal forbedres. Dette skal ske ved på den ene side at bygge videre på folkeskolens nuværende styrker, og på den anden side at tage hånd om de udfordringer skolen står overfor. Aftaleparterne (daværende regeringen, Venstre og Dansk Folkeparti) vil derfor fastholde og udvikle folkeskolens styrker og faglighed ved at arbejde for følgende tre overordnede mål: 1) Folkeskolen skal udfordre alle elever, så de bliver så dygtige, de kan. 2) Folkeskolen skal mindske betydningen af social baggrund i forhold til faglige resultater. 3) Tilliden til og trivslen i folkeskolen skal styrkes blandt andet gennem respekt for professionel viden og praksis.( fra Aftale mellem regeringen (Socialdemokraterne, Radikale Venstre og Socialistisk Folkeparti), Venstre og Dansk Folkeparti om et fagligt løft af folkeskolen, 7. juni 2013) Programmets formål er, at understøtte folkeskolereformen og bringe den digitale Folkeskole et stort skridt fremad, ved at etablere tidsvarende digitale løsninger. Løsningerne skal kunne understøtte kommunikation, læring og trivsel i Folkeskolen og bidrage til opfyldelse af målene i folkeskolereformen. Som en del af Brugerportalsinitiativet er det et mål at: Alle kommuner har indkøbt en læringsplatform i overensstemmelse med gældende lovgivning og BPI-aftalen. Læringsplatforme er i drift på alle skoler ved udgangen af Kunden står for at indkøbe læringsplatform til kommunens skoler. Kunden ønsker at læringsplatformen understøtter de strategier for skoleområdet, der er lagt i kommunen og samtidigt understøtter målene i Brugerportalsinitiativet. <OM KOMMUNENS STRATEGIER FOR SKOLEOMRÅDET> Læringsplatformen skal være omdrejningspunkt for en del af det daglige arbejde på kommunens skoler, der handler om: Elevplan Læringsforløb Fælles mål Progression Trivsel Og der skal kunne anvendes Digitale læremidler Relevante nationale IT-services 3.2 Målgruppen for Læringsplatformen udarbejdes frem mod endelig kravspecifikation men se afsnit om Brugeraktører

13 BPI Side 13 af Business Case <Kommuner skal selv indsætte deres egen business case for projektet> 3.4 Succeskriterier Mål: Beskrivelse af succeskriterier udarbejdes frem mod endelig kravspecifikation

14 BPI Side 14 af 53 4 Aktører og kontekst I dette kapitel forklares den kontekst Læringsplatformen skal fungere i, og aktørerne (både bruger- og systemaktører) beskrives. 4.1 Kontekstdiagram Kontekstdiagrammet herunder viser Læringsplatformen og de (primære) aktører der skal understøttes, både brugere og systemer; Figur 1: Kontekstdiagram for Læringsplatformen Grundlæggende set vil Læringsplatformen skulle kunne integrere til fire systemaktører samt en række primære brugertyper, hvor Pædagogisk personale, elever, skoleledelser og forældre er de primære brugere. I afsnittene herunder er Brugeraktører og Systemaktører gennemgået mere dybdegående. Brugeraktører Figuren herunder viser de primære brugergrupper med en kort beskrivelse af de behov de har, der skal understøttes af Læringsplatformen.

15 BPI Side 15 af 53 Figur 2: Brugeraktører Udover de fire primære brugeraktører er der en række andre brugere der skal understøttes af løsningen (se Andre brugere nedenfor) I skemaerne herunder er hver brugeraktør beskrevet. Navn Rolle Organisatorisk placering Antal/Kapacitet (angivet på nationalt plan) Pædagogisk Personale Pædagogisk Personale dækker lærere, pædagoger og andre der arbejder med undervisning og har ansvar for at; planlægge, igangsætte og evaluere læringsforløb Oprette elevplaner og planlægge elevers læringsforløb i forhold til Fælles Mål og Læringsmål For det Pædagogisk Personale vil Læringsplatformen være deres primære it-applikation i forhold til deres didaktiske og læringsmæssige arbejde. Pædagogisk Personale vil typisk være ansat på en bestemt skole, men kan også være ansat kommunalt med behov for at arbejde på flere skoler folkeskolelærere og pædagoger <Her indsættes kommunens eget antal> Navn Rolle Elev Elev dækker alle børn der går i folkeskole, og herunder hørende tilbud som SFO og klub, i kommunen. Gruppen er præget af stor diversitet bestående af indskolingsbørn op

16 BPI Side 16 af 53 til udskolingselever. Deres it-forudsætninger er vidt forskellige, lige som deres sproglige, faglige og sociale forudsætninger dækker hele spekteret i Den Danske Folkeskole. Organisatorisk placering Antal/Kapacitet (angivet på nationalt plan) En elev er tilhørende en folkeskole, samt en hertil hørende SFO eller klub <Her indsættes kommunens eget antal> Navn Rolle Organisatorisk placering Antal/Kapacitet (angivet på nationalt plan) Forældre Forældre dækker alle myndige personer med juridisk myndighed over en elev i en af kommunens skoler eller tilbud. Forældre er en divers brugergruppe, både ift itkompetencer og ambition for involvering i deres børns skolegang. Samtidigt er der en gruppe forældre med anden sproglig baggrund, vanskeligheder ved at begå sig skriftligt eller andre udfordringer som bedst muligt skal understøttes i løsningen. En forælder kan have børn i en eller flere skoler (på tværs af kommuneskel). Børnene kan desuden gå i SFO, klub og lignende. Anslået <Her indsættes kommunens eget antal> Navn Rolle Organisatorisk placering Antal/Kapacitet (angivet på nationalt plan) Skoleledelse Skoleledelsen består af skoledere, viceskoleledere samt administrativt personale der udfører ledelsens arbejde (ex i forbindelse med indberetninger til kommune). Skoleledelsen er både forankret kommunalt og på den enkelte skole, hvilket stiller specielle krav til hvordan de itsystemer de anvender kan interagere. Anslået <Her indsættes kommunens eget antal> Navn Rolle Andre aktører Dækker en bred vifte af personer der skal have mulighed for at anvende læringsplatformen, ex;

17 BPI Side 17 af 53 En UU-vejleder der skal vurdere en elevs uddannelsesparathed, har behov for at kunne se elevens elevplan og portefølje En ekstern partner der har ansvar for at administrere læringsforløb med skolens elever En AKT-vejleder skal have adgang til elevplan og portefølje for bedst at rådgive omkring en elev med særligt fokus Det betyder at andre aktører skal kunne få adgang til løsningen, men begrænset til enkeltstående overblik og funktionaliteter ift Pædagogisk Personale. Organisatorisk placering Antal/Kapacitet (angivet på nationalt plan) Andre aktører kan være Pædagogisk Personale på skolen, vejledere fra andre kommunale instanser eller eksterne parter. Ca <Her indsættes kommunens eget antal> Systemaktører Læringsplatformen bliver det centrale it-system for de primære brugergrupper og for at opfylde brugernes behov er det nødvendigt for platformen at interagere med følgende systemaktører: Figur 3: Systemaktører Herunder er beskrevet systemaktørerne samt hvordan det forventes at Læringsplatformen skal interagere med dem.

18 BPI Side 18 af 53 Navn Beskrivelse Samarbejdsplatform Samarbejdsplatformen er brugernes primære indgang til skoleområdet gennem websider eller apps. I Samarbejdsplatformen håndteres kommunikation, nyheder, kalender, sikker fildeling m.m. Derudover vil eksterne systemer kunne udstille deres brugergrænseflader (såkaldte widgets) igennem Samarbejdsplatformen, så brugeren oplever at skulle gå ind i færrest mulige forskellige systemer. Samarbejdsplatformen anskaffes fælleskommunalt og har som mål at være idriftsat sommer Kravsætning til leverandører af Læringsplatforme vil være at kunne udstille udvalgte (samt de leverandører derudover ønsker at tilbyde sine brugere) widgets ultimo Rolle Ansvar At give brugerne en indgang til de værktøjer de bruger ifm skolen, herunder Læringsplatform, fildeling, kommunikation, kalender mv. At tilbyde en samlet platform som kan rumme alle eksterne systemers brugergrænseflader driftet centralt men kommunalt ansvar for lokal opsætning. At give brugere mulighed for at personalisere deres websider og apps (vælge widgets og placering heraf) Organisatorisk placering og Systemejer KOMBIT

19 BPI Side 19 af 53 Navn Beskrivelse Digitale Læremidler Digitale Læremidler er læringsforløb (eller dele heraf) som gennemføres i et eksternt miljø. Det kan eksempelvis være matematikopgaver i en portal eller større projekter der gennemføres over længere tid. I læringsplatformen skal man kunne vedligeholde adgange til Digitale Læremidler, og kunne udveksle data med Læremidlet omkring ex igangsættelse, grupper og rettigheder, progression, evaluering og afslutning. I regi af brugerportalinitiativet bliver der i december 2015 vedtaget tre danske standarder for læringsindhold. Standarderne skal sikre, at der kan udveksles læringsindhold mellem læringsplatforme fra forskellige leverandører, og at der kan overføres resultater fra de digitale læremidler til Læringsplatformen. Det er ambitionen at markedet skal være så frit som muligt hvorfor det vil tælle positivt for en Læringsplatform at integrere flest mulige Digitale Læremidler. Samtidigt vil det veje negativt såfremt der er dårlige muligheder for at integrere Digitale Læremidler, eller såfremt Læringsplatformen gør det nemmere at anvende visse producenters Digitale Læremidler over andres. Rolle Ansvar At lade elever gennemføre læringsforløb, eller dele heraf, på en måde der hænger sammen med Elevplan og Læringsforløb. At sikre størst mulig faglig gevinst for elever At sikre bedst mulig sammenhæng med Læringsplatform Organisatorisk placering og Systemejer Hos producent

20 BPI Side 20 af 53 Navn Beskrivelse STIL Integrationsplatform Styrelsen for IT og Lærings Integrationsplatform har til formål at stille relevante data til rådighed indenfor skoleområdet. Relevant for Læringsplatform er; Fælles Mål hvor Læringsplatformen kan hente UVMs Forenklede Fælles Mål Materialeplatformen hvor Læringsplatformen kan søge og hente information om materialer og leverandører De Nationale Test (DNT) hvor Læringsplatformen kan hente information om tests og testresultater Datavarehus hvor statistik kan hentes til at skabe overblik for Pædagogisk Personale og Skoleledelse EMU videnportal hvor Læringsplaform kan søge og hente information om læringsforløb Rolle At stille relevant information til rådighed til at sikre at læringsforløb og materialer kan deles og genbruges At udstille data om progression (tests) og trivsel til brug i lokale systemer At give statistisk overblik, så skoler kan vurdere sig ift andre skoler Ansvar Organisatorisk placering og Systemejer At tilbyde data via en sikker løsning og integration STIL

21 BPI Side 21 af 53 Navn Beskrivelse Fildelingsløsninger Skolerne anvender i dag en række forskellige fildelingsløsninger som OneDrive, GoogleDrive, Dropbox, lokale filservere m.v. Mange af de filer vil være relevante for Læringsplatformen, for at sikre at evaluering og feedback foretages på de rigtige filer/dokumenter, samt for at skabe elevens samlede portefølje af progression og produkter. Læringsplatformen skal i højst muligt omfang gøre det muligt for brugere at overføre dokumenter mellem fildelingsløsninger og Læringsplatformen. Her vil det vægte positivt jo nemmere det opleves af brugeren. Rolle At give brugerne en fildelingsløsning der fungerer godt og muliggør deling i dynamiske grupper At give brugerne en fildelingsløsning der sikrer informationer der er personfølsomme Ansvar Organisatorisk placering og Systemejer Sikkerhed ift personfølsomme oplysninger Kommune og leverandøren af dennes fildelingsløsning 5 Funktionelle krav Dette kapitel indeholder kravspecifikationens funktionelle krav, herved forstået krav som er møntet på hvordan løsningen vil understøtte brugernes behov. Der er defineret 10 funktionelle områder Læringsplatformen skal understøtte. Hvert funktionelt område består af en række User Stories der fra brugerens vinkel forklarer deres behov og den værdi de får ud af at have funktionaliteten. Det er ikke forventeligt at en Læringsplatform kan understøtte alle User Stories fuldt ud, da de repræsenterer en bruttoliste af krav defineret på gaggrund af foranalyserne til Brugerportalsinitiativet, en række workshops med kommunerne samt allerede udarbejdet materiale fra kommunernes anskaffelser. User Stories kan ses i bilaget User Story Katalog til review hvor der findes et faneblad for hvert af de ti områder. 5.1 Læringsforløb Et Læringsforløb er et afgrænset forløb hvor en eller flere elever gennemfører et forløb, der leder mod enten et Læringsmål eller et Forenklet Fælles Mål. Læringsforløb kan have meget varierende omfang, og være forskellige af natur. Det kan eksempelvis være et rent fysisk forløb som at undersøge et stykke natur og finde plantearter, et læringsforløb der gennemføres i et eksternt Digitalt Læremiddel eller en blanding af de to. Når en lærer har nedbrudt et Forenklet Fælles Mål til en række Læringsmål som eleverne skal nå, er læringsforløbet den aktivitet der leder eleverne mod deres individuelle mål. Læringsforløb vil oftest blive udarbejdet af det Pædagogiske

22 BPI Side 22 af 53 Personale, men kan ligeså vel være forløb som eleverne selv udformer. For det Pædagogiske Personale skal man kunne planlægge, revidere, gemme og offentliggøre læringsforløb, ligesom de skal kunne knyttes til Digitale Læremidler og bestemte elevgrupper. Såfremt et læringsforløb er hentet fra en ekstern kilde, skal det efterfølgende i Læringsplatformen kunne redigeres på lige fod med læringsforløb skabt i løsningen. Krav XX: User Stories - Læringsforløb Navn Beskriv for hver user story hvordan den opfyldes i jeres system. Bemærk at der skal besvares ud fra systemets nuværende version på markedet. Såfremt det er planlagt at opfylde user story i en fremtidig version bør det noteres særskilt og vil blive vægtet positivt, men ikke som opfyldelse af krav. Leverandørens besvarelse: Besvarelse pr User Story: US-YYY US-ZZZ Øvrige kommentarer til opfyldelse af kravgrupperingen: <udfyldes af tilbudsgiver> 5.2 Elevplan Elevplanen er det værktøj hvori det pædagogiske personale, eleven eller begge to, planlægger elevernes udvikling. Fra de Forenklede Fælles Mål alle elever skal nå, angives Nedbrudte Mål der bliver elevens delmål på vejen mod læring, der opfylder det forenklede fælles mål. Elevplanen viser også elevens samlede progression indtil nu (som beskrevet nedenfor), og er det kommunikationsværktøj der anvendes mellem Pædagogisk Personale, Forældre og elev ex i forbindelse med Skolehjem samtaler. Alle parter har mulighed for at kommentere elevplanen, eksempelvis skal eleven kunne være med til at angive Læringsmål for sin egen udvikling. Krav XX: User Stories - Elevplan Navn Beskriv for hver user story hvordan den opfyldes i jeres system. Bemærk at der skal besvares ud fra systemets nuværende version på markedet. Såfremt det er planlagt

23 BPI Side 23 af 53 at opfylde user story i en fremtidig version bør det noteres særskilt og vil blive vægtet positivt, men ikke som opfyldelse af krav. Leverandørens besvarelse: Besvarelse pr User Story: US-YYY US-ZZZ Øvrige kommentarer til opfyldelse af kravgrupperingen: <udfyldes af tilbudsgiver> 5.3 Progression Progression handler om den del af Elevplanen der handler om hvor langt en elev er nået indtil nu. Det vil sige hvilke Læringsforløb der er gennemført med hvilken evaluering og feedback, eventuelt med en oversigt over de udarbejdede produkter. Krav XX: User Stories - Progression Navn Beskriv for hver user story hvordan den opfyldes i jeres system. Bemærk at der skal besvares ud fra systemets nuværende version på markedet. Såfremt det er planlagt at opfylde user story i en fremtidig version bør det noteres særskilt og vil blive vægtet positivt, men ikke som opfyldelse af krav. Leverandørens besvarelse: Besvarelse pr User Story: US-YYY US-ZZZ Øvrige kommentarer til opfyldelse af kravgrupperingen: <udfyldes af tilbudsgiver> 5.4 Evaluering Evaluering omfatter den evaluering, feedback og vurdering der skal til i et Læringsforløb. Der skal være mulighed for, at Pædagogisk personale kan vurdere, eleven selv kan evaluere sig selv og at elever kan give hinanden feedback. For elever er det vigtigt at de modtager evaluering, feedback eller vurdering på en måde som passer til deres alder og kompetenceniveau, og som virker motiverende for dem. Der skal for Pædagogisk Personale også være mulighed for at se samlede oversigte over evalueringer og vurderinger pr klasse, klassetrin etc.

24 BPI Side 24 af 53 <Info til kommuner: Der tages i denne kravspecifikation ikke stilling til hvordan man ønsker evaluering skal foregå, hvilket kommunen bør indføre alt efter hvilken didaktisk linie man ønsker (tekstuel feedback, godkendt/ikke-godkendt og andre måder at evaluere. Der kan eventuelt kravstilles i forhold til at integrere til eksterne systemer, så målinger vises i læringsplatformen)> Krav XX: User Stories - Evaluering Navn Beskriv for hver user story hvordan den opfyldes i jeres system. Bemærk at der skal besvares ud fra systemets nuværende version på markedet. Såfremt det er planlagt at opfylde user story i en fremtidig version bør det noteres særskilt og vil blive vægtet positivt, men ikke som opfyldelse af krav. Leverandørens besvarelse: Besvarelse pr User Story: US-YYY US-ZZZ Øvrige kommentarer til opfyldelse af kravgrupperingen: <udfyldes af tilbudsgiver> 5.5 Trivsel For de kommuner der ønsker at arbejde løbende og koordineret med elevernes trivsel, skal man kunne måle elevernes individuelle trivsel jævnligt og være understøttet i at planlægge og gennemføre tiltag og forløb der bringer eleverne til bedre trivsel. Dette kan ske både individuelt og i grupper. Det skal samtidigt være muligt at se resultater af den nationale trivselsundersøgelse, om end den ikke er på individ niveau. <Info til kommuner: Emnet dækker både User Stories der er rettet mod trivsel ifm nationale trivselsmål og User Stories omkring mere aktivt arbejde med trivsel. Sidstnævnte skal kun medtages i kravspecifikation såfremt man ønsker at anskaffe en Læringsplatform med indbygget trivselsunderstøttelse. Mange kommuner bruger eksterne systemer til dette, og bør i så fald udelade kravene. Der kan eventuelt kravstilles i forhold til at integrere til eksterne systemer, så målinger vises i læringsplatformen > Krav XX: User Stories - Trivsel Navn Beskriv for hver user story hvordan den opfyldes i jeres system. Bemærk at der skal besvares ud fra systemets nuværende version på markedet. Såfremt det er planlagt

25 BPI Side 25 af 53 at opfylde user story i en fremtidig version bør det noteres særskilt og vil blive vægtet positivt, men ikke som opfyldelse af krav. Leverandørens besvarelse: Besvarelse pr User Story: US-YYY US-ZZZ Øvrige kommentarer til opfyldelse af kravgrupperingen: <udfyldes af tilbudsgiver> 5.6 Ledelse Som skoleledelse er det vigtigt at kunne følge med i både pædagogisk personale og elevers arbejde, for at sikre at man bevæger sig i den retning som skolen samlet set ønsker. Det betyder at ledelsen skal kunne se elevplaner og lærernes målnedbrydning, ligesom aggregeret information baseret på Læringsplatformens indhold vil være et stærkt redskab for ledelsen. Det skal samtidigt være muligt for ledelsen at holde godt øje med elever med særligt fokus for at sikre inklusion og et passende niveau af samarbejde om det enkelte barn. Krav XX: User Stories - Ledelse Navn Beskriv for hver user story hvordan den opfyldes i jeres system. Bemærk at der skal besvares ud fra systemets nuværende version på markedet. Såfremt det er planlagt at opfylde user story i en fremtidig version bør det noteres særskilt og vil blive vægtet positivt, men ikke som opfyldelse af krav. Leverandørens besvarelse: Besvarelse pr User Story: US-YYY US-ZZZ Øvrige kommentarer til opfyldelse af kravgrupperingen: <udfyldes af tilbudsgiver> 5.7 Deling En stor gevinst for skolerne vil være i størst muligt omfang at kunne dele læringsforløb, både på skolen, i kommunen og nationalt. Derfor skal man kunne søge og filtrere i læringsforløb og nemt få adgang til relevante forløb (eksempelvis vedrørende emner der er oppe i medierne). Man skal kunne evaluere og kommentere læringsforløb, så

26 BPI Side 26 af 53 andre får mulighed for at vurdere om det passer til deres kontekst, ligesom det skal kunne ses hvilke licenser der kræves for at kunne gennemføre forløbet (ex om det er frit tilgængeligt via EMU eller kræver licens til et bestemt Digitalt Læremiddel). Krav XX: User Stories - Deling Navn Beskriv for hver user story hvordan den opfyldes i jeres system. Bemærk at der skal besvares ud fra systemets nuværende version på markedet. Såfremt det er planlagt at opfylde user story i en fremtidig version bør det noteres særskilt og vil blive vægtet positivt, men ikke som opfyldelse af krav. Leverandørens besvarelse: Besvarelse pr User Story: US-YYY US-ZZZ Øvrige kommentarer til opfyldelse af kravgrupperingen: <udfyldes af tilbudsgiver> 5.8 Administration af læremidler Skolerne vil potentielt komme til at anvende mange forskellige producenters digitale læremidler og det vil derfor være vigtigt at man nemt kan finde de læremidler man har adgang til, samt eksempelvis se hvor længe et læremiddels licens er gældende. Krav XX: User Stories Administration af læremidler Navn Beskriv for hver user story hvordan den opfyldes i jeres system. Bemærk at der skal besvares ud fra systemets nuværende version på markedet. Såfremt det er planlagt at opfylde user story i en fremtidig version bør det noteres særskilt og vil blive vægtet positivt, men ikke som opfyldelse af krav. Leverandørens besvarelse: Besvarelse pr User Story: US-YYY US-ZZZ Øvrige kommentarer til opfyldelse af kravgrupperingen: <udfyldes af tilbudsgiver>

27 BPI Side 27 af Skoleskift Når en elev eller pædagogisk personale skifter skole, er det vigtigt at relevant data kan eksporteres til en anden Læringsplatform. For eleven gælder det om elevplan, progression, portefølje og produkter. For læreren vil det typisk være de læringsforløb man gerne vil fortsætte med at anvende. Krav XX: User Stories - Skoleskift Navn Beskriv for hver user story hvordan den opfyldes i jeres system. Bemærk at der skal besvares ud fra systemets nuværende version på markedet. Såfremt det er planlagt at opfylde user story i en fremtidig version bør det noteres særskilt og vil blive vægtet positivt, men ikke som opfyldelse af krav. Leverandørens besvarelse: Besvarelse pr User Story: US-YYY US-ZZZ Øvrige kommentarer til opfyldelse af kravgrupperingen: <udfyldes af tilbudsgiver> 5.10 Portefølje Porteføljen indeholder en elevs produktioner gennem tiden. Det kan være alle typer filer der dækker tekst, video, lyd og så videre, men også andre data om den givne produktion. I denne forbindelse er det vigtigt at eleven nemt kan flytte filer fra det sted hvor de er produceret (eks fildelingsløsning eller i Digitalt Læremiddel) til Læringsplatformens portefølje. Krav XX: User Stories - Portefølje Navn Beskriv for hver user story hvordan den opfyldes i jeres system. Bemærk at der skal besvares ud fra systemets nuværende version på markedet. Såfremt det er planlagt at opfylde user story i en fremtidig version bør det noteres særskilt og vil blive vægtet positivt, men ikke som opfyldelse af krav. Leverandørens besvarelse: Besvarelse pr User Story:

28 BPI Side 28 af 53 US-YYY US-ZZZ Øvrige kommentarer til opfyldelse af kravgrupperingen: <udfyldes af tilbudsgiver> 5.11 Brugere og rettigheder Udarbejdes pt 5.12 Systemadministration Udarbejdes pt

29 BPI Side 29 af 53 6 Ikke funktionelle krav I dette kapitel beskrives de krav der omhandler Læringsplatformens opbygning, integrationer, implementering samt den lovgivning løsningen skal overholde. 6.1 Arkitekturstrategier og principper Kundens Læringsplatform er en central del af kerneprocessen på folkeskolerne i alle kommuner og er en del af Brugerportalinitiativet. Derfor skal Læringsplatformen være med til at understøtte de offentlige strategier, principper og initiativer, der er relevante for Læringsplatformen: Fællesoffentlig digitaliseringsstrategi Fælleskommunal digitaliseringsstrategi 1 Aftalen om Brugerportalinitiativet 2 Den fælleskommunale rammearkitektur 3 Referencearkitektur for Brugerportalsinitiativet 4 Læringsplatformen skal medvirke til at realisere målene for den fælleskommunale rammearkitektur og læringsplatformen skal således følge de fem mål og relevant arkitekturprincipper fra den fælleskommunale referencearkitektur. De fem mål er: 1. Sammenhængende it Kommunens borgere (og medarbejdere) mødes ikke med behovet for genindtastning af data, som allerede er kendte af andre systemer. Systemerne har en datasammenhæng og en dataudvekslingsarkitektur, som skaber sammenhæng mellem it-løsningerne. 2. Genbrug En kommune skal ikke betale fuld pris for den samme funktionalitet to gange, da det skal være let for it-løsninger at benytte og genbruge funktioner eller data i andre (kommuners) it-løsninger. En større del af den fremtidige kommunale systemportefølje bør derfor modulopbygges af fælleskomponenter eller standardkomponenter, som er kompatible. Samtidig skal der sikres en incitamentsstruktur, der gør det attraktivt for leverandørerne at udvikle genbrugelig funktionalitet. 3. Byg til forandring Kommunens it-løsninger skal være lette at tilpasse, når der F.eks. kommer ny lovgivning, der ændrer processen, eller når kommunerne af andre årsager vil forandre opgaveløsningen, så it omkostningerne ikke bliver en bremse på forandring. 4. Flere leverandører Når kommunen baserer sine løsninger på åbne standarder og udskiftelige komponenter, kan de skifte leverandører uden tekniske barrierer. Herudover er der et ønske om et reelt flerleverandørmarked, som sikrer konkurrence og innovation. 5. Driftsstabilitet et.pdf pdf

30 BPI Side 30 af 53 Kommunens it-løsninger skal være driftsstabile, pålidelige, attraktive og sikre, så borgere og medarbejdere kan have tillid til og vil tilslutte sig den digitale opgaveløsning. Understøtte mål for den fælleskommunale rammearkitektur Kategori: Krav Type: Ikke-funktionelt Leverandøren skal redegøre for hvordan og i hvilken grad Læringsplatformen understøtter de fem mål for den fælleskommunale rammearkitektur, herunder også hvor Læringsplatformen fraviger fra målene. Læringsplatformen skal tillige følge udvalgte arkitekturprincipper vedrørende forretning og information, samt applikation og teknologi, der er følgende: B8. Fælles autoritative reference- og grunddata anvendes Beskrivelse fra rammearkitekturen It-løsninger i kommunerne bør anvende fælles autoritative referencedata (F.eks. KLE, FORM mv.) samt grunddata (CPR, CVR, BBR mv.). Konsekvens/betydning for Læringsplatformen Læringsplatformen skal anvende fælles referencedata (F.eks. stamdata om elever fra Uni-Login), hvilket skal ske gennem anvendelse af reference- og grunddata, der bliver udstillet via serviceplatform, integrationsplatform, brugerstyring og administrative systemer. C1. Data udstilles via åbne snitflader og kan genbruges Beskrivelse fra rammearkitekturen Relevante forretningsdata skal stilles til rådighed gennem åbne snitflader, bygget på fælles begrebsmodeller. Konsekvens/betydning for Læringsplatformen Fælles information (data) i brugerportalinitiativet skal kunne deles på tværs af komponenter og anvendes i Læringsplatformen. Det kan F.eks. være elevplanen for en specifik elev, der skal kunne deles mellem forskellige applikationer. C2. Alle data er uafhængige af systemet, hvor de opbevares

31 BPI Side 31 af 53 Beskrivelse fra rammearkitekturen Forekomster af et forretningsobjekt må ikke begrænses af det system, de aktuelt er opbevaret i. F.eks. skal en sag kunne overføres fra en it-løsning til en anden. Det betyder, at forekomster af et forretningsobjekt og dets relationer skal kunne eksporteres og importeres i en ny it-løsning. Konsekvens/betydning for Læringsplatformen Læringsplatformen skal anvende fælles og standardiserede data for alle de forretningsmæssige informationer, der skal deles mellem brugerportalinitiativets løsninger (byggeblokke), nationale og eksterne tjenester. C3. Data identificeres entydigt Beskrivelse fra rammearkitekturen Alle forretningsobjekter bør have én teknisk nøgle, der er uforanderlig. Objektet kan dog samtidig have et ubestemt antal brugervendte nøgler, der skal kunne ændres. Konsekvens/betydning for Læringsplatformen Fælles data i brugerportalinitiativet, herunder i Læringsplatformen skal være identificeret ved global unik identifikation, der er uafhængig af et bestemt system. Tekniske nøgler er globalt unikke. Dvs., at der ikke findes andre objekter med samme id. Brugervendte nøgler er unikke inden for samtlige forekomster af samme objekt. C4. It-løsninger er skalerbare efter formål Beskrivelse fra rammearkitekturen It-løsninger skal være skalerbare. Det vil sjældent være sådan, at it-løsninger opnår deres fulde anvendelse fra dag et, og derfor skal især driften kunne skaleres. Især når itløsninger begynder at genbruge funktioner fra allerede udviklede løsninger på tværs af fagområder, vil der opstå et øget ressourcetræk. Konsekvens/betydning for Læringsplatformen Læringsplatformen, der er målrettet mange samtidige brugere skal være designet til at kunne skaleres i forhold et stort antal brugere og stigende mængder af data. Dette gælder også for driften af disse applikationer. C5. It-løsninger er robuste over for egne og andre systemers nedbrud Beskrivelse fra rammearkitekturen Ved fejl i integrationer skal applikationen kunne fortsætte i de dele, der ikke direkte er relateret til den fejlramte integration. I forlængelse heraf skal der være en høj grad Konsekvens/betydning for brugerportalinitiativet Læringsplatformen skal have en høj robust. F.eks. skal den være designet, så dele, der ikke er direkte relateret til en fejlramte integration kunne fortsætte.

32 BPI Side 32 af 53 af logning/overvågning, således at tegn på nedbrud identificeres tidligt. Afviklingen af Læringsplatformen skal have en høj robusthed, ved at driften bl.a. omfatter overvågning, høj oppetid, dokumentation af applikation, integrationer og driftsmiljøer. Følge principper fra den fælleskommunale rammearkitektur Kategori: Krav Type: Ikke-funktionelt Leverandøren skal beskrive hvordan og i hvilken grad Læringsplatformen følger de seks principper (B8 og C1 til C5) fra den fælleskommunale rammearkitektur, herunder også hvor Læringsplatformen fraviger fra principperne. 6.2 Specifikke arkitekturkrav (to-be målarkitektur) for Læringsplatformen Målarkitektur for Læringsplatformen og dens samspil med øvrige løsninger er vist herunder;

33 BPI Side 33 af 53 De blå pile angiver hvor der vil være data- eller brugergrænseflade-integrationer fra og til Læringsplatformen. De grønne pile angiver hvordan Uni-login vil understøtte singlesign on, når en bruger via Læringsplatform eller Samarbejdsplatform tilgår oplysninger fra Læringsplatformens bagvedliggende systemer. I figuren ovenfor er vist de parter der skal integreres til, både ifm implementering af Læringsplatformen i kommunen, men også i fremtiden når integrationer, standarder og løsninger er klar. Det omfatter: Samarbejdsplatform Forventes idriftsat primo 2018 STIL Integrationsplatform Forventes idriftsat medio 2016 Uni-login løsning for forældre Forventes idriftsat??? Digitale Læremidler Læringsplatformen skal overholde den profilering der endeligt defineres ultimo Overholdelse af denne profilering fra de Digitale Læremidler vil ske løbende herefter, og såfremt et Digitalt Læremiddel ikke overholder profileringen, kan Læringsplatformen ikke kræves at kunne integrere dertil. Beskrivelse af realisering Kategori: Krav Type: Ikke-funktionelt Leverandøren skal beskrive realisering af Læringsplatformen, herunder hvilke komponenter, programmeringssprog og værktøjer, der benyttes, og hvordan de benyttes. Hvor der ikke anvendes standardkomponenter og standard snitflader skal det specifikt argumenteres herfor.

34 BPI Side 34 af 53

35 BPI Side 35 af 53 Skolernes multimodale arbejde Kategori: Krav Type: Ikke-funktionelt Leverandøren skal beskrive hvordan løsningen giver brugerne mulighed for at arbejde multi-modalt (lyd og billede såvel som tekst). Det vægter positivt at løsningen i højest muligt omfang understøtter multimodal kommunikation og arbejde. 6.3 Dataudveksling og integration til andre it-systemer Dette afsnit beskriver krav til dataudveksling og integration til andre it-systemer, der skal anvendes til udveksling af data mellem Læringsplatformen og tilgrænsende kommunale it-systemer og eksterne systemer (se kontekstdiagram i afsnit 4.1). Læringsplatformen skal understøtte følgende integrationer: Samarbejdsplatform STIL Integrationsplatform (og hertil hørende services) Unilog-in Web SSO Unilog-in øvrige services Kommunale systemer indeholdende fraværsoplysninger Andre kommunale it-løsninger Kommunale fildelingsløsninger Digitale læremidler og producenter heraf Biblioteker Export og import af Læringsforløb (mellem Læringsplatforme) Dataudveksling med og integrationer til andre it-systemer skal opbygges efter og følge nogle generelle krav til integrationsmønstret, der skal sikre åben og fri udveksling af information mellem løsninger inden for Brugerportalinitiativet og med eksterne itsystemer. Løs kobling i integrationer Kategori: Krav Type: Ikke-funktionelt Integrationer skal kobles så løst som muligt mellem de itsystemer, der integreres. Herudover skal der anvendes fælles standarder i det omfang, de findes. Understøttelse af gængse integrationsmønstre

36 BPI Side 36 af 53 Kategori: Krav Type: Ikke-funktionelt Der lægges vægt på, at Læringsplatformen er rustet til at understøtte gængse integrationsmønstre som (men ikke begrænset til): Manuel eller automatisk filoverførsel Publish/subscribe Request/Response Kunden vil for hver integration til et andet system have mulighed for at vælge det optimale integrationsmønster, baseret på hvad det andet system tilbyder Dataudveksling og integration til Samarbejdsplatform I forbindelse med at Samarbejdsplatformen er fuldt etableret primo 2018, skal Læringsplatformene udstille en række brugergrænseflader som widgets der kan ses i Samarbejdsplatformen. Læringsplatforme skal derfor pr 1/ kunne udstille som minimum følgende brugergrænseflader som widgets; Liste over Læringsforløb en Elev eller Pædagogisk Personale er i gang med/ ansvarlig for Oversigt over Elevplan for en given elev, varieret efter om Elev/forælder ser den eller Pædagogisk Personale/skoleledelse Oversigt over en elev/klasses samlede Progression ift igangværende Fælles Mål og Læringsmål Denne liste skal suppleres og kvalificeres frem mod endelig kravspecifikation Det vil være op til Læringsplatformen at udstille flere widgets der kan forbedre brugernes oplevelse af Samarbejdsplatform og Læringsplatform, hvilket vil blive vægtet positivt. Teknisk skal widgets være baseret på CSS; HTML5 og javascript, samt understøtte Unilog-in som log-in metode via Samarbejdsplatformen. (Dette krav vil blive uddybet frem mod endelig kravspecifikation) Etablering af integration: XX. Samarbejdsplatform Kategori: Krav Type: Ikke-funktionelt Læringsplatformen skal kunne udstille widgets til Samarbejdsplatformen som beskrevet i afsnit 6.3.1, når denne realiseres