RAPPORT Högskolan i Borås Sigrén, Peter Holmqvist, Hans 2005-01-15 Syntes och analys av tidigare kravspecifikationer för upp- handlingar av LMS inom den svenska högskolan 2000 – 2004 INNEHÅLL SAMMANFATTNING................................................................................3 SUMMARY .................................................................................................4 1 INLEDNING................................................................................................5 1.1 Genomförande................................................................................................................... 5 1.2 Rapportens upplägg........................................................................................................... 5 2 ÖVERGRIPANDE PUNKTER AV TIDIGARE KRAVSPECIFIKATIO- NER; METANIVÅ ......................................................................................7 o Referenser ......................................................................................................................... 7 o Akademiskt fokus ............................................................................................................. 7 o Övriga produkter i sortimentet .......................................................................................... 7 o Tredjepartslösningar.......................................................................................................... 7 o Pedagogiskt synsätt ........................................................................................................... 7 o Inställningar för webbläsare.............................................................................................. 7 o Bandbreddsbegränsning .................................................................................................... 7 o Brandvägg ......................................................................................................................... 7 o Standarder ......................................................................................................................... 7 o Mobila möjligheter............................................................................................................ 7 o Systemkrav........................................................................................................................ 8 o Integration med specifika databaser.................................................................................. 8 o Användbarhet .................................................................................................................... 8 o Metadata............................................................................................................................ 8 3 SYNTES AV TIDIGARE KRAVSPECIFIKATIONER; MIKRONIVÅ ..............................................................................................9 3.1 System............................................................................................................................... 9 3.2 Access och säkerhet .......................................................................................................... 3 3.3 Funktionalitet .................................................................................................................. 14 3.4 Dokumenthantering......................................................................................................... 16 3.5 Användarmiljö ................................................................................................................ 17 3.6 Kommunikation .............................................................................................................. 19 3.7 Utbildning och stöd av systemet ..................................................................................... 21 3.8 Drift av systemet ............................................................................................................. 22 4 KONKLUDERING....................................................................................23 5 REFERENSER...........................................................................................24 WWW-länkar .................................................................................................................. 24 Fotnoter ........................................................................................................................... 25 BILAGA 1..............................................................................................................26 BILAGA 2..............................................................................................................27 APPENDIX Tidigare kravspecifikationer från följande lärosäten: Högskolan i Borås, Chalmers tekniska hög- skola, IT-universitetet i Göteborg, Karlstads universitet, Högskolan i Kristianstad, Luleå tekniska universitet. - 3 - SAMMANFATTNING Högskolan i Borås gavs 2004-11-01 i uppdrag av Myndigheten för Sveriges nätuniversitet att sammanställa och analysera tidigare kravspecifikationer, framtagna av högskolor och universitet, i samband med LMS-upphandlingar (Learning Management System). Material har ställts till för- fogande från Högskolan i Borås, Chalmers tekniska högskola, IT-universitetet i Göteborg, Karl- stads universitet, Högskolan i Kristianstad, Luleå tekniska universitet, Malmö högskola, Umeå universitet samt Uppsala universitet. Målet med rapporten är att underlätta en nationell upphandling av en eller flera utbildningsplatt- formar inom den svenska högskolan och främja ett långvarigt erfarenhetsutbyte, inom den svens- ka högskolesektorn, rörande frågor knutna mot LMS/VLE (Virtual Learning Environment). Rapporten bygger på såväl kravspecifikationer som tidigare använts vid upphandlingar av LMS: s som sådana som är/var tänkta att ligga till grund för en framtida upphandling. Rapporten är ut- formad på ett sådant sätt att det skall vara möjligt att, med relativt små justeringar, använda mate- rialet i ett gemensamt nationellt upphandlingsuppdrag. Det innebär att läsaren får ha en viss för- ståelse för hur framförallt kapitel tre, som är en sammanställning av olika krav, är uppbyggt. En uppdelning har gjorts i ”skall-krav” och i ”bör-krav”. De förstanämnda kraven måste ett system uppfylla för att över huvudtaget bli aktuellt i en upp- handling, de senare är sådana som är önskvärda, men inte direkt tvingande. Vidare har varje krav åsatts ett visst viktningsvärde. Det skall noteras att olika lärosäten kan ha givit samma krav olika vikt, beroende på det enskilda lärosätets prioriteringar. Även om det utförs en syntes så bör det finnas en enkelhet i att på ett effektivt sätt kunna organisera alla variabler som ingår i en sådan syntes därav konstruktionen av ett system med en så kallad ”mall” för ingående variabler. I syntesen har framförallt de senaste årens underlag använts. På grund av den expansiva teknikut- vecklingen finns det ”brister” i de tidigare underlagen. Inte på så sätt att dessa skulle vara under- måliga utan mer anpassade efter den teknik som fanns att tillgå i slutet av 1990-talet och i början av 2000-talet. Det går inte att bortse ifrån att många tidigare ”bör-krav” numera är standard och därmed ett ”skall-krav”. - 4 - SUMMARY The Swedish Netuniversity Agency has asked all universities and university colleges in Sweden their interest in making a central inquiry concerning Learning Management Systems, LMS. One part of such an inquiry will be a list of specifications and demands. The agency has asked University College of Borås to make such a list, based on specifications used by universities in earlier in- quiries. The University College of Borås, Chalmers University of Technology, IT-University of Göte- borg, Karlstad University, University College of Kristianstad, Luleå University of Technology, University College of Malmö, Umeå University and Uppsala University have contributed. This report is a summary and a synthesis of earlier specifications. The specifications are divided in two groups, “skall-krav”, i.e. specifications that are imperative, and “bör-krav”, i.e. specifications that a system ought to fulfil. Every demand has also been given a number, 1-5, based on the im- portance of the demand. In evaluation of different LMS, this figure in combination with a judg- ment of how well the demand is fulfilled could be used. Since development in technology is rapid, more attention has been given to specifications from the last years. Many things that were wanted five years ago today are imperative. - 5 - 1 INLEDNING Högskolan i Borås gavs 2004-11-01 i uppdrag av Myndigheten för Sveriges nätuniversitet att sammanställa och analysera tidigare kravspecifikationer, framtagna av högskolor och universitet, i samband med LMS-upphandlingar (Learning Management System). Material har ställts till för- fogande från Högskolan i Borås, Chalmers tekniska högskola, IT-universitetet i Göteborg, Karl- stads universitet, Högskolan i Kristianstad, Luleå tekniska universitet, Malmö högskola, Umeå Universitet samt Uppsala Universitet. Målet med rapporten är att underlätta en nationell upphandling av en eller flera utbildningsplatt- formar inom den svenska högskolan och främja ett långvarigt erfarenhetsutbyte, inom den svens- ka högskolesektorn, rörande frågor knutna mot LMS/VLE (Virtual Learning Environment), se t.ex. (Brenner & Ericsson, 2003). Ett antal upphandlingar har genomförts under senare år, bland annat av IT-universitetet i Göte- borg (Fronter), Karlstads universitet (It´s learning), Luleå tekniska universitet (Fronter), och Uppsala Universitet (Ping Pong). Det finns således empiri att tillgå rörande hur dessa utvärde- ringar/upphandlingar har skett (se www-länkar under referenser, sid. 24). 1.1 Genomförande Kontakt har tagits med i stort sett samtliga lärosäten för att få uppgift om redan genomförda upp- handlingar och därmed kravspecifikationer, samt sådana planerade upphandlingar och därmed sammanhängande kravspecifikationer. Ur detta material har sedan en syntes gjorts, så att en lista över samtliga krav har gjorts, sammanförda till åtta grupper. En uppdelning i ”skall-krav” och ”bör-krav” har gjorts och varje krav har försetts med en viktningskoefficient. Den senare är en sammanvägning av viktningar gjorda i olika kravspecifikationer, men överensstämmelsen mellan kravspecifikationerna är relativt hög, varför en avvikelse på en, högst två enheter kan finnas i något fall. 1.2 Rapportens upplägg Tekniken har hunnit långt i en jämförelse med de tidigaste underlagen från slutet av 1990 talet med de senare från 2004. Kravspecifikationer ställs m.a.o. utifrån differentierade förutsättningar. Ett bra exempel på denna differentiering är videokonferenssystemens utveckling under de senaste fem åren (Furht, 1999). Systemen för bildöverföring är betydligt mer sofistikerade idag i en jäm- förelse med tidigare och därigenom är det möjligt att bli än mer flexibel för högskolor i sitt ut- bildningsutbud. Kapitel två innehåller en del övergripande punkter (metanivå) som lärosäten diskuterat. Dessa mer övergripande punkter bryts ned på en mikronivå i syntesen som då utförs under kapitel tre. - 6 - Denna syntes mynnar ut i följande åtta övergripande områden där vi försökt att greppa variatio- nen hos lärosätena. System Access och säkerhet Funktionalitet Dokumenthantering Användarmiljö Kommunikation Drift av systemet Utbildning och stöd av systemet I kapitel fyra förs en kort diskussion kring vad som framkommit i syntesen. Några slutsatser dras, andra kan skönjas, sett ur ett teknologiskt framtidsperspektiv. Relativt klart är dock att framtidens virtuella utbildningssystem kommer att ställa fortsatt höga krav på systemutvecklare. Rapporten avslutas med två bilagor där förslag ges på hur en upphandling kan se ut. Bilagorna redovisar upphandlingsmallar, utvärderingsförslag samt en analysmetod för en utvärdering av ett upphandlingsförfarande. Till rapporten finns även ett appendix. I appendixet kan de ingående lärosätenas kravspecifikatio- ner analyseras mer ingående. Tillsammans med URL-länkarna (sid. 24.) är det möjligt, för den intresserade, att kunna fördjupa sig ytterligare. - 7 - 2 ÖVERGRIPANDE PUNKTER AV TIDIGARE KRAVSPECIFIKA- TIONER; METANIVÅ Nedanstående punkter är sådana som har diskuterats hos lärosäten inför upphandlingar. Vi väljer att inte visa på någon variation utan sammanfattar dessa under 14 punkter. De flesta av dessa återkommer när syntesen redovisas i kapitel 3, men det torde ändå finnas en poäng i att visa på dessa mer övergripande variabler innan de bryts ned till en mikronivå i kapitel 3. Det ger en bra överblick av vad som anses vara viktiga faktorer i ett framtida LMS. • Referenser Ange referenser för organisationer, företrädesvis universitet och högskolor, där systemet används. Referenserna skall vara möjliga att kontakta för ytterligare frågor. Det skall vara möjligt, genom dessa referenser, erhålla exempel på hur systemet har fungerat och funge- rar vid minst 1 000 lärare och 6-10 000 studenter registrerade. • Akademiskt fokus Är systemet byggt för att implementeras i akademiska organisationer? Redovisa i så fall hur systemet har designats utifrån tidigare diskurs, (se kapitel 2). • Övriga produkter i sortimentet Beskriv vilka andra produkter, för utbildningsändamål, företaget kan tillhandahålla. • Tredjepartslösningar Ange hur samarbetet med eventuella tredjepartsleverantörer ser ut. Det är specifikt viktigt att reda ut hur licensavtalen är formulerade. • Pedagogiskt synsätt Beskriv det pedagogiska koncept som varit framträdande vid designen av systemet, t.ex. arkitektur, funktionalitet och interface. • Inställningar för webbläsare Beskriv om systemet behöver specifika inställningar för webbläsaren på klienten. T.ex. är denna aspekt viktig om Java-applikationer används. • Bandbreddsbegränsning Vilka rekommendationer ges rörande minimal bandbredd för att kunna köra systemet ef- fektivt. Systemet bör inte ta mer än 100 % (genomsnittligt) längre tid i jämförelse med ett LAN vid körning på campus. • Brandvägg Klargör om det finns ytterligare portar (port 80 undantaget) som används för kommunika- tion genom brandvägg. Om det finns, ange vilken typ av kommunikation som avses. • Standarder Klargör vilka standarder som systemet är kompatibelt med. T.ex. LDAP, IMS, AICC, SCORM, iCAL, vCAL. Ange även vilka versioner som kan användas. Ange även stöd för databashantering. T.ex. XML, SQL, osv. • Mobila möjligheter Ange om det finns möjlighet att arbeta med systemet genom pda´s och mobiltelefon. - 8 - • Systemkrav Ange vilka krav som ställs på systemets servrar. T.ex. operativsystemet, RAM, hårddis- kar, processorer, databaser, mjukvara och eventuella tredjepartsmjukvaror. • Integration med specifika databaser Ange hur integrationen fungerar (genom referenser) med databaser som t.ex. Ladok, Ne- verLost och andra liknande administrativa datasystem för högskolor. • Användbarhet Beskriv den metodologi och strategi som använts för att ge en bra anpassning till syste- mets olika delar. T.ex. möjlighet till virtuellt samarbete mellan deltagare. • Metadata Ange hur systemet arbetar med metadata. - 9 - 3 SYNTES AV TIDIGARE KRAVSPECIFIKATIONER; MIKRONIVÅ Syntesen av tidigare kravspecifikationer har utmynnat i åtta övergripande områden, med ett 100- tal undergrupper (variabler) av aspekter på ett LMS. Dessa åtta områden är följande: System; Access och säkerhet; Funktionalitet; Dokumenthantering; Användarmiljö; Kommunikation; Ut- bildning och stöd av systemet; samt Drift av systemet. Det finns såväl skall-krav som måste uppfyllas (vikt 5)1 samt bör-krav som helst bör uppfyllas (vikt 1-4). Det finns en naturlig variation mellan olika lärosätens syn på hur viktigt ett krav upp- fattats. Ett försök görs här, att visa på denna variation. Som det nämnts tidigare hålls en viss struktur i kravspecifikationen med tanke på att den eventuellt skall återanvändas i ett upphand- lingsförfarande. Ett förslag på en sådan mall, har arbetats fram inom ramen för rapporten, se bila- ga 1, sid. 26. 3.1 System 3.1.1 LMS Systemet skall vara fullt webbaserat. Plug-ins och Java applet kan accepteras i specifika verktyg, men inte generellt. Krav: Skall Vikt: 5 Kommentar: Detta är ett generellt krav. 3.1.2 Java Om Java-applet används i något avseende skall syftet klargöras (i bilaga) samt vilken version av Java som krävs. Krav: Skall Vikt: 5 Kommentar: Ett krav framförallt från tekniska högskolor/universitet. 3.1.3 Java; HTML Java applet i HTML-sidor som importeras eller skapas i systemet bör stödjas. Krav: Bör Vikt: 3 Kommentar: Detta är ett önskemål från flera. 3.1.4 Webbläsare Systemet skall vara kompatibelt med Netscape Navigator 7.0 eller högre samt Internet Explorer 6.0 eller högre. Krav: Skall Vikt: 5 Kommentar: Önskemål om webbläsare Mozilla, version 1.4 eller högre finns. Anm. Mozilla körs när Linux används. 3.1.5 Handikappanpassat De riktlinjer som ställs i W3C: s "Web Content Accessibility Guidlines bör uppfyllas". Krav: Bör Vikt: 4 Kommentar: Hänvisning till denna URL har gjorts: www.w3.org/consortium - 10 - 3.1.6 Standarder Systemet skall följa den utveckling av standarder som sker. Krav: Skall Vikt: 5 Kommentar: Exempel på standarder som givits är t.ex. SCORM; IMS; OKI 3.1.7 Operativsystem Klienten skall vara kompatibel med följande operativsystem: Windows 98 eller högre; MacOS X; Krav: Skall Vikt: 5 Kommentar: Detta är ett generellt krav. 3.1.8 Operativsystem; Linux; Unix Klienten bör vara kompatibelt med följande operativsystem: Linux; Unix Krav: Bör Vikt: 4 Kommentar: Önskemål framförallt från tekniska högskolor/universitet. 3.1.9 Skärmupplösning; 800 * 600 Systemet skall vara kompatibelt med upplösningen 800 * 600. Det skall vara möjligt att navigera i denna upplösning utan att behöva skrolla horisontellt. Krav: Skall Vikt: 5 Kommentar: Detta är ett generellt krav. 3.1.10 Källkod Det bör vara möjligt att erhålla access till dokumentation ang. systemets källkod. Krav: Bör Vikt: 4 Kommentar: Önskemål framförallt från tekniska högskolor/universitet. 3.1.11 Brandväggar Det bör inte användas någon form av kommunikation som inte följer standardiserad webbkommunikation genom brandväggar (port 80 undantaget). Krav: Bör Vikt: 2 Kommentar: Generellt önskemål. 3.1.12 Virusskydd Systemet bör ha någon form av integrerad programvara för virusskydd. Krav: Bör Vikt: 2 Kommentar: Några anger detta. 3.1.13 Design av gränssnitt Grafisk presentation i systemet bör kunna ändras av systemadministratör. T.ex. logga för högskola eller universitet. Krav: Bör Vikt: 4 Kommentar: Ett flertal vill ha denna funktion. - 11 - 3.1.14 Navigering Det bör vara möjligt att använda webbläsarens kommandoknappar för navigering framåt och bakåt. Avser om systemet har en annan standard för visning av kurser. Krav: Bör Vikt: 1 Kommentar: En teknisk högskola har angett detta. 3.1.15 Trädstruktur Det skall vara möjligt att kursmappar kan visas i s.k. trädstruktur om annan standard används. Avser om systemet har en annan standard för visning av kurser. Krav: Skall Vikt: 5 Kommentar: Generellt krav. 3.1.16 Trädstruktur; långa namn Det skall vara möjligt att använda långa kurs- och filnamn. Krav: Bör Vikt: 3 Kommentar: Det torde inte vara ett problem men det nämns av fler än ett lärosäte. 3.1.17 Gästkonto Gästkonto till vissa delar av systemet bör finnas. Krav: Bör Vikt: 4 Kommentar: Generell önskemål. Dock ej som ett skall-krav. 3.1.18 Starthjälp Dokumentation och hjälpfunktion, att kunna komma igång, skall finnas att tillgå i systemet. Krav: Skall Vikt: 5 Kommentar: Språk: Engelska eller svenska anger de flesta. Dock inte krav på svenska hos alla. 3.1.19 Integration till studentadministrativa system Det skall finnas möjlighet till integration med t.ex. LADOK. Krav: Skall Vikt: 5 Kommentar: Generellt krav. Referenser till vilka studentadministrativa system som stöds efterfrågas. 3.1.20 Integration till studentadministrativa system Det bör finns möjlighet till integration med schemaläggningssystem Det bör finns möjlighet till integration med Novellsystem och liknande system t.ex. Novell GroupWise. Det bör finnas en möjlighet att, genom automatik, synkronisera en specifik student till de kurser denna skall gå. Krav: Bör Vikt: 3 - 4 Kommentar: Referenser och vilka sådana system som stöds t.ex. NeverLost efterfrågas. - 12 - 3.1.21 Databaser Det bör vara möjligt med integration av och mot databaser. Krav: Bör Vikt: 5 Kommentar: Vilken typ av databashantering systemet stödjer efterfrågas. 3.1.22 Belastning; åtkomsttider Ange hur åtkomsttider ser ut när systemet belastas med många användare samtidigt. T.ex. 1000, 2000, 3000 studenter osv. Krav: Skall Vikt: 5 Kommentar: De flesta anger någon form av belastningsuppgifter. 3.1.23 Sökmotor Systemet bör innehålla någon slags sökmotor. Krav: Bör Vikt: 4 Kommentar: Sökning på kursnamn, kursinnehåll, användare är vad som efterfrågas. 3.1.24 Sökmotor; metadata Det bör finnas möjlighet till sökning av metadata. Krav: Bör Vikt: 2 Kommentar: Metadata är ett återkommande begrepp. 3.1.25 Bibliotek Det bör finnas en koppling mot högskolors/universitets biblioteksresurser. Krav: Bör Vikt: 2 Kommentar: Efterfrågas framförallt i de senare daterade underlagen. - 13 - 3.2 Access och säkerhet 3.2.1 Säkerhet Det skall vara möjligt att organisera och dela ut rättigheter i systemet av systemadmin, (en traditionell nätverksstruktur). Vem har rätt att göra vad i kurser, mappar, chattar osv. Det skall finnas en nivå: systemadmin; samt en nivå; kursadmin. Krav: Skall Vikt: 5 Kommentar: Detta är ett generellt krav. 3.2.2 Säkerhet, ägare Det skall vara möjligt att ändra ägandet av mappar osv. Vad som avses är att det skall gå att ändra oavsett vem som skapat kurs/mapp osv. Krav: Skall Vikt: 5 Kommentar: Detta är ett generellt krav. 3.2.3 Säkerhetskopiering Det skall finnas rutiner för backup av systemet. Krav: Skall Vikt: 5 Kommentar: Detta är ett generellt krav. T.ex. ange utförligt (i bilaga) vilken standard som följs. 3.2.4 Säkerhet, kryptering Systemet skall använda en hög kryptering av data (128 bit SSL) vid integrering med personal- och studentadministrativa system. Krav: Skall Vikt: 5 Kommentar: Detta är ett generellt krav. 3.2.5 Säkerhet, uppgradering Det skall finnas rutiner för hur uppgradering av systemet sker. Krav: Skall Vikt: 5 Kommentar: Detta är ett generellt krav. 3.2.6 Belastning Det bör finnas möjlighet att grafiskt se hur systemet belastas vid givna tidpunkter. Vad som avses är att möjligheten bör finnas för systemansvarig. Krav: Bör Vikt: 2 Kommentar: Önskemål framförallt från tekniska högskolor och universitet. - 14 - 3.3 Funktionalitet 3.3.1 Kalender Kalender skall finnas. Krav: Skall Vikt: 5 Kommentar: Detta är ett generellt krav. 3.3.2 Kalender; generellt Kalender bör vara redigerbar för student. Det bör vara möjligt att ställa kalendern i visningsläge vecka, åtminstone på individnivå och gruppnivå. Det bör finnas möjlighet att importera och exportera kalenderinnehåll. T.ex. till iCalender- och vCalenderformat. Det bör vara möjligt att repetera återkommande schema. T.ex. lektioner som återkommer repetitivt veckodag - tidpunkt. Det bör vara möjligt att ställa kalendern i påminnelseläge. T.ex. pop-up vid inloggning där de närmaste uppgifterna visas. Det bör vara möjligt att länka i kalendern till specifika dokument. T.ex. PowerPoint presentationer, kursmaterial osv. Krav: Bör Vikt: 2 - 4 Kommentar: Vikten avser variationen i dessa exempel på bör-krav, som ställts, inom kalenderfunktionen. 3.3.3 Frågedatabas Det skall finnas verktyg för frågedatabaser. Krav: Skall Vikt: 5 Kommentar: Generellt krav. Extern programvara kan accepteras. 3.3.4 Frågedatabas; generellt Det skall vara möjligt att styra frågeformulär med start- respektive stopptid. Det skall vara möjligt för lärare att skriva ut svaren på en sida. Krav: Skall Vikt: 5 Kommentar: Detta är ett generellt krav. 3.3.5 Frågedatabas; generellt Det bör vara möjligt att importera egna frågor till befintlig databas. Det bör vara möjligt för studenter att öva sig på frågor från en speciell övningsdatabas. Det bör vara möjligt att sätta en vikt (poäng) på frågorna. Det bör vara möjligt att avge ett svar anonymt. Det bör vara möjligt för lärare att kommentera svar. Frågor bör kunna slumpas ut från en databas. Krav: Bör Vikt: 2 - 3 Kommentar: Vikten avser variationen i dessa exempel på bör-krav, som ställts, ang. frågedatabas. 3.3.6 Betygsbok Betygsbok bör finnas. Krav: Bör Vikt: 3 Kommentar: Inget generellt krav på betygsbok. - 15 - 3.3.7 Enkäter, utvärdering Det skall finnas möjlighet att skapa utvärderingsenkäter Krav: Skall Vikt: 5 Kommentar: Såväl med multiple choicefrågor som öppna svarsalternativ anges som krav. 3.3.8 Portfolio Portfolio skall finnas. Krav: Skall Vikt: 5 Kommentar: Detta är ett generellt krav. 3.3.9 Porfolio; generellt Det bör vara möjligt att importera och exportera filer från portfolion för både lärare och student. Det bör vara möjligt att sända redovisningar från portfolion genom datumstyrning. Möjlighet att lägga upp ett CV. Krav: Bör Vikt: 3 - 4 Kommentar: Generellt önskemål. 3.3.10 Examination Det bör finnas ett verktyg för en enkel leverans av examinationsuppgifter till lärare. Krav: Bör Vikt: 4 Kommentar: Någon anger t.ex. drag and drop-system. Gärna i anslutning till portfolion. 3.3.11 Statistik Det skall finnas någon typ av statistikfunktion i systemet. Krav: Skall Vikt: 5 Kommentar: Detta är ett generellt krav. 3.3.12 Statistik; generellt Det bör finnas möjlighet att exportera det statistiska materialet. Det bör vara möjligt att presentera statistik såväl på individ- som gruppnivå. Det bör vara möjligt för lärare att se hur en student har loggat in i kursen, mappar och filer. Krav: Bör Vikt: 3 - 4 Kommentar: Vikten avser variationen i dessa exempel på bör-krav, som ställts, ang. statistikfunktion. 3.3.13 Filhantering; generellt Det bör vara möjligt att konvertera filer till andra filformat. T.ex., .doc till .pdf; .psd till .jpg. Det bör inte finnas någon begränsning i filstorlekar. Det bör finnas möjlighet att dra in filer och lägga i mappar. Krav: Bör Vikt: 4 Kommentar: Generellt önskemål. - 16 - 3.3.14 Peer Review Systemet bör ge möjlighet till att studenter och lärare kan ge kommentarer i texter. Krav: Bör Vikt: 2 Kommentar: Önskemål från flera. 3.3.15 Kurser Det skall finnas möjlighet att packa ned och upp kursstrukturer. Krav: Skall Vikt: 5 Kommentar: Vilka standarder som stöds efterfrågas t.ex. SCORM, IMS och AIC. 3.4 Dokumenthantering 3.4.1 Dokumenthantering Dokumenthanteringsfunktion skall finnas. Krav: Skall Vikt: 5 Kommentar: Detta krav ställs generellt. 3.4.2 Dokumenthantering, generellt Stöd för delade dokument skall finnas. Dokumenthanteraren skall stödja olika filformat. Det skall vara möjligt att bestämma när dokument skall tas bort eller läggas till. Dokumenthantering i realtid skall finnas. Dokument skall kunna skrivas ut oberoende av filformat. Det skall kunna ske såväl import som export av dokument. Det skall gå att öppna dokument i såväl extern som intern miljö. Krav: Skall Vikt: 5 Kommentar: Dessa krav ställs generellt. 3.4.3 Dokument; HTML Det bör inte finnas några begränsningar av import av HTML dokument. Krav: Bör Vikt: 4 Kommentar: Önskemål från flera. - 17 - 3.5 Användarmiljö 3.5.1 Språk; Svenska; Engelska Svenska eller engelska skall finnas som menyspråk. Krav: Skall Vikt: 5 Kommentar: 3.5.2 Språk; personlig profil Menyspråk bör kunna ändras beroende på inställd personlig profil. Även om menyn är på engelska skall systemet kunna stödja svenska tecken som t.ex. å, ä, ö. Krav: Bör Vikt: 2 Kommentar: Generellt önskemål. 3.5.3 Svenskt tidsformat Det skall vara möjligt att använda svenskt tidsformat (GMT + 1). Krav: Skall Vikt: 5 Kommentar: Detta är ett generellt krav. 3.5.4 Portalsida; generellt Den första sida vid inloggning bör vara en portalsida. Det bör vara möjligt att gå direkt till sin "egen kursportal" från portalsidan. Det bör finnas flaggning för nytt material på portalsidan. Krav: Bör Vikt: 3 - 4 Kommentar: Vikten avser variationen i dessa exempel på bör-krav, som ställts, ang. portalsida. 3.5.5 Personliga uppgifter Användare bör kunna ändra egna personliga uppgifter. Krav: Bör Vikt: 4 Kommentar: Önskemål från flera. 3.5.6 Länkning; generellt Det skall finnas verktyg för att skapa länkning mellan t.ex. schema och dokument i systemet. Det skall finnas verktyg för att skapa länkning till t.ex. extern URL. Krav: Skall Vikt: 5 Kommentar: Generella krav. 3.5.7 HTML-editor Det bör finnas en HTML editor. Krav: Bör Vikt: 3 Kommentar: Önskemål från flera. - 18 - 3.5.8 Dynamisk webbhantering Det bör finnas en WYSIWYG-editor inkluderat i den generella editorn. Systemet bör ha ett verktyg för visning av mediafiler. Det bör finnas ett verktyg för att skapa och editera mer avancerade matematiska formler. Krav: Bör Vikt: 2 - 4 Kommentar: Vikten avser variationen i dessa exempel på bör-krav, som ställts, ang. dynamisk webbhantering. 3.5.9 Bilder Bilder skall kunna läggas in i systemet. Krav: Skall Vikt: 5 Kommentar: Generellt krav. 3.5.10 Bildkonferens Det bör finnas integrering med t.ex. Marratech eller Netmeeting. Ange om extern programvara behövs; eventuell licenskostnad. Krav: Bör 3 Vikt: Kommentar: Önskemål från flera. 3.5.11 Streamingfunktion Möjlighet att länka till en streamingserver bör finnas. Krav: Bör Vikt: 3 Kommentar: Önskemål från flera. 3.5.12 Ljudkonferens Möjlighet till ljudkonferens bör finnas. Krav: Bör Vikt: 3 Kommentar: Önskemål från flera. 3.5.13 Inspelningar; ljud Det bör vara möjligt att lägga ut ljudfiler för nedladdning. T.ex. i filformat wave, mp3. Krav: Bör Vikt: 2 Kommentar: Önskemål från flera. 3.5.14 Språkgranskning Systemet bör innehålla ett verktyg för språkgranskning. Vilka språk verktyget stödjer efterfrågas. Krav: Bör Vikt: 2 Kommentar: 3.5.15 Bandbredd Systemet skall kunna köras över ett modem. Ange lägsta modemhastighet. Krav: Skall Vikt: 5 Kommentar: De flesta anger krav på möjlighet med modemuppkoppling. - 19 - 3.6 Kommunikation 3.6.1 Vem är inloggad Systemet skall visa vilka som är inloggade. Krav: Skall Vikt: 5 Kommentar: Generellt krav. 3.6.2 Diskussionsforum Det skall finnas diskussionsforum Krav: Skall Vikt: 5 Kommentar: Generellt krav. 3.6.3 Diskussionsforum; generellt Lärare skall kunna ges möjlighet till att ge access till fora. Det skall finnas möjlighet till en s.k. trådad diskussion. Användare skall ha möjlighet att starta egna diskussionsforum och dela ut rättigheter till dessa. Krav: Skall Vikt: 5 Kommentar: Övergripande krav. 3.6.4 Diskussionsforum; generellt Det bör vara en acceptabel hastighet i diskussionsforumet. Det bör vara överskådligt utan att behöva skrolla horisontellt. Nya inlägg bör flaggas. Det bör vara möjligt att skriva ut diskussioner. Det bör vara möjligt att se vilka som läst inlägget. Det bör vara möjligt att svara en specifik deltagare i diskussionen. Det bör vara möjligt att spara en påbörjad session. Krav: Bör Vikt: 1 - 4 Kommentar: Vikten avser variationen i dessa exempel på bör-krav, som ställts, ang. diskussionsforum 3.6.5 Chatt Systemet skall tillhandahålla möjlighet för synkron kommunikation. Krav: Skall Vikt: 5 Kommentar: Generellt krav. - 20 - 3.6.6 Chatt; generellt Det bör vara möjligt att använda chatt-funktionen utan användning av Java applet. Det bör vara möjligt att använda funktionen utan konfigurering via brandvägg. Chatt-funktionen bör ha en viskningsfunktion. Det bör finnas möjlighet att spara en chatt. Det bör finnas möjlighet för lärare eller moderator att utesluta personer under pågående chatt. Det bör vara möjligt för studenter att lägga upp ett chatt-forum. Krav: Bör Vikt: 2 - 4 Kommentar: Vikten avser variationen i dessa exempel på bör-krav, som ställts, ang. chatt-funktion. 3.6.7 Anslagstavla (whiteboard) Systemet skall ha en anslagstavla för synkront informationsutbyte. Dock kan extern program accepteras om integration finns med systemet. Krav: Skall Vikt: 5 Kommentar: Generellt krav. 3.6.8 Anslagstavla; generellt Det skall vara möjligt att stänga av deltagare från anslagstavlan. Det skall vara möjligt att använda anslagstavlan utan konfigurering via brandvägg. Dock kan extern program accepteras om integration finns med systemet. Krav: Skall Vikt: 5 Kommentar: Övergripande krav. 3.6.9 Anslagstavla; generellt Det bör finnas möjlighet till verktyg för att producera bildmaterial. Det bör vara möjligt att spara det som visas på anslagstavlan. Det bör finnas en textbaserad chatt-funktion i anslagstavlan. Krav: Bör Vikt: 2 - 4 Kommentar: Vikten avser variationen i dessa exempel på bör-krav, som ställts, ang. whiteboard. 3.6.10 E-post E-post skall kunna hanteras såväl internt som externt Krav: Skall Vikt: 5 Kommentar: Generellt krav. 3.611 E-postlistor Det bör inte finnas några begränsningar i e-postlistor. Det bör vara möjligt att skapa egna e-postlistor. Krav: Bör Vikt: 2 Kommentar: Önskemål från flera. - 21 - 3.6.12 SMS Det bör finnas möjlighet att sända SMS till en grupp av användare. Det bör vara möjligt att stänga av SMS-funktionen för användare. Krav: Bör Vikt: 1 - 2 Kommentar: Önskemål framförallt från tekniska högskolor/universitet. 3.6.13 PDA Det bör finnas möjlighet att ansluta en PDA (handdator) på ett smidigt sätt i systemet. T.ex. genom trådlös överföring. Krav: Bör Vikt: 1 - 2 Kommentar: Önskemål framförallt från tekniska högskolor/universitet. 3.6.14 FAQ Det bör finnas möjlighet att ställa och besvara frågor som samlas i en FAQ. Krav: Bör Vikt: 2 - 3 Kommentar: Önskemål från flera. 3.7 Utbildning och stöd av systemet 3.7.1 Stöd Anbudsgivaren skall kunna tillhandahålla mer innehållsberoende stöd. T.ex. en fysisk person att tala med efterfrågas Krav: Skall Vikt: 5 Kommentar: Generellt krav. . 3.7.2 Utbildning Anbudsgivaren skall kunna tillhandahålla utbildning för såväl lärare som administratörer. Anbudsgivaren skall kunna ge utbildning i systemets användargränssnitt. Krav: Skall Vikt: 5 Kommentar: Generellt krav. 3.7.3 Dokumentation Anbudsgivaren skall kunna tillhandahålla fullständig dokumentation av systemet. Krav: Skall Vikt: 5 Kommentar: Generellt krav. 3.7.4 Implementerande Återförsäljaren av systemet skall ha resurser och kompetens att sörja för en god implementering. Krav: Skall Vikt: 5 Kommentar: Generellt krav. - 22 - 3.8 Drift av systemet 3.8.1 Drift; server på högskola/universitet Ange en kostnadsmodell, i bilaga, för drift på respektive högskola/universitet. Krav: Skall Vikt: 5 Kommentar: Generellt krav. 3.8.2 Drift; server på högskola/universitet Antal samtida användare, licenser, krav på servrar, databashanterare, uppdateringar, säkerhetskopiering, support och behörighetskontrollsystem. Viktigt är att ange vilka tredjepartslösningar som eventuellt måste tillföras. Krav: Skall Vikt: 5 Kommentar: Generellt krav. 3.8.3 Drift; server hos leverantör Ange en kostnadsmodell, i bilaga, för drift hos leverantör. Krav: Skall Vikt: 5 Kommentar: Generellt krav. 3.8.4 Drift; server hos leverantör Antal samtida användare, licenser, krav på servrar, databashanterare, uppdateringar, säkerhetskopiering, support och behörighetskontrollsystem. Viktigt är att ange vilka tredjepartslösningar som eventuellt måste tillföras. Krav: Skall Vikt: 5 Kommentar: Generellt krav. - 23 - 4 KONKLUDERING Utifrån föreliggande rapport kan konstateras att mycket har hänt ifrån det första upphandlingsun- derlaget från i slutet av 1990-talet tills de senare daterade 2004. Det är framförallt krav på fler möjligheter till ett bättre samarbete mellan studenter som är honnörsord 2004 (Sigrén, 2003). Bibliotekens roll är mer framträdande samt möjlighet till integrering av databaser och där spelar biblioteken en viktig roll. Det går även att påvisa önskemål om bättre förutsättningar för audiovi- suellt material. Ett exempel på detta är inspelade föreläsningar som streamas ut, liksom inspelade svar på examinationer t.ex. ljudfiler, fler möjligheter för studenter att använda sig av webbkonfe- renser inom ett LMS. Användandet av s.k. iCalender- och vCalenderformat är på framåtgående samt PDA. Eftersom dessa handdatorer blir mindre, smidigare och att användningsområdena ökar är inte dessa krav förvånande (Abbott, 2001; Moore & Koble, 1995; Race, 2000). En slutsats blir således att såväl en utveckling av den pedagogiska som den teknologiska kontex- ten har varit kumulativ men tenderar att öka betydligt snabbare med de nya system som finns på marknaden. På något längre sikt kan det skymtas att mobiltelefoner kan komma att få ett bredare användningsområde t.ex. inom utbildningssektorn. Troligtvis kommer det fler telefoner, med avancerade system för kalenderfunktion och överföringsmöjligheter av textmaterial och inte minst videokonferenser. Dessa kommer troligtvis även att kunna sammanlänkas med ett LMS genom t.ex. BluetoothTM som då möjliggör en enklare överföring av utbildningsmaterial. Open Source Software nämns ofta som ett alternativ (Brenner & Ericsson, 2003). Det framgår även att några lärosäten har diskuterat sådana lösningar i sina underlag. Det är självklart att sam- ma krav skall ställas på en Open Source-lösning på som på ett kommersiellt system Det är också uppenbart att den kravspecifikation vi i denna rapport presenterar är baserad på idag känd teknik. Den får därför betraktas som färskvara och som en nulägesbeskrivning. Det har inte legat inom ramen för uppdraget att ha ett mera visionärt arbetssätt. Som sagt, teknik daterad anno 2004 är, som den egentligen alltid varit, en färskvara. Skillnaden nu mot förr är att hastigheten i denna utveckling, av färskvaran, är svindlande. Med dessa blickar framåt överlämnar vi härmed vår rapport och anser därigenom uppdraget slutfört. Högskolan i Borås den 15 januari 2005 Peter Sigrén Hans Holmqvist - 24 - 5 REFERENSER Abbott, C. (2001). ICT : changing education. London: Routledge Falmer. Brenner, M., & Ericsson, J. (2003). Lärplattformskonferens, 2004, from World Wide Web, http://www.hig.se/learningcenter/erfbank/erfbank.html Collis, B., & Moonen, J. (2001). Flexible learning in a digital world : experiences and expecta- tions. London: Kogan Page. Furht, B. (1999). Handbook of Internet and multimedia systems and applications. Boca Raton, Fla.: CRC Press. Moore, M. G., & Koble, M. A. (1995). Video-based telecommunications in distance education. University Park, Pa.: American Center for the Study of Distance Education. Race, P. (2000). Moving from Traditional Teaching to Flexible Learning. In L. Hall & M. Ryan (Eds.), Flexible Learning and ICT. London: Greenwich University Press. Sigrén, P. (2003). Open Distance Learning in Higher Educational System : A Technological Ap- proach Within a Social Constructivistic Perspective. Paper presented at the International Con- ference on Education and Information Systems: Technologies and Applications., EISTA ´03., Orlando, FL, USA, p.p. 299-304. WWW-LÄNKAR Chalmers tekniska högskola www.ckk.chalmers.se/cselt/cselt/fas2/larplattform.html Högskolan i Gävle www.ckk.chalmers.se/cselt/cselt/fas2/pdf/iktlokaler/tekniskaplattformar.pdf IT-universitetet i Göteborg www.ituniv.se/news_archive.php?focus=81 Karlstads universitet www.kau.se/corral/intra.lasso?page_id=346 Luleå tekniska universitet www.online.luth.se/projekt/LMS/ Malmö högskola www.mah.se/upload/20050/plattformsrapport.pdf Uppsala Universitet www.uadm.uu.se/it-telefoni/wbl/ Umeå Universitet www.pingpong.umu.se/utbildning_admin.htm Viktoriainstitutet www.viktoria.se Web Content Accessibility Guidelines www.w3.org.consortium - 25 - FOTNOTER 1 En för stor fokusering vid ”vikten” bör inte göras. Ingående lärosäten har ett differentierat synsätt på vikt. En del har valt en skala om 1-5 andra 1-2, 1-3 eller uppfyllt respektive ej upp- fyllt. Vi har valt att använda oss av en vikt om 5 för ett skall-krav samt 1-4 som en varians i bör-kraven. Vi tror oss ligga nära ”sanningen” genom detta förfarande. - 26 - BILAGA 1 Figur 1 visar på ett förslag över hur en mall kan se ut vid ett eventuellt upphandlingsförfarande. Anbudsgivaren ges möjlighet att, på ett relativt enkelt sätt, ange om denne uppfyller ett skall-krav samt hur denne klarar ett bör-krav. Fältet för svarsalternativ ”JA” fylls i om skall-kravet uppfylls. Uppfylls inte kravet lämnas cellen/rutan tom. Skall-kravet representerar en vikt om 5. Bör-kravet representerar en vikt mellan 1 och 4 i hela tal. Viktpoängen räknas fram av utvärderingsgruppen. Hur viktpoängen skall räknas fram diskuteras inte i denna rapport men ett förslag kan vara att använda sig av en metod som benämns ”minirisk”. I denna analys kan en skala användas om 1-5, där denna skala representerar hur väl kravet uppfyllts. Denna ”poäng” kan sedan multipliceras med vikten och därigenom erhålls vikt- poängen för respektive variabel (se mer utförligt i bilaga 2 sid. 28). Figur 1 Exempel på ett skall samt bör-krav - 27 - BILAGA 2 Utvärderingsförslag, avser en kravspecifikation för ett LMS Användbarhet I utvärderingen bör fokus vara på systemets effektivitet mot student, lärare, administratörer och IT-personal. Systemet bör även valideras mot såväl lärandemiljöer på campus som på distans. Det är viktigt att ett Virtual Learning Environment stöds på ett effektivt sätt. Den flexibla utbildning- en är ett av flera incitament i högskolors sätt att se på utbildning (Collis & Moonen, 2001) Funktionalitet I utvärderingen bör stor vikt läggas vid skall-kraven som måste vara uppfyllda. Naturligtvis finns det förståelse för att det förekommer många slags administrativa system runt om på rikets hög- skolor. Det är dock av stor vikt att högskolors databaser går att knyta mot systemet t.ex. Ladok och andra liknade studentadministrativa system. Kostnad Utvärderingen av kostnader bör baseras på kostnader för licens, installation, utbildning, integra- tion med andra IT-system, hårdvara och drift av systemet. Vi ser helst att anbudsgivaren ger en totalkostnad som inkluderar även tredjepartslösningar. M.a.o. anbudsgivaren är den part använda- ren av systemet skall kunna vända sig till även rörande tredjepartslösningar. En viktig fråga i sammanhanget är, t.ex. i specifika fall som en tredjepartslösning innebär, att vid användande av en sådan programvara bör licensfrågan vara löst? T.ex. om en integration sker med Marratech´s webbkonferenssystem eller andra liknande system (NetMeeting) så bör antal ”rum” vara om inte obegränsade så tillräckligt många för att kunna stödja kollaborativa pedagogiska modeller för lärande. Organisatoriskt Utvärderingen av denna variabel bör koncentreras mot hur ett LMS kommer att kunna utvecklas i framtiden. Hur kommer supporten att fungera angående teknik och funktioner? Redovisning av tidigare erfarenhet (från anbudsgivaren) vid implementerande av systemet och då framförallt ex- empel från den högre utbildningen är önskvärt. Hur många installationer är utförda på framförallt svenska högskolor? Referenser till utländska universitet får naturligtvis lämnas och bör så även göras. Hur har tredjepartslösningar fungerat i praktiken? Anbudsgivaren engagemang för högre utbildning och integration med biblioteksresurser är av högsta vikt. - 28 - Miniriskmetod En metod som kallas ”minirisk” och som används vid riskhantering bör kunna användas, vid ut- värderingen av LMS: s, i ett eventuellt upphandlingsförfarande. Minirisk fungerar enligt följande: - sätter ett värde av 1-5 på sannolikheten att risken inträffar - sätter ett värde av 1-5 på konsekvensen av att risken inträffar - riskvärdet är multipeln mellan sannolikhet och konsekvens (1-25 där 25 är sämsta utfallet) Riskerna kan sedan positioneras i en matris enligt nedan, där de ”röda riskerna” prioriteras: Figur 1 Matris för en riskanalys (Hedberg, P. Högskolan i Borås) Om resonemanget översätts till en kravspecifikation kan sannolikhet ersättas med ”Vikt” och konsekvens kan ersättas med ”Uppfyllnad”. Multipeln kan sedan beräknas. Figur 2 Förslag på en matris för en utvärdering av en kravspecifikation av ett LMS (Hedberg, P. 2004. Högskolan i Borås) Sannolikhet Konsekvens Vikt Uppfyllnad APPENDIX Högskolan i Borås Sigrén, Peter Holmqvist, Hans 2005-01-15 APPENDIX Syntes och analys av tidigare kravspecifikationer för upp- handlingar av LMS inom den svenska högskolan 2000 – 2004 INNEHÅLL Inledning..................................................................................................................................... 2 Högskolan i Borås ...................................................................................................................... 3 Chalmers tekniska högskola....................................................................................................... 6 IT-universitetet i Göteborg....................................................................................................... 41 Karlstads universitet ................................................................................................................. 45 Högskolan i Kristianstad .......................................................................................................... 49 Luleå tekniska universitet......................................................................................................... 52 2 INLEDNING Appendixet innehåller kravspecifikationer från de lärosäten som har lämnat ifrån sig en elek- tronisk version av sitt underlag. Ett lärosäte har valt att inte vilja publicera underlaget. 3 HÖGSKOLAN I BORÅS Kravspecifikation Nedan anges de krav som högskolan anser att ett system skall eller bör uppfylla. Samtliga skall-krav måste vara uppfyllda för att systemet skall kunna ingå i upphandlingen. Område/Funktion Förklaring 1. System 1.1 Systemoberoende (OS, webbläsare) på klientsidan Systemet skall kunna användas med alla standardb- rowser som uppfyller w3c standard för browser (HTML 4). Denna browser skall inte vara låst till ett speciellt operativsystem. 1.2 Systemoberoende (OS, webbläsare) på klientsidan Alla basfunktioner bör vara åtkomliga utan extra plugins. Ange vilka plugins som krävs för att kunna använda systemets alla funktioner. 1.3 Standard Systemet skall följa den utveckling av standarder för LMS som sker. (SCORM, IMS OKI etc.) 1.4 Klientoberoende Systemet skall kunna användas utan speciell installe- rad klient. 1.5 Virusskydd Systemet bör ha integrerad programvara för virus- skydd. Beskriv vilken programvara som används. Om inte programvaran levereras skall rekommendation på virusskydd beskrivas. 1.6 Brandväggar Det bör inte användas någon form av kommunikation som inte följer standardiserad webbkommunikation genom brandväggar (annat än port 80). 1.7 Hantering av java applets Java applets i htmlsidor som importerats eller skapats i systemet bör stödjas. Själva java appleten skapas i extern miljö. 1.8 Stöd för funktionshindrade Stöd för funktionshindrade bör finnas. Ange hur och vilka standarder som följs. 1.9 Lagring Varning vid överskriden lagring bör ske. 1.10 Tid och datum Svensk tid- och datumformat bör finnas. 2. Användare 2.1 Språk på menyer 1 Svenska eller engelska skall finnas som menyspråk. 2.2 Språk på menyer 2 Menyspråk bör kunna ändras beroende på inställd personlig profil. 2.3 Teckenhantering i text-chatt Systemet bör kunna använda text med olika tecken- snitt. Ange hur systemet hanterar standarder för text- kodning såsom Unicode. 2.4 Öppen (icke inloggad) nivå En nivå bör kunna vara öppen för användare utan lösenord. 2.5 Personuppgifter Användare bör kunna ändra egna personliga uppgif- ter. 2.6 Verktyg för reflektion En viktig del i lärandet är egen reflektion. Systemet bör stödja detta på något sätt, t.ex. med dagboksfunk- tion. 2.7 Samarbetsverktyg (red av dokument i realtid) Dokumenthantering i realtid för flera användare bör finnas, samt ljud och/eller textchat. 2.8 Dokumenthantering (vem skrivit vad, versioner) Stöd skall finnas för att hantera dokument som flera användare skriver och ändrar i vid olika tillfällen. 4 2.9 Gemenskapsskapande funktioner Bilder och presentationer av användare underlättar samarbete. Dynamisk bildhantering (av användarbil- der) bör finnas. 2.10 (In-) Aktivitetsinfo Information vid t.ex. nedladdning då till synes ingen- ting händer under lång tid bör finnas. Detta är extra viktigt vid modemanvändning. 2.11 Flaggning av nytt mtrl Användare bör kunna se, vilket material som är nytt på en central nivå (underliggande nivåer bör inte behöva besökas för att få information om ev. nytt material). 2.12 E-postlistor E-postlistor till såväl grupp (inom kurs) som hela kursgruppen bör finnas. 2.13 Anslagstavla Möjlighet för studenter och lärare att publicera med- delande som alla användare ser, respektive viss grupp ser, bör finnas. 2.14 E-postfunktion Det skall finnas intern resp. extern e-postfunktion, 2.15 Vilka är inloggade Inloggade bör kunna se vilka andra som inloggade i kursen. 2.16 Import och export Det skall kunna ske såväl import som export av do- kument. 2.17 HTML sidor Hela HTML sidor bör kunna importeras till systemet. 3. Lärare 3.1 Multimedia Multimediafiler som skapas i extern miljö (flash, real media, Microsoft media, director, quicktime) skall kunna publiceras. 3.2 Olika behörighetsnivåer Olika behörighetsnivåer för t.ex. administratörer, lärare, handledare, och studenter skall kunna ställas in vid registrering av nya användare. 3.3 Autoinlägg av studenter och komplettering av lärare Oberoende av rutiner vid inläggning av användare i systemet bör det vara enkelt att komplettera en grupp användare med ytterligare personer. 3.4 Användarfrekvens Visning av användarfrekvens på individnivå bör finans. Information bör ges om antal inlägg i diskus- sionsforum, uppladdningar etc. 3.5 Se presumtiva drop-outs Systemet bör kunna visa vilka som inte loggat in efter ett antal dagar. 3.6 Historik Det bör vara möjligt att se vem som gjort vad med det aktuella kursmaterialet. 3.7 Nytt dokument Att skapa nytt dokument direkt i systemet bör vara möjligt. 3.8 Datumstyrning Publiceringsdatum bör kunna anges för kursmaterial. Ange vilka andra publiceringsstyrningar som finns. 3.9 Tidsstyrning Publiceringstid bör kunna anges för kursmaterial. 3.10 Webb-editering Enkel webb-editering med eller utan mallar bör vara möjligt. 3.11 HTML dokument Hela HTML dokument bör kunna importeras. 3.12 Sökfunktion Sökfunktion för material och personer inom systemet bör finnas. 3.13 Trädstruktur Trädstruktur - layout underlättar navigering och överblick och bör finnas. 3.14 Frågeverktyg, inklusive statistikverktyg och gra- fik Bör finnas för såväl "snabba" frågor som en mer standardiserad tentamensmodell. Ange vilken typ av frågor som kan hanteras (inmat- ning av frågor, visning, inmatning av svar och vis- ning av svar). 5 3.15 Frågedatabas Frågor bör kunna slumpas ut t.ex. när studenter vill testa ett ”batteri” av frågor. 3.16 Bildkonferens Bör finnas. T.ex. integrering med Netmeeting eller Marratech. 3.17 Ljudkonferens Bör finnas. 3.18 Streamingfunktion Bör kunna kombineras på ett enkelt sätt med Internet. 3.19 Metadata Det bör finnas möjligheter att använda metadata och är dessa i så fall sökbara? Ange om standard följs. Ange referens där metadata har använts. 3.20 Stöd för bildpublicering Bilder skall kunna läggas in i systemet. 3.22 Kursvärdering System för kursvärdering bör finnas. 4. Drift hos HB 4.1 Kostnadsmodell Ange kostnadsmodell. Ange hur många samtida akti- va användare som kan finnas i systemet. HB har i dag cirka 12 000 registrerade studenter och 600 anställda 4.2 Samtida användare Ange hur många samtida användare som kan använda samma dokument, exempelvis en tentamen. 4.3 Krav på server mm. Vilken serverplattform (OS), övriga produkter (pro- gram), licenser, internminne, lagringsutrymme krävs? 4.4 Skalbarhet Ange krav för olika nivåer av antal användare på server, serverprogramvaror, 3.e-partslicenser, kom- munikation etc. 4.5 Databashanterare Används någon 3: parts lösning? Vilka är möjliga? 4.6 Uppdateringar Hur ofta sker uppdatering av mjukvaran? Vilka krav/möjligheter till patchning av OS lämnas av sy- stemet? 4.7 Säkerhetskopiering Rekommenderade säkerhetskopieringssystem? 4.8 Support Support till handledare/författare/administratör skall kunna erbjudas. Beskriv supporten med avseende på uppbyggnad, kontaktvägar samt öppettider 4.9 Supportkostnader Supportkostnader vid egen drift? Supporttider? Kost- nader för olika typer av support? 4.10 BKS, behörighetskontroll Beskriv systemets behörighetskontrollsystem. Önsk- värt är också kommentarer till hur väl systemet kan nyttja det system för identifikation/auktorisation som utvecklas i universitetsvärlden. 5. Drift hos leverantör 5.1 Kostnadsmodell Ange kostnadsmodell. Kan antalet användare ökas stegvis? 5.2 Kommunikationskostnader Tillkommer kostnader för kommunikation? 5.3 Kommunikationshastighet Vilken kommunikationshastighet garanteras? 5.4 Serverkapacitet mm. Servertyp, kapacitet och konfiguration? Internmin- ne/lagringskapacitet? 5.5 Säkerhetskopiering Hur sker säkerhetskopiering och vilka är möjlighe- terna till återinläggning av ev. förlorade filer? 5.6 Support Support till handledare/författare/administratör skall kunna erbjudas. Beskriv supporten med avseende på uppbyggnad, kontaktvägar samt öppettider 5.7 Supportkostnader Supportkostnader vid drift hos leverantör? Supportti- der? 5.8 BKS, behörighetskontroll Beskriv systemets behörighetskontrollsystem. Önsk- värt är också kommentarer till hur väl systemet kan nyttja det system för identifikation/auktorisation som utvecklas i universitetsvärlden. 6 CHALMERS TEKNISKA HÖGSKOLA Kravspecifikation Compatibility Web based The system must be fully web based. No client installation besides the web browser should be needed to be able to use and administrate the system. Plug-ins and Java applets can be accepted in specific tools, but not in general. Requirement: must Importance: 5 Fulfilled: yes/no Comment Web browser The system must be compatible with any of the web browser Explorer 6.0, Netscape 7.0 or Mozilla 1.4 Specify versions and other eventual browsers. Requirement: must Importance: 5 Fulfilled: yes/no Comment Web browser – W3C standard The system must be compatible with web browser supporting the W3C stan- dards ¶ XHTML 1.0 ¶ CSS1/2 Requirement: must Importance: 5 Fulfilled: yes/no Comment Java The system should not use Java applets in the general interface E.g. Java should not be used for navigation on the portal page. Java applets can be allowed for specific tools. If Java applets are used, specify their purpose and which version of Java Virtual Machine they require. Requirement: must Importance: 5 Fulfilled: yes/no Comment Operative System The client side of the system must be compatible with the operative systems MacOS X, Windows XP and Linux Specify other eventual operative systems. Requirement: must Importance: 5 Fulfilled: yes/no Comment 7 Screen size The system must be compatible with the screen size 1024x768 Requirement: must Importance: 5 Fulfilled: yes/no Comment Screen size – 800x600 The system should be compatible with the screen size 800x600 You must be able to navigate in the system and read text documents without horizontal scrolling. Requirement: should Importance: 4 Fulfilled: yes/no Comment Physically impaired The system should be adapted for the physically impaired For this requirement to be fulfilled, the system must comply with: ¶ Level Triple-A Conformance to Web Content Accessibility Guidelines 1.0 ¶ US Government Section 508 Accessibility Guidelines Requirement: should Importance: 4 Fulfilled: yes/no Comment System adaptability We shall have access to the system source code, including full documentation and specification of SDK and API, enabling our ability to write our own sys- tem modules, and make interface and integration adjustments. Requirement: must Importance: 5 Fulfilled: yes/no Comment System adaptability – source code The source code of the platform should be available if requested, possibly without any extra license fees The license for using the source code should allow developers to modify it and redistribute the modifications at least within Chalmers. Requirement: should Importance: 4 Fulfilled: yes/no Comment 8 Interface issues Usability The system interface should have high usability The system should be tested to conform to ISO 9241 part 11 for usability: "The extent to which a product can be used by specified users to achieve specified goals with effectiveness, efficiency, and satisfaction in a specified context of use." We will if necessary test the systems usability according to the following: ¶ effectiveness ¶ efficiency ¶ satisfactory Requirement: should Importance: 4 Fulfilled: yes/no Comment Swedish time format It shall be possible to use Swedish time (GMT +1), Swedish time format (24 hour) and Swedish calendar format (Monday-Sunday weeks) E.g. in calendar views, web forum time stamps etc. Requirement: must Importance: 5 Fulfilled: yes/no Comment Swedish time format – time zones It should be possible to set time zones on an individual level Requirement: should Importance: 4 Fulfilled: yes/no Comment Navigation structure The system should be able to present information and content in an hierar- chical navigation structure The intention is to use a classic tree structure with menus in several levels, e.g. using a folder metaphor. Requirement: should Importance: 4 Fulfilled: yes/no Comment Navigation structure – customized menus It should be possible to use customized menu texts The system should offer the ability to write customized menu texts, not only select from pre-defined menus (e.g. default buttons). Requirement: should Importance: 4 Fulfilled: yes/no Comment 9 Navigation structure – long course names It should be possible to use (input and display) long course names Requirement: should Importance: 2 Fulfilled: yes/no Comment Language The system should have support for English in the proprietary parts of the interface E.g. default menu buttons, functions etc. shall be able to display in English. The standards i18n and l12n shall be used. Requirement: must Importance: 5 Fulfilled: yes/no Comment Language – Swedish The system should have support for Swedish in the proprietary parts of the interface E.g. default menu buttons, functions etc. must be able to display in Swedish. Requirement: should Importance: 4 Fulfilled: yes/no Comment Language – characters The system must have Swedish characters The standards Western ISO-8859-15 and Unicode-utf-8 must be used. Requirement: must Importance: 5 Fulfilled: yes/no Comment Language – language negotiation Displayed language should be role based and individualized The intention is that the user can select display language him/herself. Requirement: should Importance: 2 Fulfilled: yes/no Comment Portal page The first main page after login must be a portal page Our definition of a portal page is that it is a web page where important content is highlighted, such as announce- ments, forum postings, calendar notes, assignments etc. Requirement: must Importance: 5 Fulfilled: yes/no Comment 10 Portal page – flags New content on the portal page should be high-lighted with “flags” E.g. new announcements or newsgroup postings submitted since last login. Requirement: should Importance: 3 Fulfilled: yes/no Comment Portal page – individualized The content and display on the portal page should be possible to individualize by the user E.g., the user should be able to set preferences for which information will be displayed, time span etc. Requirement: should Importance: 2 Fulfilled: yes/no Comment Portal page – role based The content on the portal page should be possible to use as role base E.g., participants in a specific course get information from that particular course. Requirement: should Importance: 2 Fulfilled: yes/no Comment Experienced users The system should be able to provide an interface adapted to experienced us- ers The intention is to have short cuts etc. which increase the efficiency for experienced users. This could be default in the interface, or a feature that can be made accessible for specific users. Requirement: should Importance: 1 Fulfilled: yes/no Comment Print Web pages should be adapted for printing Describe how this has been assured. We include e.g. user lists, newsgroups, statistics, help pages, news announce- ments etc. Navigation menus and similar is not included in this requirement. Requirement: should Importance: 3 Fulfilled: yes/no Comment Design adjustments Graphic elements in the system interface should be exchangeable by the sys- tem administrator Requirement: should Importance: 3 Fulfilled: yes/no Comment 11 Back & forward The web browsers back & forward buttons should be possible to use as in- tended in all parts of the system Requirement: should Importance: 1 Fulfilled: yes/no Comment Access, security and account management Security management The system must be able to manage security on objects based on the notions of roles and permissions Security settings are defined in terms of roles and permissions. When a role is assigned to a permission, users with the given role will be able to perform tasks associated with the permission on the object (no matter who owns the object.) Requirement: must Importance: 5 Fulfilled: yes/no Comment Objects The system must be able to manage objects An object can be a folder, a mailing list, a forum, a course, a calendar, a text document, a theme, a video etc. Requirement: should Importance: 4 Fulfilled: yes/no Comment Ownership of objects. The system must be able to manage ownership of an object It must be possible for an object to have owners. Requirement: should Importance: 4 Fulfilled: yes/no Comment Roles The system must be able to manage roles Any number of roles may be defined globally. Example of roles: Anonymous, Authenticated, Manager, Member, Owner, Reader, Reviewer, Workgroup Man- ager, Workgroup Member, Workgroup Visitor, Teacher, Student Requirement: should Importance: 4 Fulfilled: yes/no Comment Permissions The system must be able to manage permissions on objects Permission is associated with a task performed on an object. Permissions provide a way to control access to opera- tions without having to list each operation explicitly. Example of permissions: 'Add Folders - Add Mailing Lists - Add Workgroups - Copy or Move - Delete objects - Edit Directory - Import/Export objects, List folder contents - Take ownership - Undo changes, View, Publish Requirement: should Importance: 4 Fulfilled: yes/no Comment 12 Assigning roles to users The system must be able to manage assigning roles to users Roles must be manually assignable. Roles must be assignable by the system, for instance: ¶ All authenticated users are assigned the 'authenticated' role. ¶ All anonymous users (not authenticated) are assigned the 'anonymous' role. Roles must be assignable through an external authority (e.g. LDAP) Requirement: should Importance: 4 Fulfilled: yes/no Comment Assign permissions to objects The system must be able to manage assigning permissions to objects Requirement: should Importance: 4 Fulfilled: yes/no Comment Preserving ownership It must be possible to perform actions on objects by preserving the object's ownership Action performed on an object must be able to not modify the object's owners hip (unless stated otherwise as for example with the 'take ownership' action). For instance: ¶ If a manager renames or moves a user's folder, the ownership of the folder and its objects must be preserved. ¶ When a user is removed, ownership information on objects must be preserved, i.e. an object must be ownable by a user that no longer exists in the user database. Requirement: should Importance: 4 Fulfilled: yes/no Comment Preserving permissions It must be possible to perform actions on objects by preserving the permis- sions of the object. Action performed on an object must be able to not modify the permissions of the objects if not stated otherwise Requirement: should Importance: 4 Fulfilled: yes/no Comment Assigning permissions to roles It must be possible to assign individual permissions to individual roles See matrix and explanation below Requirement: should Importance: 4 Fulfilled: yes/no Comment 13 Assigning roles to permissions It must be possible to assign individual roles to individual permissions See matrix and explanation below Requirement: should Importance: 4 Fulfilled: yes/no Comment Assigning roles to objects It must be possible to assign individual roles to individual objects Local roles must be able to be assigned to individual objects. Requirement: should Importance: 4 Fulfilled: yes/no Comment Acquisition of permissions It must be possible to manage the acquisition of permissions This indicates whether items should inherit security settings for a given permission from its container object. For instance, it must be possible for a document in a folder to automatically inherit the permissions of the folder with- out the need to define the document's permissions. Requirement: should Importance: 4 Fulfilled: yes/no Comment Public access It should be possible to make parts of the system content public (anonymous access without login) E.g. the access to specific news announcements, documents, files, course content etc. should be possible to set as public. Specify which system objects can be public. Requirement: should Importance: 4 Fulfilled: yes/no Comment IP address It should be possible to base access on user IP address Requirement: should Importance: 1 Fulfilled: yes/no Comment Single Sign On The system should support Single Sign On (SSO) Requirement: should Importance: 4 Fulfilled: yes/no Comment Describe applied standards 14 Encryption The client side must use strong encryption (128 bit SSL) when personal data is transferred or used via the network, and when a user log in Requirement: must Importance: 5 Fulfilled: yes/no Comment Encryption – SSL Support for Secure Socket Layer or the equivalent between server and client Requirement: should Importance: 4 Fulfilled: yes/no Comment Backup/recovery The system must have routines for backup and recovery management, and these must be well documented Requirement: must Importance: 5 Fulfilled: yes/no Comment Upgrade management The system must have routines for upgrades and patches, and these must be well documented Requirement: must Importance: 5 Fulfilled: yes/no Comment LADOK integration The system must be able to receive information from LADOK Requirement: must Importance: 5 Fulfilled: yes/no Comment Chalmers system integration The system must be adaptable to catalog and login databases currently in use at Chalmers Attached: description of our current infrastructure. Requirement: must Importance: 5 Fulfilled: yes/no Comment Group management The system should have a tool which allows students to sign up in pre- defined groups The intention is e.g. to let students manage their own sign-up to lab groups, project groups etc., and the system should then also display the participants in each group. Requirement: should Importance: 4 Fulfilled: yes/no Comment 15 Group management – group size It should be possible to set max-min values on group sizes and number of groups Requirement: should Importance: 4 Fulfilled: yes/no Comment Group management – time limit The groups should be possible to open and close according to specified start and end dates Requirement: should Importance: 4 Fulfilled: yes/no Comment Group management – acting as a group It should be possible for groups to do activities, as a group, in the system E.g. publish files, write messages etc. Requirement: should Importance: 2 Fulfilled: yes/no Comment Performance and system requirements Scalability The system must be scalable up to 1,000 simultaneous users (concurrent re- quests) It must be possible to scale to system through load balancing, cluster installation, or other documented and proven methods, so that the load on the system (number of request per second, response time or other measurable vari- ables) varies linear up to 1,000 simultaneous users. Requirement: must Importance: 5 Fulfilled: yes/no Comment Cluster It must be possible to run the system as a cluster There must be a documented and tested method to run the system in a cluster, on several machines. Please describe what effect this would have on licenses and budget. Requirement: must Importance: 5 Fulfilled: yes/no Comment Operative system It must be possible to run the system on Linux or Solaris It must be possible to run the system on production versions of Linux on Intel x86 (e.g. RedHat Advanced Server). It must be possible to run the system on other versions of Linux without extensive adjustments. It must be possible to run the system on production versions of Solaris on Sparc (e.g. Solaris 9) Requirement: must Importance: 5 Fulfilled: yes/no Comment 16 Databases It must be possible to use Oracle 9 with the system There should be support for different databases, but it must have support for Oracle 9. Requirement: must Importance: 5 Fulfilled: yes/no Comment Web server The system must be able to utilize a web server, or have a proprietary web server Requirement: must Importance: 5 Fulfilled: yes/no Comment Functionality “Rooms” It must be possible to open “rooms” in the system, adding any type of “ob- ject” See introduction for our definition of “rooms” and “objects”. What we require is the ability to create “courses” and “project rooms” (the equivalent of our concept “room”) and arrange these in a hierarchical structure. We require that any “object” (tool, content etc.) can be added to any room. Describe to what extent the system can be used according to this concept. Requirement: must Importance: 5 Full-fills: yes/no Comment “Rooms” – access Both teachers and students should be able to create and administrate “rooms” Requirement: should Importance: 4 Full-fills: yes/no Comment “Rooms” – multiple roles In each specific “room” every access role should be able to have more than one user assigned E.g. in a course, several users should be able to be teachers, or course builders, course managers etc. Requirement: should Importance: 4 Full-fills: yes/no Comment Calendar Tool for the display of time-specific events The tool must be able to present events with specified start and end times, sorted chronologically on start time. Requirement: must Importance: 5 Full-fills: yes/no Comment 17 Calendar – week view The events are presented in calendar week views The calendar should be able to display calendar data as a weekly overview, summarizing events and free time Requirement: should Importance: 4 Full-fills: yes/no Comment Calendar – role based It should be possible to display the calendar events according to different groups/access levels and system roles The display of events should be controllable so that specific calendar data is accessible only to specific users. This access should be based on groups, system access and/or system roles. Each user should only see the events that are relevant for the specific user, e.g. students only see events in the courses in which they are participating. Requirement: should Importance: 4 Full-fills: yes/no Comment Calendar – summary The system should be able to display a summary of all events E.g., a teacher or student should be able to choose to see all events, even those that he/she is not participating in. Requirement: should Importance: 2 Full-fills: yes/no Comment Calendar – individualized events The user should be able to add individual events in the calendar tool E.g., the user should be able to book private meetings. Requirement: should Importance: 2 Full-fills: yes/no Comment Calendar – summary of individual events Tool for summary of several individual calendars The intention is e.g. to use this in project groups to find common free time in the calendar. Requirement: should Importance: 1 Full-fills: yes/no Comment Calendar – deadline display The calendar tool should include not only events such as meetings and lec- tures, but also other time critical events such as project or quiz deadlines Requirement: should Importance: 4 Full-fills: yes/no Comment Calendar – day-specific events It should be possible to add events which have a specific date but not a time interval Requirement: should Importance: 2 Full-fills: yes/no Comment 18 Calendar – import/export It must be possible to export and import calendar content It must be possible to export and import calendar content according to iCalendar or vCalendar standards. Requirement: should Importance: 4 Full-fills: yes/no Comment Calendar – synchronizing It should be possible to synchronize calendar events in the system with other calendar applications Requirement: must Importance: 5 Full-fills: yes/no Comment Calendar – integration It should be possible to integrate the calendar tool with a calendar server Preferably, you should be able to connect a calendar server to the system so that all calendar data is stored outside the system and is accessible for other applications. Requirement: should Importance: 2 Full-fills: yes/no Comment Calendar – repetition Function for efficient management (create, edit and delete) of repetitive events It should also be possible to change only one of the repeated events. Requirement: should Importance: 4 Full-fills: yes/no Comment Calendar – links Function for adding links from events to files and/or objects in the system and/or external URL. E.g. class material, PowerPoint presentations, web pages. Requirement: should Importance: 4 Full-fills: yes/no Comment Calendar – location It should be possible to locate an instance of the tool in any course or “room” Requirement: should Importance: 4 Fulfilled: yes/no Comment 19 Flexible levels It should be possible to arrange tools, content etc. (“objects”) in a customiza- ble hierarchical structure The intention is to locate tools (e.g. forums, calendar etc.) and content (e.g. announcements, documents etc.) any- where in a hierarchical structure, not only inside courses or project rooms. Note that we generally refer to this as “objects”. Requirement: should Importance: 4 Fulfilled: yes/no Comment Grade-book The system should have a Grade-book-tool We intend to use the grade-book-tool to register student results from quizzes, grades and “points”. Requirement: must Importance: 5 Fulfilled: yes/no Comment Grade-book – statistics The Grade-book should have a tool for summarizing and displaying student statistics Requirement: should Importance: 3 Fulfilled: yes/no Comment Grade-book – export/import It must be possible to import and export data to and from the grade-book Requirement: must Importance: 5 Fulfilled: yes/no Comment Quizzes & surveys The system must have a tool for creating and deploying quizzes and surveys Requirement: must Importance: 5 Fulfilled: yes/no Comment Quizzes & surveys – i nteractive elements The majority of these interactive form elements should be available when creating quizzes and surveys Describe which of the following that is available: ¶ Input field ¶ Text area ¶ Menu box ¶ Dropdown menu ¶ Check-box ¶ Radio buttons ¶ Image maps Requirement: should Importance: 4 Fulfilled: yes/no Comment 20 Quizzes & surveys – export It must be possible to export data as tab separated text files (or equivalent) Requirement: must Importance: 5 Fulfilled: yes/no Comment Quizzes & surveys – timed access The access to a quiz or survey should be possible to set according to start and end time Requirement: should Importance: 2 Fulfilled: yes/no Comment Quizzes & surveys – trials It should be possible to control how many trials a user can answer a quiz or survey Requirement: should Importance: 2 Fulfilled: yes/no Comment Quizzes & surveys – test time It should be possible to control how long time a user has to complete a survey or quiz Requirement: should Importance: 2 Fulfilled: yes/no Comment Quizzes & surveys – anonymity It should be possible to let the user fill in a quiz or a survey anonymously Requirement: should Importance: 2 Fulfilled: yes/no Comment Quizzes & surveys – auto-grading When launching a quiz, it should be possible to have the quiz answers graded either automatically or manually Requirement: should Importance: 4 Fulfilled: yes/no Comment Quizzes & surveys – auto-grading – delay When using manual grading, it should be possible for the teacher to decide when the correct answer/grading will be displayed Requirement: should Importance: 2 Fulfilled: yes/no Comment 21 Quizzes & surveys – point value It should be possible to set point value on each question in a quiz Requirement: should Importance: 4 Fulfilled: yes/no Comment Quizzes & surveys – quizz es – teacher comments When using quizzes, it should be possible for the teacher to give comments to the students when grading a quiz It is an advantage if the student, as a part of the quiz, also can send comments to the teacher. Requirement: should Importance: 2 Fulfilled: yes/no Comment Quizzes & surveys – quizz es – question archive Quizzes and/or the questions should be achievable for later re-use by other teachers Requirement: should Importance: 3 Fulfilled: yes/no Comment Quizzes & surveys – qui zzes – random order It should be possible to have the questions in a quiz displayed in random or- der It is important that the system keep track of which questions a specific student has seen Requirement: should Importance: 2 Fulfilled: yes/no Comment Quizzes & surveys – quizzes – Grade-book integration The result from quizzes should be exported/synchronized with the system Grade-book Requirement: should Importance: 3 Fulfilled: yes/no Comment Quizzes & surveys – quizzes – export It should be possible to export the results from the quizzes to tab separated text files (or equivalent) Requirement: should Importance: 3 Fulfilled: yes/no Comment Quizzes & surveys – quizzes – import It should be possible to import questions from external sources into the quiz tool Requirement: should Importance: 3 Fulfilled: yes/no Comment 22 Quizzes & surveys – quizz es – printable essays When using essay answers in the quiz, it should be possible for the teacher to display and print all essays on one page Requirement: should Importance: 3 Fulfilled: yes/no Comment Quizzes & surveys – statistics It should be possible to display statistics from survey data It would be an advantage to have graphical tools for displaying the result as diagrams. Requirement: should Importance: 4 Fulfilled: yes/no Comment Quizzes & surveys – location It should be possible to locate an instance of the tool in any course or “room” Requirement: should Importance: 4 Fulfilled: yes/no Comment File management The system must have tools for managing files Uploading, display, and downloading of files are required. This general requirement for file management is equivalent to both “file publishing” and “asset management”, and can be solved either as separate tools or one general tool. Requirement: must Importance: 5 Fulfilled: yes/no Comment File management – checking in/out The file management should include a check in/check out function, so that two users cannot edit the same file Requirement: should Importance: 4 Fulfilled: yes/no Comment File management – versioning The file management should include a versioning function Requirement: should Importance: 2 Fulfilled: yes/no Comment File management – comments It should be possible to post comments connected to specific files Please describe if several comments can be added, and if a threaded discussion can be displayed. Requirement: should Importance: 2 Fulfilled: yes/no Comment 23 File management – collaborative editing It should be possible for two or more users to edit the same file simultane- ously Please describe which file formats can be used. Requirement: should Importance: 2 Fulfilled: yes/no Comment File management – file formats It should be possible to control, on a folder-by-folder basis, which file for- mats are allowed and which are not Requirement: should Importance: 2 Fulfilled: yes/no Comment File management – file size It should be possible to control, on a folder-by-folder basis, which file for- mats are allowed and not Requirement: must Importance: 5 Fulfilled: yes/no Comment File management – file conversion Tool for conversion between file formats E.g. from .doc to .pdf, or .psd to .jpg. Please specify formats. Requirement: should Importance: 2 Fulfilled: yes/no Comment File management – deploying content The platform should support common protocols that facilitate uploading (and optional editing) of files, folders, and documents At least FTP or WebDAV. Requirement: should Importance: 4 Fulfilled: yes/no Comment Workflow The system should have a tool for creating and managing workflows Requirement: should Importance: 4 Fulfilled: yes/no Comment Peer review The system should have a specific tool for peer review This should include the ability for students to exchange e.g. essays and make comments. Random distribution of documents to review should also be included. Requirement: should Importance: 4 Fulfilled: yes/no Comment 24 Assignments submission The system should have a tool which manages the student submission of as- signments, group works etc. The intention is to have a set of tools which makes it possible for students to submit their work for teacher evalua- tion, peer review etc. Requirement: must Importance: 5 Fulfilled: yes/no Comment Link publishing There must be a tool for publishing (create and display) hypertext links The system should manage the links as “objects” (compare the management of documents or files), hence making it possible to publish them in any part of the navigation structure. Requirement: must Importance: 5 Fulfilled: yes/no Comment Link publishing – system internal The system should make it possible to create internal links, from one object to another Requirement: must Importance: 5 Fulfilled: yes/no Comment Link publishing – target The TARGET-tag for the link should be possible to set This should include the ability to open the link in the same frame, in the same browser window and in a new win- dow. Requirement: must Importance: 5 Fulfilled: yes/no Comment Dynamic web pages It must be possible to create dynamic web pages with an editing tool What we would like is the use of web forms to create documents whose content is stored in e.g. a database, and then displayed as web pages. Requirement: must Importance: 5 Fulfilled: yes/no Comment Dynamic web pages – HTML It should be possible to use HTML code when using the editing tool What we would like is e.g. using snippets of code to achieve e.g. a text editing that is not built into the editing tool. Requirement: must Importance: 5 Fulfilled: yes/no Comment 25 Dynamic web pages – upload web pages It should be possible to upload and parse existing web pages (html files) Requirement: must Importance: 3 Fulfilled: yes/no Comment Dynamic web pages – upload web sites It should be possible to upload and parse existing web sites (complete www directory) This should include automatic management of internal links and links to images and other sources. Requirement: should Importance: 2 Fulfilled: yes/no Comment Dynamic web pages – import web pages It should be possible to import a complete web site via a submitted URL This should include the automatic import of all required html files, image files etc. Requirement: should Importance: 1 Fulfilled: yes/no Comment Dynamic web pages – extern WYSIWYG It should be possible to import dynamic web pages from external web pub- lishing systems The tool should use XML, XSLT and IMS standards. Requirement: should Importance: 2 Fulfilled: yes/no Comment Dynamic web pages – formula editor The editing tool should have a tool for creating and editing advanced mathematical and statistical expressions and formulas The editor should not use any additional client software. Java applets can be accepted. Requirement: should Importance: 4 Fulfilled: yes/no Comment Dynamic web pages – spelling The editing tool should include a spelling correction feature Please comment whether the tool includes Swedish and/or English language modules. Requirement: should Importance: 2 Fulfilled: yes/no Comment Dynamic web pages – WYISWG The editing tool should include a WYSIWYG editor The editor should not use any additional client software. Java applets can be accepted. Requirement: should Importance: 4 Fulfilled: yes/no Comment 26 Dynamic web pages – WYISWG – Java It should be possible to use the editing tool without any Java applets The intention is to give users the choice not use the Java applet, and thus accepting more simple features and func- tionality. Requirement: should Importance: 3 Fulfilled: yes/no Comment Dynamic web pages – WYISWG – templates It should be possible to create new templates for dynamic web pages, includ- ing new content fields Requirement: should Importance: 1 Fulfilled: yes/no Comment Dynamic web pages – file display The system should have a tool for display of media files etc. The tool should be able to recogniz e common file formats and create the necessary tags for embedding the media in a web page. This should be editable by the user. Please state if the system can handle the following file formats in this way: Flash, Shockwave, Quicktime, Realvideo, .avi, mpeg, Cult3D, mp3, wave and custom Java applets. Requirement: should Importance: 4 Fulfilled: yes/no Comment News The system shall include a tool for publishing news The news (announcements) is e.g. published via a web form. Teachers shall have access to this tool. Requirement: must Importance: 5 Fulfilled: yes/no Comment News – portal News should be displayed on the system portal page The news display on the portal page should be role based, hence each user get news and announcements sorted and displayed according to which rooms (courses etc.) the user participates in. Requirement: should Importance: 2 Fulfilled: yes/no Comment News – subscription The user should be able to subscribe to the news Please notify if the user can get news notified via e-mail or via SMS. Requirement: should Importance: 3 Fulfilled: yes/no Comment 27 News – subscription – individualized The subscription should be individualized Our intention is that each user should be able to control which news the subscription sends a notification about. Requirement: should Importance: 3 Fulfilled: yes/no Comment News – standards The news tool should comply to standards enabling the news to be exportable from the system E.g. any of the standards RSS, RD, 6.9.1. Requirement: should Importance: 4 Fulfilled: yes/no Comment News – location It should be possible to locate news in any course or “room” Requirement: should Importance: 4 Fulfilled: yes/no Comment Statistics There must be a statistics tool in the system E.g. the teacher must be able to follow the activities of the students. Requirement: must Importance: 5 Fulfilled: yes/no Comment Statistics – export It must be possible to export statistics from the system Please describe which standards and formats the export utilizes. Requirement: should Importance: 4 Fulfilled: yes/no Comment Statistics – graphical display Statistics should be presentable graphically, e.g. as tables and diagrams Requirement: should Importance: 3 Fulfilled: yes/no Comment Statistics – group and individual The statistics tool should include a report generator This should include the ability to customize st atistical reports, e.g. according to individuals, groups and courses, etc. Describe which parameters can be used to customize the report. Requirement: should Importance: 3 Fulfilled: yes/no Comment 28 Statistics – activity highlight The statistics tool should be able to highlight inactive users in the system It should e.g. be possible for the teacher to see how often a specific student has logged in, posted in forums, taken quizzes etc. Requirement: should Importance: 3 Fulfilled: yes/no Comment Rooster The system shall have a tool for displaying rooster lists over participants in a room (course) The rooster shall be accessible both for teachers and students in each course. Requirement: must Importance: 5 Fulfilled: yes/no Comment Rooster – family names It should be possible to sort rooster lists on family names Requirement: should Importance: 3 Fulfilled: yes/no Comment Rooster – identical names Users with identical names should be easily identifiable although their names are identical Requirement: should Importance: 3 Fulfilled: yes/no Comment Rooster – photographs It should be possible to submit photographs of each participator, linked to the rooster lists Requirement: should Importance: 3 Fulfilled: yes/no Comment Rooster – location It should be possible to locate an instance of the tool in any course or “room” Requirement: should Importance: 4 Fulfilled: yes/no Comment Search engine There must be a full search engine in the system This must include keyword search on e.g. course name, course content and users. Requirement: must Importance: 5 Fulfilled: yes/no Comment 29 Search engine – file content The search engine should be able to index and search for content of up- loaded files Requirement: should Importance: 3 Fulfilled: yes/no Comment Search engine – access The search engine should not display hits which the user does not have ac- cess to Requirement: should Importance: 3 Fulfilled: yes/no Comment Digital portfolio There should be a tool where teachers and students can create their own digi- tal portfolio E.g. papers, essays, etc can be stored. Requirement: should Importance: 4 Fulfilled: yes/no Comment Digital portfolio – CV The portfolio should include a CV Requirement: should Importance: 3 Fulfilled: yes/no Comment Digital portfolio – file upload It should be possible to upload files to the digital portfolio Requirement: must Importance: 3 Fulfilled: yes/no Comment Digital portfolio – public It should be possible for the owner of each portfolio to make it public Public means accessible for users outside the system, without login. Requirement: should Importance: 3 Fulfilled: yes/no Comment Digital portfolio – export It should be possible to export the portfolio as a self-contained unit, e.g. as a static web site or .pdf file Requirement: should Importance: 4 Fulfilled: yes/no Comment 30 Digital portfolio – learning objectives There should be a tool for management of learning objectives E.g. the definition of learning objectives, and the status of their fulfillment. Requirement: should Importance: 3 Fulfilled: yes/no Comment Course re-cycling There must be a tool for recycling courses Please specify flexibility regarding which parts of an old course can be selected to recycle or not. Requirement: must Importance: 5 Fulfilled: yes/no Comment Course export/import It must be possible to export and import courses to and from the system Describe which formats and standards are used (including versions), e.g.: ¶ SCORM ¶ IMS ¶ AICC Requirement: must Importance: 5 Fulfilled: yes/no Comment Meta data All objects in the system shall manage meta data This would include keywords etc. on e.g. documents, files, news announcements, links etc. Please specify meta data per each object type. Requirement: must Importance: 5 Fulfilled: yes/no Comment Meta data – standards All meta data should comply to the Dublin Core standard Requirement: should Importance: 2 Fulfilled: yes/no Comment Communication & collaboration Who’s logged in? Presentation of who’s logged in to the system E.g. students can see which other students or teachers currently are logged in to the system. Requirement: should Importance: 2 Fulfilled: yes/no Comment Web forums It must be possible to create threaded web forums Requirement: must Importance: 5 Fulfilled: yes/no Comment 31 Web forums – quotation There should be a feature which makes it easy to quote earlier postings Requirement: should Importance: 2 Fulfilled: yes/no Comment Web forums – speed The web forums should be fast and efficient to use Requirement: should Importance: 3 Fulfilled: yes/no Comment Web forums – overview Multiple postings should be possible to display and print on the same page E.g. postings in one thread or during one time interval. Requirement: should Importance: 3 Fulfilled: yes/no Comment Web forums – new postings The system should high-light new postings Requirement: should Importance: 4 Fulfilled: yes/no Comment Web forums – read postings It should be possible to see who’s read (displayed) a specific posting Requirement: should Importance: 1 Fulfilled: yes/no Comment Web forums – notification It should be possible for the user to individualize notifications E.g. the user should be able to select specific postings or authors, and then vie e-mail or on the system portal page get a notification about when responses or postings from the author has been posted. Requirement: should Importance: 1 Fulfilled: yes/no Comment Web forums – attachments It should be possible to attach files in the web forum Requirement: should Importance: 1 Fulfilled: yes/no Comment Web forums – search There should be a search tool for the web forum It should be possible to search for authors as well as keywords in headings and messages. Requirement: should Importance: 2 Fulfilled: yes/no Comment 32 Web forums – access Both students and teachers should be able to launch web forums Requirement: should Importance: 3 Fulfilled: yes/no Comment Web forums – location It should be possible to locate an instance of the tool in any course or “room” Requirement: should Importance: 4 Fulfilled: yes/no Comment Chat The system must have a chat tool for synchronous text communication Requirement: must Importance: 5 Fulfilled: yes/no Comment Chat – applets It should be possible to use the chat without the use of Java applets If the chat tool has both Java and non-Java interface, please describe differences in functionality. Requirement: should Importance: 2 Fulfilled: yes/no Comment Chat – firewalls It should be possible to use the chat through standard configured firewalls This includes the ability to use the chat via a standard firewall, without the need to open specific ports, e.g. when temporary chat guests need to use the chat. Requirement: should Importance: 3 Fulfilled: yes/no Comment Chat – access Both students and teachers should be able to launch chat sessions Requirement: should Importance: 3 Fulfilled: yes/no Comment Chat – ”whisper” The chat should have a “whisper” function We would like the system to have the ability to let participants write, within the chat, private messages to one or several specific participants Requirement: should Importance: 2 Fulfilled: yes/no Comment 33 Chat – access control It should be possible to control access to each chat session Either a chat session should be public, or the moderators invite/approve each new participant. Requirement: should Importance: 2 Fulfilled: yes/no Comment Chat – participants list The chat tool should include a list of current participants Requirement: should Importance: 2 Fulfilled: yes/no Comment Chat – activity flag The chat tool should include a flag/notification showing if any of the partici- pants are writing We would like the system to have the ability to see if a participant is actively writing a message in the chat, but has not yet posted the message. Requirement: should Importance: 1 Fulfilled: yes/no Comment Chat – log It should be possible to log/archive chat sessions Requirement: should Importance: 3 Fulfilled: yes/no Comment Chat – protocol The chat tool should use a standardized protocol, making synchronous chat with other chat clients possible Requirement: should Importance: 1 Fulfilled: yes/no Comment Chat – public list It should be possible to publicly list all chat sessions in the system Requirement: should Importance: 1 Fulfilled: yes/no Comment Chat – location It should be possible to locate an instance of the tool in any course or “room” Requirement: should Importance: 4 Fulfilled: yes/no Comment 34 White-board The system should have a white-board tool for synchronous texts and image based communication Requirement: must Importance: 5 Fulfilled: yes/no Comment White-board – drawing tools The white-board should include a tool for drawing and writing in a common, synchronously updated screen area Describe the abilities to change typeface, text color, pen width, drawing tools etc. Requirement: must Importance: 5 Fulfilled: yes/no Comment White-board – chat integration The white-board should include a text based chat Describe in which way the chat and white-board tools relate to each other. Requirement: should Importance: 4 Fulfilled: yes/no Comment White-board – image import It should be possible to import common file formats into the white-board Describe which image file formats can be imported and displayed. Requirement: should Importance: 4 Fulfilled: yes/no Comment White-board – formula/equation editor There should be a formula/equation editor for the graphic based creation of advanced mathematical expressions etc. Requirement: should Importance: 4 Fulfilled: yes/no Comment White-board – applets It should be possible to use the white-board without the use of Java applets If the white-board tool has both Java and non-Java interface, please describe the differences in functionality. Requirement: should Importance: 2 Fulfilled: yes/no Comment White-board – fire walls It should be possible to use the white-board through standard configured firewalls This includes the ability to use the white-board via a standard firewall, without the need to open specific ports, e.g. when temporary chat guests need to use the chat. Requirement: should Importance: 3 Fulfilled: yes/no Comment 35 White-board – access Both students and teachers should be able to launch white-board sessions Requirement: should Importance: 3 Fulfilled: yes/no Comment White-board – access control It should be possible to control access to each white-board session Either a white-board session should be public, or the moderators invite/approve each new participant. Requirement: should Importance: 2 Fulfilled: yes/no Comment White-board – participants list The chat tool should include a list of current participants Requirement: should Importance: 2 Fulfilled: yes/no Comment White-board – log It should be possible to log/archive white-board sessions, including drawn images Requirement: should Importance: 2 Fulfilled: yes/no Comment White-board – location It should be possible to locate an instance of the tool in any course or “room” Requirement: should Importance: 4 Fulfilled: yes/no Comment E-mail There must be a tool for posting messages to groups or individuals The writer of the message must be able to post the message both as an internal system message (“internal e-mail”), and as an e-mail to the recipient’s external e-mail address. The recipients must be able to set a re-direction of internal message to the external e-mail address. Requirement: must Importance: 5 Fulfilled: yes/no Comment E-mail – external addresses It should be possible to send e-mails to any external address via the system Requirement: should Importance: 1 Fulfilled: yes/no Comment 36 E-mail – e-mail links The system should display external e-mail addresses to all users E.g. in user lists etc. Requirement: should Importance: 1 Fulfilled: yes/no Comment E-mail – e-mail lists The system should have a tool for launching and administrating many-to- many mail lists The mail lists should use external e-mail addresses. Requirement: should Importance: 1 Fulfilled: yes/no Comment E-mail – e-mail lists – administration The teachers and students should be able to create and administrate the mail lists Requirement: should Importance: 2 Fulfilled: yes/no Comment E-mail – e-mail lists – integration with web forum Mail lists should be integrated with web forum Postings can be made to the same forum both via the mail list and the web forum interface. Requirement: should Importance: 1 Fulfilled: yes/no Comment SMS It should be possible to send SMS to a group of users from the system Requirement: should Importance: 2 Fulfilled: yes/no Comment SMS – user choice Individual users should be able to select not to receive SMS from the system Requirement: should Importance: 1 Fulfilled: yes/no Comment Task assignments The system should have a tool for task assignment management so that teachers and students can assign tasks to each other This should include status and deadlines. Requirement: should Importance: 2 Fulfilled: yes/no Comment 37 Task assignments – Gantt diagram It should be possible to present tasks and deadlines in a Gantt diagram Requirement: should Importance: 2 Fulfilled: yes/no Comment Task assignments – standards The task lists should follow the iCal or vCal standards Requirement: should Importance: 1 Fulfilled: yes/no Comment Recording and streaming lectures The system should be able to record lectures as video clips that include course material (streaming video and slides). This should include both a Media Management Framework and Content Management Framework. Requirement: should Importance: 2 Fulfilled: yes/no Comment User and role management The system should have user and role management for controlling access to the media (lecturer, viewer, manager, anonymous user) Requirement: should Importance: 1 Fulfilled: yes/no Comment Meta-data Support for meta-data is required (lecture title, course title, author, language, copyrights, recording date, keywords, searchable text) Requirement: should Importance: 1 Fulfilled: yes/no Comment Media format management ¶ video formats, RealVideo, MPEG, WindowMedia ... ¶ bandwidth negotiation ¶ targeted audience Requirement: should Importance: 1 Fulfilled: yes/no Comment Media publication workflow There should be a workflow for publishing lectures, for managing recording schedules, for creating and announcing media events Requirement: should Importance: 1 Fulfilled: yes/no Comment 38 Archiving There should be a way to archive lectures and get access to them easily This would include exporting lectures to CD and DVD. Requirement: should Importance: 1 Fulfilled: yes/no Comment Digital Right Management (DRM) Support for DRM Requirement: should Importance: 1 Fulfilled: yes/no Comment Importing course material Import of course material should support various formats (PowerPoint, pdf, LaTeX, Postscript, images etc.) to generate presentations for the lecture Requirement: should Importance: 1 Fulfilled: yes/no Comment Managing video/audio material ¶ Support for encoding profiles ¶ recording live video, and audio sources ¶ storing video/audio on a server ¶ converting it (optional) ¶ editing generated media (optional) Requirement: should Importance: 1 Fulfilled: yes/no Comment Synchronizing video and slides During the lecture, the slideshow synchronizing information should be re- cordable Requirement: should Importance: 1 Fulfilled: yes/no Comment Creating multimedia presentation with synchronized video and slides Generating media content by synchronizing video and slideshows into web presentations (e.g. SMIL). Generating multiple format presentations. Requirement: should Importance: 1 Fulfilled: yes/no Comment Media server infrastructure (third-party software if needed) ¶ File storage to store recorded videos, course material ¶ A media server to stream live or recorded videos Requirement: should Importance: 1 Fulfilled: yes/no Comment 39 Education/support Online support Documentation and tutorials for users shall be available online in the system Please specify if the documentation and tutorials are available in both Swedish and English. Requirement: must Importance: 5 Fulfilled: yes/no Comment Online support - context The online help should be context dependent Our intention is that the user gets help customized to the specific part of the system which is currently used. Requirement: should Importance: 3 Fulfilled: yes/no Comment Support The supplier must be able to offer support Requirement: must Importance: 5 Fulfilled: yes/no Comment Help desk The supplier should be able to offer a help desk Requirement: should Importance: 4 Fulfilled: yes/no Comment Education The supplier must be able to deliver education in the system for both admin- istrators, teachers and students Requirement: must Importance: 5 Fulfilled: yes/no Comment Education – API The supplier should be able to supply education in the system API´s Requirement: should Importance: 3 Fulfilled: yes/no Comment Documentation The supplier should be able to offer full system’s documentation, including maintenance documentation Requirement: must Importance: 5 Fulfilled: yes/no Comment 40 Organization Implementation The system provider must have both the resources and competence to man- age the system implementation This includes both technical and educational skills as well as experience from organizational changes during VLE implementations. Requirement: must Importance: 5 Fulfilled: yes/no Comment 41 IT-UNIVERSITETET I GÖTEBORG Kravspecifikation Moduler och krav Prioritet Uppfylls av Fron- ter Ingår i projekt- leverans 1 Generella krav a All inmatning av information för förmedling till systemets användare skall kunna ske i ett webbgränssnitt 1 Ja Ja b All information skall om inte särskilda skäl finns, vara öppen för alla 1 Nej Ja c Inloggning skall endast krävas för att få personanpassad information samt då innehåll i systemet skall påverkas 1 Nej Ja d Gränssnittet skall minst finnas på svenska och engelska 3 Ja Ja e Information som riktar sig till specifika personer/målgrupper skall kunna samlas i en personanpassad vy 1 Ja Ja f Systemet skall möjliggöra integration av information på "nivå IT-universitetet" med information på programnivå 2 Ja Ja g Systemet skall möjliggöra integration av program- och kursinformation 1 Ja Ja h Systemet skall gå att integrera med existerande system för kursinformation och student- service som finns på Chalmers/GU 2 Nej Nej? i God användbarhet till en sådan nivå att det kan antas att användarproblem inte utgör ett hinder för deltagande 1 Ja? Ja j Plattformen ska vara modulärt uppbyggd med moduler som går att koppla ur/koppla på 2 Ja Ja k God överblickbarhet, memorability och learnability 2 Ja? Ja? l Omfattande hjälpfunktioner tillgänglig i webbgränssnittet. 2 Ja Ja m Egna funktionsrubriker ("knappar") ska kunna definieras i olika nivåer i systemstruktu- ren 3 Ja Ja n Möjlighet till inställningar så att alla användargrupper kan ges möjlighet att publicera dokument, filer, länkar, resurser osv. 2 Ja Ja o Plattformen ska vara flexibel för olika pedagogiska metoder 1 Ja Ja p Flexibel tilldelning av behörigheter baserat på (tid), individ, grupp/roll och funktion 1 Ja Ja q Enkel administration av användarkonton (import/export eller koppling till andra data- källor) 1 Ja Ja r Svenskt tid- och datumformat ska kunna användas 2 Ja Ja s Behörighet baserad på IP-adress 3 Nej Ja 2 Modul: Nyheter a Olika målgrupper för riktad information 1 Ja Ja b Insyn i nyheter där informationen är riktad till andra målgrupper än den egna 1 Ja? Ja c Varje nyhet kan delas upp i Rubrik, Ingress/Sammanfattning, Brödtext 2 Ja Ja d Avsändare kopplat till varje nyhet (valbar presentation) 3 Ja Ja e Valbar presentation av avsändare 3 Nej Nej f Utsökning utifrån datum (period), avsändare och/eller innehåll 3 ? ? g Möjligt att styra formatering genom html 3 Ja Ja h Prenumerera på nyheter via sms 3 Ja Ja 3 Modul: Kalendarium a Olika målgrupper för riktad information 1 Ja Ja b Insyn i kalenderdelar där informationen är riktad till andra målgrupper än den egna 1 Ja? Ja c Privat kalender 1 Ja Ja 42 d Synkronisering med Outlook 2 Ja Ja e Kopplade dokument till händelse (föreläsningsunderlag/presentationer/…) 1 Nej ? f Olika typer av händelser (gästföreläsning/seminarium/"nöj e"/...) 1 Nej Nej g Inmatning av repetitiva händelser 3 Ja Ja 4 Modul: Fildistribution a Ladda upp filer, oavsett typ, till systemet för förmedling till olika målgrupper 1 Ja Ja 5 Modul: Diskussionsforum a Möjlighet att koppla forum till olika grupperingar/interaktionsareor 1 Ja Ja b Ej trådat forum ("gästbok") 2 Nej Nej? c Trådat forum 1 Ja Ja d Möjlighet att inkludera citat från inlägg i svar till detsamma 3 Nej Nej e Bevakning/Notifiering av/vid inlägg 3 Ja Ja f Markering av vilka inlägg som är nya sedan senaste besöket/inloggningen 3 Ja Ja g Deltagande (skriva inlägg) låsbart till specifika målgrupper 1 Ja Ja h Inställning för att göra forumet modererat (inga inlägg presenteras innan godkännande) 2 Nej Nej i Behörighet att moderera skall kunna tilldelas vissa användare eller grupper 3 Nej Nej j Spårbarhet (möjlighet för administratör att se vem som skrivit vad även om namn ej presenteras) 2 Ja Ja k Sortering efter datum 3 Nej Nej 6 Modul: Chat a Synkron textbaserad kommunikation 1 Ja Ja b Möjlighet att se vilka som är online vid en viss tidpunkt 1 Ja Ja c Privata rum 2 Ja Ja d Möjlighet att bjuda in användare till privata rum 2 Ja Ja e Spårbarhet (möjlighet för administratör att se vem som skrivit vad även om namn ej presenteras) 2 Ja Ja f Inga komponenter skall behöva installeras på klientdatorn för att använda chatten 2 Ja Ja 7 Modul: Dokumenthantering/Fildelning a Filuppladdning till systemet 1 Ja Ja b Möjlighet att styra läs- och skrivåtkomst till olika användare/grupper 1 Ja Ja c Möjlighet att koppla kommentarer till filer 2 Ja Ja d Versionshantering 1 Ja Ja e Samskrivning av dokument av flera användare samtidigt 3 Ja Ja f Möjlighet att låsa dokument 2 Ja Ja 8 Modul: Projektplats /Virtuella grupprum a Möjlighet för olika grupper av användare att skapa areor med valfri mängd av övriga moduler/funktionalitet för användning under begränsad tid 1 Nej? Nej? b Gant-scheman 3 Ja Ja c "Att-göra-listor" (Uppgifter som tilldelas någon av projektmedlemmarna) 3 Ja Ja 9 Modul: Länklista a Externa länkar 2 Ja Ja b Systeminterna länkar 2 Ja Ja c Kopplad beskrivning 3 Ja Ja d Olika målgrupper för riktad information 1 Ja Ja e Insyn i länklistor där informationen är riktad till andra målgrupper än den egna 1 Ja? Ja 9 Modul: Videostöd a Videokonferenser 3 Ja Ja 43 b Synkron streaming av video med god överföring av både lärare, publik och presenta- tionsmaterial 2 Nej Nej c Möjlighet till realtidskommunikation via audio 2 Ja Ja 10 Modul: Anslagstavla a Olika målgrupper för riktad information 1 Nej Ja b Olika kategorier för att organisera annonserna efter typ 1 Nej Ja c Öppet för samtliga användare att lägga in annonser 2 Nej Ja d Möjlighet att begränsa vissa användargruppers inlägg till specifika kategorier 3 Nej Nej 11 Modul: Kompetensbank a Möjlighet för användare att skiva in sin "profil" (Personuppgifter, Utbildning, Kompe- tenser, Språkkunskaper osv.) 1 Nej Ja? b Koppling till personlig portfölj med arbeten/rapporter/publikationer mm 2 Nej Ja? c Koppling till personlig hemsida 3 Ja Ja d Inställningar för vilka uppgifter som skall presenteras för vilka målgrupper 3 Nej Nej? e Möjlighet att presentera användare i olika grupperingar 2 Ja Ja f Sökfunktion 1 Ja Ja 12 Modul: Maillistor a Förteckning över mailadresser i olika grupperingar 1 Ja Ja b Möjlighet att göra urval av mottagare i lista 2 Ja Ja c Öppet för användande av administratör/lärare 1 Ja Ja d Öppet för användande av i urvalet förekommande användare 1 Ja Ja e Möjlighet att sända mail utan mailklient installerad på klientdatorn 2 Ja Ja f Möjlighet att använda maillistan i ordinarie mailklient (export av adresslista) 2 Ja Ja 13 Modul: Peer-review a Möjlighet för studenter att utbyta dokument/filer för att kommentera varandras arbeten 1 Nej? Nej? b Automatisk fördelning av dokument/filer mellan grupper/studenter som lämnat in 3 Nej Nej 14 Modul: "Bibliotek" med rapporter/dokument a Möjlighet att publicera rapporter/dokument för externa besökare 2 Nej Ja b Kopplade attribut (Författare, publiceringsdatum, nyckelord, mm) 2 Nej Nej? c Sökfunktion 1 Nej Nej? 15 Modul: Ladok-tjänster a Resultat-utdrag 1 Nej Ja b Sammanställning över registrerade/valda kurser 1 Nej Ja 16 Modul: Åtkomst från mobila enheter a Möjlighet att sända/hämta delar av informationen till/från mobila enheter 3 Ja Ja 17 Modul: FAQ a Möjlighet att ställa och besvara frågor som samlas i en FAQ 3 Nej Nej b Möjlighet att koppla FAQ till olika nivåer i systemet 3 Nej Nej c Sökfunktion 3 Nej Nej 18 Modul: Enkätfunktion/Självtest a Möjlighet att skapa formulär/enkät med flervalsfrågor 2 Ja Ja b Möjlighet att styra till specifik målgrupp 2 Ja Ja c Självrättande 2 Ja Ja 44 19 Modul: Statistik a Användarfrekvens på individnivå 3 Ja Ja 20 Modul: Information a Kursmaterial ska kunna kategoriseras med metadata 3 Nej Nej b Information ska kunna presenteras i olika nivåer i systemet för olika målgrupper 1 Ja Ja c Fri layout (formatering mha html ska tillåtas) 2 Ja Ja d Flexibilitet vad gäller att namnge kurser/interaktionsareor i systemet (långa beteckning- ar möjliga) 3 Ja Ja 45 KARLSTADS UNIVERSITET Kravspecifikation Vid urvalsförfarandet kommer följande områden (ej rangordnade här) att beaktas: Kostnadsbild för egen drift alternativt drift av leverantör. Strategiska hänsyn för att möjliggöra en homogen student- och samarbetsmiljö mellan olika lärosäten. Leverantörens supportmöjligheter. Leverantörens ekonomiska status. Teknisk tillförlitlighet, framför allt vid drift av system med många användare. Resultat från användarvärdering. Funktioner enligt nedan, inklusive möjlig integration med LADOK och andra system. Funktionslistan nedan är därmed ett av 7 områden som kommer att beaktas. En övergripande be- dömning av funktionerna kommer att göras. Listan nedan kan ses som en beskrivning av de viktigas- te funktionerna i det LMS vi söker. Område/funktion Förklaring Systemoberoende (OS, webbläsa- re) på klientsidan Systemet bör kunna användas av både PC- och Macanvändare. Sy-stemet skall kunna användas med en standardbrowser (Explorer, Netscape). Krav hos användarna på nyare webbläsare än Netscape 4.7 eller Explorer 5.0 bör inte ställas. Ange vilka eventuella plug-ins som krävs för kunna använda systemets alla funktioner. Standard Systemet skall följa den utveckling av standarder för LMS som sker. (SCORM, IMS etc.) Ge, om möjligt, referens där överflyttning av innehåll från ert system skett till ett annat LMS eller v.v. Klientoberoende Systemet skall kunna användas utan speciellt installerad klient. Virusskydd Systemet bör ha integrerad programvara för virusskydd. Beskriv vil- ken programvara som används. Om inte programvaran levereras skall rekommendation på virusskydd beskrivas. Systemintegration Koppling till LADOK, som möjliggör automatiskt inlägg av stude- randeuppgifter, bör vara möjligt. Beskriv hur integrationen sker och vilka krav som ställs på datafiler och/eller kringsystem etc. från LADOK-systemet. Ge referenser till svenska högskolor eller universi- tet där detta genomförts. Brandväggar Används någon form av kommunikation som inte följer standardise- rad webbkommunikation genom brandväggar (annat än port 80)? Remote administration Alla administrativa delar bör kunna skötas via webbgränssnitt. Hur garanteras säkerheten och vilka krav ställs på eventuella säkerhets- produkter för att säker administration skall kunna ske. Används kryp- tering och i så fall vilken form? Multimedia Multimediafiler som skapas i extern miljö (flash, real media, Micro- soft media, director, quicktime) bör kunna publiceras i plattformen. Metadata Finns möjligheter att använda metadata och är dessa i så fall sökbara? Ange om standard följs. Ange referens där metadata har använts. Språk på menyer 1 Svenska bör finnas som menyspråk. Vilka ytterligare språk finns? Språk på menyer 2 Hur kan ett nytt menyspråk tillföras? Språk på menyer 3 Menyspråk bör kunna ändras beroende på inställd personlig profil. Teckenhantering i textchat Textchat bör kunna hantera olika teckensnitt (t.ex. kyrilliska tecken). Tid och datum Svenskt tid- och datumformat bör kunna användas. Öppen (icke inloggad) nivå En nivå bör kunna vara öppen för användare utan lösenord. 46 Olika behörighetsnivåer Olika behörighetsnivåer för t.ex. administratör, lärare, handledare, studerande ska kunna ställas in vid registrering av nya användare samt kunna ändras fortlöpande. Kan nya roller skapas? Auto inlägg av stud + komplette- ring av lärare Oberoende av rutinerna vid inläggning av användare i systemet bör det vara enkelt att komplettera en grupp användare med ytterligare en person. Personuppgifter Användare bör kunna ändra egna personuppgifter. Indelning i studiegrupper Indelning i studiegrupper ska kunna göras. En studerande ska kunna delta i flera samtidiga studiegrupper i olika kurser. Koppling handledare-studiegrupp En handledare ska kunna kopplas till en eller flera studiegrupper. "Webbeditering" Enkel webbeditering, med eller utan mallar, bör vara möjlig. HTML-sidor Hela HTML-sidor bör kunna importeras till systemet. Hantering av java applets Java applets i html-sidor som importerats eller skapats i systemet bör stödjas. Själva java appleten skapas i extern miljö. Formeleditor Formeleditor för statistiska och matematiska formler bör vara inbyggt i systemet. Stöd för funktionshindrade Stöd för funktionshindrade bör finnas. Ange hur och vilka standarder som följs. Användarvänlighet, moduler, hjälpfunktioner Systemet bör vara användarvänligt. Uppfattningen om användarvän- lighet varierar mellan olika användare och är en subjektiv upplevelse. Systemet kan dock utformas för att underlätta användandet på olika vis. T.ex. behöver moduler som inte används inte synas i utgångslä- get, olika nivåer kan finnas beroende på användarnas preferenser och erfarenhet, en "stödjande" layout kan underlätta och enkla hjälpfunk- tioner kan finnas. Stöd vid kursimplementation för både kurser med problemoriente- rad och kurser med sekventiell struktur Systemet bör stödja olika typer av kursimplementering med guidlines. Med problemorienterat menas här en kursstruktur som utgår från en frågeställning/problem som de studerande ska arbeta vidare med. Det kan innebära att de söker material både i och utanför systemet. Ingen stark kronologisk styrning finns i hur materialet behandlas. Med se- kventiell menas här en kursstruktur som utgår från en relativt fastlagd studiegång. Oftast finns rekommenderat studiematerial med ankny- tande test. Verktyg för reflektion En viktig del i lärandet är egen reflektion. Systemet bör stötta detta på något sätt, t.ex. med dagboksfunktion. Samarbetsverktyg (red av doku- ment i realtid) Dokumenthantering i realtid för flera användare bör finnas, samt ljud och/eller textchat. Dokumenthantering (vem skrivit vad, versioner) Stöd skall finnas för att hantera dokument som flera användare skri-ver och ändrar i vid olika tillfällen. Förslag på färgmarkeringar, namnmarkeringar och backmöjligheter till närmast föregående ver- sion fanns som förslag vid behovsanalysen. Gemenskapsskapande funktioner Bilder och presentationer av användare underlättar samarbete. Dyna- misk bildhantering (av användarbilder) bör finnas. Stöd för bildpublicering Storleken på bilder bör anpassas automatiskt som default. För studen- ter och lärare som ska publicera bildmaterial är ett stöd för detta en garanti för att inte orimligt stora bilder läggs in. Användarfrekvens Visning av användarfrekvens på individnivå bör finans. Information bör ges om antal inlägg i diskussionsforum, uppladdningar etc. Se presumtiva drop-outs Systemet bör kunna automatsikt visa vilka som inte loggat in efter x antal dagar. Lagring Varning vid överskriden lagring bör ske. (In-) Aktivitetsinfo Information vid t.ex. nedladdning då till synes ingenting händer under lång tid bör finnas. Detta är extra viktigt vid modemanvändning. 47 Flaggning av nytt mtrl Användare bör kunna se vilket material som är nytt på en central nivå (underliggande nivåer bör inte behöva besökas för att få information om ev. nytt material). Historik Det bör vara möjligt att se vem som gjort vad med det aktuella kurs- materialet. Nytt dokument Att skapa nytt dokument direkt i systemet bör vara möjligt. Datumstyrning Publiceringsdatum bör kunna anges för kursmaterial. Sökfunktion Sökfunktion för material och personer inom systemet bör finnas. Adressbok Adressbok (alla, i grupp) bör finnas. Anslagstavla Möjlighet för studenter och lärare att publicera meddelande som alla användare ser, respektive viss grupp ser, bör finnas. Trädstruktur Trädstruktur-layout underlättar navigering och överblick och bör finnas. Frågedatabas m slumpgenerator Frågor bör kunna slumpas fram för att kunna användas vid tester mm. Vilka uppkopplade Inloggade bör kunna se vilka andra som inloggade i samma kurs. SMS Meddelanden bör kunna skickas via SMS Mobila enheter Möjligheter bör finnas för att sända och hämta delar av information med mobila enheter. INBYGGDA ELLER FRISTÅ- ENDE VERKTYG Ange om ev. funktioner sker med hjälp av en integrerad tredje- partslösning. Frågeverktyg, inklusive statistik- verktyg, o grafik Både för "snabba" frågor och standardiserade utvärderingar. Ange vilken typ av frågor som kan hanteras (inmatning av frågor, visning, inmatning av svar och visning av svar). Kan bilder infogas? Vilket format kan exporteras till externa statistik och analysprogram? Gene- reras grafik? Ge referenser till högskolor och universitet där detta har genomförts. Bildkonferens Ljudkonferens Streamingfunktion DRIFT HOS UNIVERSITETET Kostnadsmodell Ange kostnadsmodell. Kan antalet användare ökas stegvis? Karlstads universitet har idag ca 2000 distansstudenter och 200 lärare men det eftersökta systemet ska på sikt kunna användas även av campus- studenter och alla anställda, idag ca 11500 personer. Krav på server mm. Vilken serverplattform (OS), övriga programvaruprodukter, licenser, internminne, lagringsutrymme krävs? Skalbarhet Ange krav för olika nivåer av antal användare på server, serverpro- gramvaror, 3.e-partslicenser, kommunikation etc. Databashanterare Används någon 3.e parts databashanterare? Vilka är möjliga? Uppdateringar Hur ofta sker mjukvaruuppdateringar? Vilka krav/möjligheter till patchning av OS lämnas av systemet? Säkerhetskopiering Rekommenderade säkerhetskopieringssystem? Supportkostnader Supportkostnader vid egen drift? Supporttider? BKS, behörighetskontroll Beskriv systemets behörighetskontrollsystem. Önskvärt är också kommentarer till hur väl systemet kan nyttja det system för identifika- tion/auktorisation som utvecklas i universitetsvärlden. Se vidare; http://www.umu.se/it/projupp/spocp/ DRIFT HOS LEVERANTÖR Kostnadsmodell Ange kostnadsmodell. Kan antalet användare ökas stegvis? Karlstads universitet har idag ca 2000 distansstudenter och 200 lärare men det eftersökta systemet ska på sikt kunna användas även av campusstu- denter och alla anställda, idag ca 11500 personer. Kommunikationskostnader Tillkommer kostnader för kommunikation? 48 Kommunikationshastighet Vilken är kommunikationshastighet garanteras? Serverkapacitet mm. Servertyp, kapacitet och konfiguration? Internmin- ne/lagringskapacitet? Säkerhetskopiering Hur sker säkerhetskopiering och vilka är möjligheterna till återinlägg- ning av ev. förlorade filer? Supportkostnader Supportkostnader vid drift hos leverantör? Supporttider? BKS, behörighetskontroll Beskriv systemets behörighetskontrollsystem. Önskvärt är också kommentarer till hur väl systemet kan nyttja det system för identifika- tion/auktorisation som utvecklas i universitetsvärlden. Se vidare; http://www.umu.se/it/projupp/spocp/ 49 HÖGSKOLAN I KRISTIANSTAD Kravspecifikation Tekniska möjligheter Nödvändigt i plattform Publicering på flera nivåer - både ngt som går snabbt och ngt som tillåter bra layout etc. Stöd för grafisk design Textkommunikation, både enskilt och i grupp Möjlighet att lyssna på kursmaterialet Tester av olika slag Utvärderingar integrerat med kursen och exporterbart Hänsyn till olika tekniska villkor: Finns det program som är effektivare än andra när jag skapar mitt material? Hänsyn till de som inte är Microsoftierade Önskvärt i plattform Ljudöverföring med god kvalité Avatarer Löses på annat sätt Kunna köra videokonferens där bilden varvas med bild från en dator Möjlighet för stud. att köra program från vår server på distans, typ Citrixlösning Stöd för att spärra för nedladdning/utskrifter Support Kan man göra en gemensam kursinformation för alla Tydlig information om upphovsmannarätt 50 Här får du support (t.ex. bibla, inst sekr, serviceanmälan) VPN-klient Support kring datorhantering Program som reparerar, fixar och konverterar Bra att ha tips - FAQ Utbildning för kursadministratörer och lärare "Pedagogisk information" DVS inte bara te knik, utan hur man kan lägga upp kursen bättre Administration av kursen Nödvändigt i plattform Stöd för att göra vettigt distansutbildningsupplägg Möjlighet att dokumentera t.ex. en chatt Allt ska kunna loggas Hela kursen ska kunna dokumenteras o brännas på en CD Möjlighet att lägga upp kurs utan att allt är tillgängligt System som tillåter export till ett annat system (använder standarder) Löses på annat sätt Stöd för att producera lämpligt material Administration av studenter Nödvändigt i plattform Få e-postadresser redan till kursstart Tillgång till systemlogg (kunna se när stud. senast varit inloggad och vilka dokument som lästs) LADOK-koppling 51 Bra statistik Önskvärt i plattform Automatisering av progression 52 LULEÅ TEKNISKA UNIVERSITET Kravspecikation Kravspecifikation Lärplattform för Luleå tekniska universitet Kolumnen är formaterad så att text radbrytes om den inte får plats på en rad. Max 256 tecken ryms inom en rad (gäller äldre excel program som 95, 98). Är er text längre än så, infoga då anteckning alternativt hänvisa till anbud eller bilaga. I följande svarsformulär kravspecifikation ska leverantören fylla i kolumn SVAR, "upp- fylls", "uppfylls delvis" alternativt "uppfylls ej" på ef terfrågad funktion. Redovisa hur skall-krav respektive bör-krav uppfylls. Önskar leverantören kommentera, beskriva funktion närmare, så kan detta anges som hän- visning till position/stycke i anbud alternativt fyllas in i kolumnen SVAR efter leverantören angett uppfylls (t.ex. Uppfylls ej, men beräknas lanseras under Q2-2003 se närmare beskrivning....) Svar måste lämnas på alla punkterna. Anbudsgivare Företag Leverantör AB Adress xx Ansvarig för anbudet/kontaktperson nn Tel ss Fax aa E-post yy 1 Marknadsföring/informationssökning Krav Svar Marknadsföring/informationssökning - Inom LTU finns ett behov av att förmedla/ta del av informa- tion som är aktuellare än vad de centrala informationskanalerna klarar av, därför önskar man att det i systemet hanteras kursinformationssidor som är redigerbara på institutionsnivå. 1.1 Publicering av publik kursspecifik informa- tionssida accessbar utan inloggningsförfaran- de, alternativt inloggning via gästanvändare. Skall 1.1.1 Klientoberoende, systemet kräver inte speci- fikt installerad klientprogramvara hos använ- dare (dvs. helt webbaserat). Skall 1.1.2 Sorterings/sökfunktion på kur- ser/kursinformationssida Bör 1.1.3 E-postformulär för informationsbeställning kan implementeras i informationssida. Bör 1.1.4 Video & ljud i informationssida. Bör 2 Användarhantering Krav Svar Behörighetsinformation av studenter lagras i central LDAP server (IDEAL). Behörighet för personal kommer strax att finnas tillgänglig via en central LDAP server. Även viss kursinformation som kurs- registreringar m.m. finns åtkomligt via studenternas LDAP server. 2.1 Integration mot LADOK och LTU´s lokala användardatabas (IDEAL) genom LDAP katalogtjänst eller liknande. Skall 2.1.1 Automatisk inmatning av användare till kurs genom synkronisering eller behörighets veri- fiering av användare mot extern källa (ex. LDAP). Bör 53 2.1.2 Möjlighet att lägga in externa användare (ex. näringslivet, forskarkollegor etc.) genom autentisering i sekundär källa. Bör 2.2 Manuell import/export av användare (via LDAP eller API). Skall 2.3 Stöd för webservices(SOAP) eller ODBC. För att hämta uppgifter från Ladokdatabasen (Mimer). Bör 3 Planering/struktur Krav Svar 3.1 Strukturering, organisering presentation m.m. av information Skall 3.1.1 Information är strukturerbar i moment per undervisningstillfälle där undervisningsmate- rialet är samlat (dokument, länkar osv.). Bör 3.1.2 Kursmateriel (dokument etc.) hanteras och presenteras i en hierarkisk struktur. Bör 3.1.3 Flaggning av nya händelser, dvs. de händelser som användaren inte besökt och därmed avak- tiverat. Bör 3.1.4 Tidslinje eller liknande kronologisk funktion informerar om moment och eventuella "dead- lines". Bör 3.1.5 Dynamiska menyer, styrning av meny- er/funktioner som skall presenteras i kurs- gränssnittet Bör 3.1.6 Presentation över "Vem är online" dvs. vilka av kursmedlemmarna som är inloggade. Bör 3.2 Kalenderfunktion Skall 3.2.1 Kalendern är redigerbar av användare. Bör 3.2.2 Import/export av standardiserad kalenderin- formation. Bör 3.2.3 Kalendern kopplad mot användaren generellt, ej kursspecifik då en användare kan läsa flera kurser. Bör 3.2.4 Sammanställningsfunktion av flera individu- ella kalendrar exempelvis vid grupparbeten. Möjligheten finns hos både lärare och student. Bör 3.2.5 Dagboksfunktion Bör 3.2.6 Avstängning av kalenderfunktion Bör 3.3 Dokument och länksamlingsfunktion Skall Dokument och länksamling - Möjlighet att på ett samlat ställe lägga upp ett arkiv med dokument eller länkar. En kortfattad beskrivning av dokument respektive länk. 3.3.1 Lista av dokument med dokumentbeskrivning kan publiceras. Bör 3.3.2 Lista av länkar med länkbeskrivning kan publiceras. Bör 3.3.3 Länkning till extern nätbaserad kurs. Bör 4 Genomförande Krav Svar 4.1 Kompabilitet mot varierande IT-miljöer. Skall LTU har stor variation av användarmiljöer inom IT, spridning av nyttjandet av ett system kräver att man kan nyttja systemet hos samtliga användare. 54 4.1.2 Systemet kan accessas via Windows, Mac och UNIX. Eventuellt krav på webbläsarversion beskrivs av leverantör. Skall 4.2 Funktionshinder beaktade. Bör 4.2.1 De riktlinjer som ställs i w3c's "Web Content Accessibility Guidelines" uppfylls. Internetadressen: http://www.w3.org/TR/WCAG10 Bör 4.3 Filhanteringsfunktion Skall Filhantering - Vid genomförande av kurs kan en mängd olika filtyper komma att distribueras via sy- stemet av samtliga inblandade aktörer, vid krav på "plug-ins" eller specifika webbläsare anger leve- rantören detta. 4.3.1 För distribution av textdokument, bilder, ljud, ljud/bild, flash och java applets. Bör 4.3.2 Möjlighet att specificera begränsningar av filtyp. Bör 4.3.3 Webbeditering, med WYSIWYG-funktion (What You See Is What You Get). Bör 4.3.4 Import av färdiglänkad HTML-site (relativa länkar). Bör 4.3.5 Formeleditor för statistiska och matematiska beräkningar Bör 4.3.6 Filkonvertering till icke licenskrävande for- mat (ex. PDF) Bör 4.4 Tjattfunktion Skall Tjattfunktion - Behov av synkron kommunikation kan komma i fråga vid exempelvis handledning och arbete i grupp. 4.4.1 Lärare kan starta upp, namnge och tilldela rättighetsnivå för vilka som får access till sessionen. Bör 4.4.2 Användare (studenter) kan starta, namnge och tilldela rättighetsnivå för vilka som får access till sessionen. Dvs. utrymmen för slutna gruppsessioner finns. Bör 4.5 Diskussionsforum Skall Diskussionsforum - Ett verktyg där användare som har rättighet till forumet kan delta i eller följa andra intressenters diskussion kring en fråga. Har både en handledande och en social funktion. 4.5.1 Lärare kan starta upp, namnge och tilldela rättighetsnivå för vilka som får access till forumet. Bör 4.5.2 Användare (studenter) kan starta, namnge och tilldela rättighetsnivå för vilka som får access till forumet. Dvs. utrymmen för slutna grupp- diskussioner finns. Bör 4.6 E-postfunktion Skall 4.6.1 E-posthantering stöds via intern hantering eller genom integration med extern e- postadress. Bör 4.6.2 Kompabilitet mot externa e-posthanterare Bör 4.7 Anslagstavla Skall 4.7.1 Anslagstavla i kursutrymme, redigerbar av lärare/administrator. Bör 55 4.8 Dokumenthanteringsfunktion Skall Dokumenthantering - Stöd för arbete med delade dokument, dvs. två eller flera deltagare kan redigera dokumentet. 4.8.1 Tydlig versionshantering genom namnmarke- ring eller dylikt. Bör 4.9 Formulärhantering - En funktion som stödjer skapandet av formulär. Skall Formulärhantering - En funktion som stödjer skapandet av formulär. Användningsområden för dessa formulär är exempelvis informationsbeställning, gruppindelning, val av projektuppgift, kunskapstest, examination, kursutvärdering osv. Om systemet hanterar användningsområdena på annat sätt, beskriv hur! Formulärhantering - beståndsdelar: 4.9.1 Fritext Bör 4.9.2 Flervalsalternativ - endast ett valbart svar. Bör 4.9.3 Flervalsalternativ - två eller flera valbara svar. Bör 4.9.4 Rull-listor Bör 4.9.5 Kortsvar med exakt lydelse alternativt vissa ord uttryck. Bör 4.9.6 Matematiska uttryck Bör 4.9.7 Bilder Bör 4.9.8 Testgenerator med slumpvis valda frågor från frågedatabas. Bör 4.9.9 Generator som i en given uppgift tilldelar matematiska variabler slumpmässiga värden. Bör 4.9.10 Lagring av data sker i databas. Ange om 3: e parts databashanterare är inblandad, vilka alternativ finns. Bör Formulärhantering - styrning: 4.9.11 Begränsning av publiceringstid. Bör 4.9.12 Begränsning av ifyllnadstillfällen. Bör 4.9.13 Anonymitet hos uppgiftslämnare (ex vid kursutvärderingar) Bör 4.9.14 Automatiskt registrering av inmatade data. Bör Formulärhantering - återkoppling 4.9.15 Återkoppling kan göras direkt i formulär. Bör 4.9.16 Tid som resultat finns tillgängligt. Bör 4.9.17 Tillgänglighet av resultat eller nya uppgifter efter avklarade moment. Bör 4.9.18 Utforma sammanställning av formulär avse- ende utseende och organisation. Bör 4.9.19 Utformningsmöjlighet av kriterier som styr en automatisk sammanställning av data i ett formulär, exempelvis vid examinationer och kursutvärderingar. Bör 4.9.20 Automatisk registrering av bedömningar med möjlighet till manuell hantering. Bör 56 4.9.21 Resultat från olika formulär kan sammanstäl- las, t.ex. sammanställning av delmoment genererar ett slutbetyg. Bör 4.9.22 Sorteringsfunktion på resultat, exempelvis kan lista över godkända resultat tas ut. Bör 4.9.23 Student kan själv hämta/läsa resultat. Bör 4.9.24 Avklarade moment indikeras i student- och lärargränssnitt. Bör 4.13 Whiteboardfunktion Skall Whiteboard - för synkron distribution/kommunikation vid handledning, projektarbeten och dylikt. 4.13.1 Skrivfunktion med möjlighet att påverka font. Bör 4.13.2 Ritfunktion Bör 4.13.3 Möjlighet att lägga in bilder Bör 4.13.4 Tjattfunktion i anslutning till whiteboard. Bör 4.13.5 Röstfunktion i anslutning till whiteboard. Bör 5 Rättigheter Krav Svar 5.1 Rättig/behörighetshantering Skall 5.1.1 Olika behörighetsnivåer/roller finns. Skall 5.1.2 Rättigheter hos användarroller kan styras. Skall 5.1.3 Egna användarroller kan skapas. Bör 6 Uppföljning Krav Svar Uppföljning - Som kursanordnare följer man upp studenternas resultat från test och examinationer samt deras åsikter från kursutvärderingar. 6.1 Statistikfunktion Bör 6.1.1 Statistik kan presenteras i form av tabeller eller diagram. Bör 6.1.2 Statistik kan presenteras per grupp. Bör 6.1.3 Statistik kan presenteras per helklass. Bör 6.1.4 Statistik kan presenteras från samtliga poster i systemet. Dvs. aggregerad data från hela systemet kan nyttjas till informationssamman- ställningar. Bör 6.1.5 Data kan skalas upp per uppgift. Bör 6.1.6 Data kan skalas upp per grupp av uppgifter. Bör 6.1.7 Data kan skalas upp per kurs. Bör 6.2 Aktivitetskontroll Bör 6.2.1 Systemet kan via automatik visa inaktiva kursdeltagare Bör 6.2.2 Aktivitetsfrekvens på individnivå, visning av antal inlägg, uppladdningar och övriga aktivi- teter påvisar hur aktiv studenten är. Bör 7 Återanvändning Krav Svar Återanvändning - Producerat material organiseras för återanvändning. Lagring av producerade kurser, bibliotek som är strukturerade och sökbara samt hantering av standards. Detta för att kunna nyttja material som är producerat i ett annat LMS. 7.1 Lagringsfunktion Skall 57 7.1.1 Möjlighet att packa ner/upp kursen (både struktur och innehåll) i någon form av ar- kiv/komprimerat format för lagring lokalt eller på gemensam server mellan kurstillfäl- len. Bör 7.1.2 Lagring av historik från diskussionsforum, tjattar etc. Bör 7.1.3 Lagring av data som är producerat, distribue- rat eller kommunicerat i systemet hanteras av databas. Ange om 3: e parts databashanterare är inblandad, vilka alternativ finns. Bör 7.1.4 Möjlighet att sätta metataggar på kursinne- håll. Bör 7.1.5 Access av kursdatabas möjlig via SQL eller motsvarande. Bör 7.2 Biblioteksfunktion Bör 7.2.1 Bibliotek för textdokument Bör 7.2.2 Bibliotek för bilder Bör 7.2.3 Bibliotek för video/streaming filer Bör 7.2.4 Bibliotek för ljudfiler Bör 7.2.5 Bibliotek för övriga filformat Bör 7.2.6 Bibliotek för formulärmallar Bör 7.2.7 Märkning av filer via metadata Bör 7.2.8 Sökfunktion på lagrat material. Bör 7.3 Standardhantering Skall 7.3.1 Stöd för standards (SCORM, IMS, AICC). Ange vilka versioner. Skall 8 Säkerhet, uppgradering och anpassning Krav Svar 8.1 Säkerhetshantering Skall 8.1.1 Stöd för Secure Socket Layer eller motsva- rande för kryptering mellan server och klient. Skall 8.1.2 Rutin för backup och recovery-hantering är utarbetad och väl dokumenterad. Skall 8.1.3 Back-up på kursnivå för återskapande av kurs. Skall 8.2 Uppgraderingsfunktion Skall 8.2.1 Rutiner för uppgraderingar, Patchar är utarbe- tade och väl dokumenterade Skall 8.3 Anpassningsfunktion Bör 8.3.1 Åtkomst till källkoden möjliggör gränssnitts- och integrationsanpassningar. Bör 8.3.2 LTU har möjlighet att bygga egna moduler till systemet. Bör