Kravspecifikation til Sagsbehandling, økonomisystem og CMS af Søren Lauesen, ITU

Version 1.4 03-02-2013, 20:57Sidst rettet af: slauesen

Kravspecifikation tilSagsbehandling, økonomisystem og CMS

(i det følgende kaldet Sagssystemet)

KundeX-Fonden

Leverandør…

Leverancen omfatterLevering, drift og vedligehold af Sagssystemet

IndholdA. Baggrund og vejledning til leverandøren...............3

A1. Baggrund og vision..............................................3A2. Vejledning til leverandøren..................................5

B. Overordnede behov..................................................6B1. Forretningsmæssige mål.....................................6B2. Tidligt bevis for gennemførlighed (proof of

concept)...............................................................7B3. Minimumskrav......................................................7B4. Tildelingskriterie...................................................7

C. Task systemet skal støtte........................................8Arbejdsområde 1: Sagsbehandling.............................8

C10. Modtag henvendelse om en sag........................8C11. Forbered møde i arbejdsgruppe eller bestyrelse

...........................................................................10C12. Efterbehandling efter møde i arbejdsgruppe eller

bestyrelse..........................................................10C13. Overvåg afstemning.........................................11C14. Tildel ny sagsbehandler...................................11

Arbejdsområde 2: Økonomi.......................................12C20. Modtag anvisning eller faktura.........................12C21. Modtag kvittering for betaling...........................12C22. Rapportér til bestyrelse....................................13C23. Bogfør værdipapir-transaktioner......................13C24. Registrér andre oplysninger.............................14C25. Ad-hoc rapport.................................................14

Arbejdsområde 3: Arbejdsgrupper og bestyrelse. . .14Arbejdsområde 4: Web-redaktion..............................15

C40. Rediger fondens web-site................................15Arbejdsområde 5: Ansøgere og offentligheden.......17

C50. Besøg fondens web-site..................................17C51. Ansøg om støtte..............................................17

Arbejdsområde 6: Sagkyndige..................................17D. Data systemet skal anvende..................................18

D0. Fælles felter.......................................................19D1. Sag....................................................................19D2. Ansøgning..........................................................20D3. Udbetaling..........................................................21D4. Gruppe...............................................................21D5. Sagsrolle............................................................22

D6. Grupperolle........................................................22D7. Person_Org.......................................................23D8. Honorar..............................................................23D9. Uddelingsområde...............................................24D10. Land.................................................................24D11. Dokument........................................................25D12. Skabelon..........................................................25D13. Rapportering....................................................26

E. Andre funktionelle krav..........................................27E1. System-genererede hændelser.........................27E2. Udskrifter og rapporter.......................................27E3. Forretningsregler og komplekse beregninger....27E4. Systemadministration.........................................28

F. Systemets integration med eksterne systemer. . .29G. Teknisk it-arkitektur...............................................30

G1. Leverandøren eller tredjepart har driftsansvar. .30H. Sikkerhed................................................................31

H1. Adgangsret for brugere......................................31H2. Sikkerhedsadministration...................................31H3. Sikring mod tab af data......................................31H4. Sikring mod utilsigtet brugeradfærd...................32H5. Sikring mod trusler.............................................32

I. Brugervenlighed og design.....................................33I1. Indlæring og effektivitet i daglig brug...................33I2. Tilgængelighed og Look-and-Feel.......................33

J. Andre krav og leverancer.......................................34J1. Andre standarder der skal følges.......................34J2. Uddannelse........................................................34J3. Dokumentation...................................................34J4. Datakonvertering................................................35J5. Installation..........................................................35J6. Udfasning...........................................................35

K. Kundens leverancer...............................................36L. Drift, support og vedligehold.................................37

L1. Svartider.............................................................37L2. Tilgængelighed (driftseffektivitet).......................38L3. Datalagring.........................................................38L4. Support...............................................................39L5. Vedligehold.........................................................40

De følgende 15 sider indeholder et uddrag af de fulde 40 sider

Denne kravspecifikation er baseret på Kravskabelon SL-07 (© Søren Lauesen, 2012). Skabelonen kan frit kopieres så længe kilden og kopiretten er tydeligt angivet.

A. Baggrund og vejledning til leverandørenA1. Baggrund og visionX-Fonden uddeler støtte til mange formål, fx naturvidenskabelig og samfundsvidenskabelig forskning og miljøprojekter. Der bliver stadig flere uddelingsområder.…Kunden har i øjeblikket flere adskilte systemer som vist i figur A1 … Kunden ønsker at erstatte flere af systemerne med mere integrerede systemer for at opnå:

1. Bedre støtte til sagsbehandlingen og det tilhørende regnskab.2. Bedre kommunikation med målgrupperne via web-sitet.3. Bedre styring af værdipapirerne.

En mulig fremtidig situation er vist i figur A2. Sagssystemet består af et elektronisk dokumentarkiverings-system (eDoc) integreret med et økonomisystem og et CMS (Contents-Management System). Sagssystemet arkiverer såvel dokumenter som e-mail, og integrerer med et web-site som ansøgere bruger til at søge og til at se status på deres ansøgning. Leverandørens ansvar er vist: Kassen med dobbelt-linje ramme er det system der skal leveres. Dobbelt-linje pile er de integrationer kunden forventer at få leveret.

Sagssystem til X-Fonden

2

Figur A1: Eksisterende system

Figur A2: Vision om nyt system

Dobbelte linier:Leverandøren integrerer

Multidata

Excel

Banker

Outlook

PortmannCMS

Økonomi

eDoc

Sagssystem

Skat

Multidata

Excel

Banker

LotusNotes

Portmann

Dominoweb-server

NAV

Windowsfiles

Skat

Økonomi

Økonomi

Ansøgere

ØkonomiFormue-forvaltning

Sagsbehandlere

Sagsbehandlere

ØkonomiFormue

Sagsbehandlere

Ansøgere

CPR

CVR

Sagsbehandlere

B. Overordnede behovDette kapitel forklarer hvordan kravene tænkes at tilgodese kundens forretningsmæssige mål, hvordan risikable krav ønskes afklaret tidligt og hvordan tilbud sammenlignes.

B1. Forretningsmæssige målKundens formål med at anskaffe systemet er at opfylde en række forretningsmæssige mål. Kunden forventer at systemet bidrager til målene som anført nedenfor. Leverandøren kan sjældent opfylde målene alene, idet kundens medvirken også er afgørende. Målene er altså ikke krav til leverandøren, selvom de står i en tabel for overskuelighedens skyld.

Alle mål er vigtige og jo før de kan nås, desto bedre. For nogle mål er det kritisk at de nås på et bestemt tidspunkt, fx af forretningsmæssige eller lovgivningsmæssige grunde. Sådanne tidsfrister er anført i tabellen.

Formål med det nye system

Løsningsvision Relaterede krav Evt. tidsfrist

1. Bedre støtte til sagsbehandlingen og det tilhørende regnskab.

a. Arkivér alt data om en sag elektronisk i én "mappe".

b. Etabler en fælles liste af kontaktpersoner.

c. Simplificér bogføring og udbetaling.

C10 til C13, C20, C21, F1-F7.

2. Bedre kommunikation med målgrupperne via web-sitet.

Et nyt web-system (CMS - Contents Management System)

C40, C50, C51, F2,Kap I.

3. Bedre styring af værdipapirerne.

Opdeling i flere forvaltninger. Sikring af historik for transaktioner.

C23, C24, F7, F9.

B2. Tidligt bevis for gennemførlighed (proof of concept)Nogle krav er meget risikable og leverandøren kan være ude af stand til at levere hvad han lovede i sit tilbud. Hvis det opdages sent i projektet, kan kunden hæve kontrakten, men det er en katastrofe for begge parter. Som regel ender det med at kunden vælger at leve med det uegnede system, evt. med afslag i prisen. For at reducere risikoen, kræver kunden et tidligt bevis for at de risikable krav er gennemførlige (proof of concept).

Ifølge kontrakten kan begge parter opsige aftalen hvis de tidlige beviser ikke er tilfredsstillende.

Følgende krav betragtes som de mest risikable. Væsentlige mangler her kan næppe udbedres sent i projektet. Leverandøren skal i sit svar angive hvordan han vil udføre disse tidlige beviser, og hvornår det kan ske. Tidspunktet angives som antal arbejdsdage efter kontraktunderskrift. Kunden forventer 40 arbejdsdage eller mindre.

Områder hvor tidligt bevis kræves: Eksempel på bevis: Kode:

1. Effektiv støtte til arbejdsopgaverne. Et tilsvarende, eksisterende system vurderes af kundens ekspertbrugere.

N/A

2. Brugervenlighed (alle krav i afsnit I1). Relevant for web-delen, men næppe for medarbejder-delen. Afhænger af hvem der skal levere web-delen.

En prototype af web-delen (gerne på papir) usability-testes med typiske brugere. Kan ske inden __ arbejdsdage.

N/A

3. Svartider med det planlagte antal brugere (alle krav i Error: Reference source not found).

Et testsystem sættes op med simulation af det forventede antal brugere. Svartiderne måles. Kan ske inden __ arbejdsdage.

N/A

B3. Minimumskrav(Ikke relevant)

B4. Tildelingskriterie(Ikke relevant)


3

C. Task systemet skal støtteSystemet skal støtte alle task i dette kapitel, herunder alle subtask og varianter, samt reducere problemerne. Kolonne 1 af tabellerne beskriver hvad bruger og system skal udføre tilsammen. Hvem der konkret gør hvad afhænger af den valgte løsning.

Når et task udføres sker det fra start til slut uden væsentlige afbrydelser. Om nødvendigt må sagen parkeres og genoptages senere.

Selvom subtask er nummereret, skal de ikke nødvendigvis udføres i den rækkefølge, og de skal heller ikke nødvendigvis udføres alle sammen hver gang. Brugeren bestemmer hvad der skal gøres og i hvilken rækkefølge. Et subtask kan også udføres flere gange inden for samme task.

Et subtask kan undertiden udføres på flere alternative måder. Det vises med a, b, osv. Fx vil henvendelse om en sag normalt starte med at finde sagen frem (subtask 2), men man kan i stedet oprette den med det samme (subtask 2a). Bogstaverne p, q, osv. angiver noget der i dag er problematisk med dette subtask.

Arbejdsområde 1: SagsbehandlingSagsbehandlingen er delt i uddelingsområder, fx miljøprojekter og forskningsprojekter. Inden for hvert område er der 2 til 3 sagsbehandlere.

Brugerprofil: Sagsbehandlere. Erfarne it- brugere med et godt kendskab til ansøgningsområdet.

C10. Modtag henvendelse om en sagDette task beskriver hvad en sagsbehandler kan gøre når han modtager en henvendelse. Nogle henvendelser vedrører ikke en eksisterende sag, andre vedrører en sag der endnu ikke er blevet til en ansøgning, og nogle vedrører en eksisterende ansøgning.

Start: E-mail om sagen, almindeligt brev, telefonisk, en automatisk påmindelse, en on-line ansøgning, eller at sagsbehandleren vil se hvilken sag der er vigtigst at arbejde med lige nu.

Slut: Når sagen er opdateret og data arkiveret.Hyppighed: Totalt: Ca. 40 henvendelser pr. dag. Pr. bruger: Ca. 5 pr. dag, heraf én ansøgning.Brugere: Sagsbehandlere.

Subtask og varianter: Eksempel på løsning: Kode:

1. Se evt. hvilke sager jeg har og deres status. Vælg en sag.

2. Find sagen frem, inkl. en evt. eksisterende ansøgning.

Søgning på sagsnr, dele af personnavn, dele af sagsnavn, mv.

2a. Der er ikke oprettet en sag. Vurder om der skal oprettes en og opret den i givet fald.

2b. Hvis henvendelsen er en ansøgning via brev eller mail: opret en ansøgning og tilknyt den til en evt. eksisterende sag.

2c. Hvis henvendelsen er en on-line ansøgning: tilknyt den til en evt. eksisterende sag.

Systemet opretter automatisk en on-line ansøgning inden sagsbehandleren får besked om det.

2p. Problem: Det er svært for andre end den primære sagsbehandler at få adgang til sagen og opdatere den, specielt e-mail arkivet.

3. Se sagens status og opdater den, fx registrer at der nu er kommet svar fra en sagkyndig, nye oplysninger fra ansøger, eller årsregnskab for projektet. (Se databeskrivelsen i afsnit D).

3p. Problem: Det er svært at få overblik over en sag.

Visuelt overblik fx med farvekoder eller en tidslinje.

4. Arkivér henvendelsen og alle ændrede data elektronisk.

4p. Problem: Det er besværligt at arkivere mail i sagsbehandlingssystemet (i dag Navision).


4


4q. Problem: I dag er det egentlige arkiv på papir. Det er besværligt at printe og arkivere. De elektroniske data er ikke samlet i et fælles sagssystem og data om den enkelte sag kan være flere steder. Nogle sagsbehandlere "arkiverer" alle mail i indbakken, ca. 12.000 e-mails i visse tilfælde.

5. Send kvittering.

Især i sagens tidlige stadier: Eksempel på løsning:

11. Skriv evt. notater på sagen, bl.a. en dæknote.

12. Opret virksomheder og organisationer med relation til sagen.

13. Opret ansøgere, sagkyndige, konsulenter og andre kontaktpersoner eller ret deres data (se afsnit D).

13p. Problem: I dag har hver sagsbehandler sine egne lister over kontaktpersoner.

14. Valider CPR og CVR hvor de optræder, bl.a. af hensyn til skatteindberetning. Validér også senere, fx for at se flytninger.

On-line tilgang til CPR og CVR

15. Tilknyt sagkyndige og konsulenter, kontakt dem og start tidsovervågning. Registrer data om dem (se D7).

Søgning på dele af navn eller e-mail-adresse eller de der har haft kontakt med en bestemt arbejdsgruppe.

16. Send evt. rykker til dem.

17. Opdater evt. bilagsmaterialet til næste arbejdsgruppemøde eller bestyrelsesmøde hvor sagen skal behandles.

18. Hvis ansøgningen klart ikke er støtteværdig: afvis den.

Især når ansøgningen er bevilget: Eksempel på løsning:

21. Kontroller kvartalsrapport, årsregnskab, mv. Sammenlign med bevilling. Godkend rapport.

22. Godkend udbetaling, anfør land og uddelingsområde, send anvisning til regnskabsafdelingen.

23. Ryk evt. for rapport eller regnskab.

24. Juster evt. udbetalingsplan.

25. Anvis betaling til konsulenter og sagkyndige.

26. Afslut evt. projektet og skriv slutevaluering.


5

C1. Forbered møde i arbejdsgruppe eller bestyrelseDette task beskriver hvad en sagsbehandler gør som forberedelse. Forberedelsen for arbejdsgrupper og bestyrelse er i princippet ens.

Start: Sagsbehandlerens eget initiativ baseret på kendte publicerings-deadlines.Slut: Når der ikke kan gøres mere lige nu eller materialet er sendt til arbejdsgruppe eller

bestyrelse.Hyppighed: Totalt: Ca. 12 bestyrelsesmøder og 36 arbejdsgruppemøder om året. Pr. arbejdsgruppe:

Ca. 6 møder om året.Brugere: Sagsbehandlere og bestyrelsessekretærer.

Suibtask og varianter: Eksempel på løsning: Kode:

1. Dan eller modificér dagsordenen for mødet. Tilføj punkter til eventuelt. Tilføj referat fra sidste møde, etc.

2. Dan oversigt over ansøgninger, deres status og evt. bemærkninger. Opdel typisk i ansøgninger til anden behandling, ansøgninger til første behandling og interessetilkendegivelser.

Dan oversigten ved at klikke på sager der skal med.

3. For hver ansøgning: Indsæt dæknote, anfør foreslåede sagkyndige, indsæt deres udtalelse, indsæt selve ansøgningen, evt. som et link.

4. Lås dokumentet så denne version ikke kan ændres.

5. Send dokumentet elektronisk til arbejdsgruppe eller bestyrelse.

6. Print evt. dokumentet og send det til arbejdsgruppe eller bestyrelse.

7. Parker arbejdet.

C2. Efterbehandling efter møde i arbejdsgruppe eller bestyrelseDette task beskriver hvad en sagsbehandler gør efter mødet. Nogle ansøgninger har været til 1. behandling, andre til 2. behandling. Fremover vil man gerne have mulighed for at medlemmerne efter mødet kan stemme om nogle af sagerne.

Start: Efter mødet.Slut: Når der ikke kan gøres mere lige nu eller alt er gjort.Hyppighed: Som C1.Brugere: Sagsbehandlere.


1. Opret nye sagkyndige og konsulenter.

2. Tilknyt sagkyndige og konsulenter, kontakt dem og start tidsovervågning.

3. Bed evt. ansøger om tilføjelser eller ændringer.

4. Meddel evt. afslag til ansøger. Skabelon

4a. Send bevillingsbrev med standardbetingelser, frister for (års)rapporter og manuelle tilføjelser.

Skabelon

5. Opdater sagernes status og arkivér alle ændringer.

6. Registrer udbetalingsplan. Sendes i dag til Regnskab.

Hvis data deles er der ingen grund til at advisere Regnskab.

7. For sager hvor bestyrelsen skal stemme: Start elektronisk afstemning med tidsovervågning.


6

D. Data systemet skal anvendeSystemet skal registrere de data der er beskrevet i dette kapitel. Data skal kunne oprettes, ses og ændres gennem de relevante task i kapitel C. Data skal i mange tilfælde kunne udveksles med eksterne systemer som beskrevet i kapitel F.

Figur D er en datamodel (et Entitets/Relations diagram, E/R) der giver en oversigt over data. Hver kasse er en dataklasse. Bag kassen er der en stabel "kartotekskort". Kassen selv symboliserer et af kortene. Fx indeholder D2 et kort for hver ansøgning. Ved siden af kassen er der en liste af de vigtigste felter som kortet indeholder.

Der er relationer mellem kasserne vist som "hønseben". Et hønseben viser at et kort har en relation til et eller flere kort i en anden kasse. Fx kan en ansøgning have flere udbetalinger, mens en udbetaling kun vedrører én ansøgning. Data skal ikke nødvendigvis struktureres på denne måde i systemet, men det skal håndteres på en eller anden måde.

De følgende sider giver en detaljeret beskrivelse af de enkelte kasser.


7

Figur D. Datamodel for SagssystemetKonti, depoter og web-elementer er ikke modelleret.

navn, kreditorkonto, x1, x2, x3,status (modtaget | til1beh | til2beh | bevilget |. . .)

D1. Sag D2. Ansøgning

D4. Gruppe D5. SagsRolle

D3. Udbetaling

D8. HonorarD7. Person_OrgD6.

GruppeRolle

rolleType (primærAnsøger | sekundærAnsøger | sagsbehandler| sagkyndig | kopiAfUdbet . . . ),

status (inviteret| accepteret| svaret)

navn

D9. UddelingsOmråde D10. Land

D12. Skabelon

beløb, dato, status (plan| faktisk| kvitteret)

D11. Dokument

navn,type (dæknote | ansøgning | budget |

rapport | udtalelse | . . . ), medie( pdf | mail | . . . )navn navn, forkortelse

navnadresseemailCPR,CVR, fødselsdag . . .fagområde?

beløb, dato,status (plan| faktisk)

navn, tekst

navn

D13. Rapportering

navn, dato, status (plan| faktisk| godkendt)

rolleType (medlem| sagkyndig)

D0. Fælles felterAlle dataklasser har historik, dvs. at enhver ændring giver en ny udgave af "kartotekskortet" og den gamle bevares. "Kartotekskortet" kan også have en relation til dokumenter der vedrører "kortet".

Felter og relationer: Eksempel på løsning: Code:

1. Tidspunkt hvor "kartotekskortet" blev oprettet eller ændret.

2. Kilde: Den person der oprettede eller ændrede kortet.

3. Dokumenter: Relation til nul eller flere dokumenter der hører til "kartotekskortet". En hvilken som helst dataklasse kan have tilknyttede dokumenter. For nogle dataklasser uddybes dette punkt nedenfor.

D1. SagEn sag kan i princippet handle om hvadsomhelst, men de vigtigste er de der giver en ansøgning. En sagsbehandler kan oprette en sag når som helst.

Eksempler: En interessetilkendegivelse, en forhandling med en leverandør, en ansøgning der modtages som brev. Mange sager resulterer i én, sjældnere flere, ansøgninger.

Datakilde: En sag kan oprettes af en sagsbehandler eller oprettes automatisk ved en on-line ansøgning. Sagens data kan ændres af en sagsbehandler.

Databrug: Sagerne bruges overalt i sagsbehandlingen.

Datavolumen: Eksempel på løsning: Code:

1. Der oprettes omkring 4000 sager om året.

Felter og relationer: Eksempel på løsning: Kode:

2. Sagsnummer. Tildeles automatisk af systemet.

3. Navn: Et navn sagsbehandleren tildeler. Kan ændres senere.

4. Uddelingsområde: Relation til et sjældnere flere uddelingsområder (Error: Reference source not found).

5. Land: Relation til Error: Reference source not found.

6. Gruppe: Relation til den arbejdsgruppe der behandler sagen, sjældnere flere grupper.

7. Ansøgning: Relation til en (sjældnere flere) ansøgninger der hører til sagen.

8. Rolle: Relation til personer eller organisationer der har en rolle i sagen.

9. Status: oprettet, opfølgning, afsluttet …


8

D2. Ansøgning

Eksempler: En ansøgning om støtte til grundforskning i fysik. En ansøgning om aktivering af ældre. Datakilde: En ansøgning kan oprettes af en sagsbehandler eller oprettes automatisk ved en on-line

ansøgning. Ansøgningens data kan ændres af en sagsbehandler.Databrug: Ansøgningen bruges i bevillingsprocessen.

Datavolumen: Eksempel på løsning: Code:

1. Der oprettes omkring 2000 ansøgninger om året.

Felter og relationer: Eksempel på løsning: Kode:

2. Ansøgningsnummer. Gerne en form for undernummer på sagens nummer så man lettere kan se sammenhængen.

Tildeles automatisk af systemet.

3. Navn: Et navn sagsbehandleren tildeler ud fra ansøgningens ordlyd. Kan ændres senere.

4. Kreditorkonto: Den konto hvor udgifter og betalinger til bevillingshaver bogføres.

Tildeles automatisk af systemet.

5. Status: Se kravnoten nedenfor.

6. Uddelingsområde: Relation til D9. Kan undertiden afvige fra sagens uddelingsområde.

7. Land: Relation til D10.

8. Gruppe: Relation til den arbejdsgruppe der behandler ansøgningen.

9. Sag: Relation til den sag der hører til ansøgningen.

10. Rolle: Relation til personer eller organisationer der har en rolle i ansøgningen.

11. Udbetaling: Relation til de planlagte eller afholdte udbetalinger der hører til ansøgningen.

12. Dokumenter: Relation til dokumenter der hører til ansøgningen, fx kort beskrivelse, fuld beskrivelse, budget, CV.

13. x1, x2, x3: Ekstra felter, fx til angivelse af projektets succes. Kunden kan selv navngive dem.

Kravnote, statusAnsøgningens status kan være en af følgende:1. Modtaget2. Afvist inden første behandling3. Skal til første behandling4. Skal til anden behandling5. Afventer møde6. Bevilget7. Afslået8. Trukket tilbage


9

E. Andre funktionelle krav

De fleste systemfunktioner er simple oprettelser, sletninger, editeringer og forespørgsler, som ikke er specificeret yderligere. Det fremgår implicit af task (kapitel C), systemintegrationer (kapitel F) og databeskrivelserne (kapitel D). Desuden skal systemet kunne udføre funktionerne i dette kapitel.

E1. System-genererede hændelser

Systemet skal håndtere disse hændelser: Eksempel på løsning: Code:

1. Når en ansøgning kommer via web-sitet: Opret en sag. Send meddelelse til sagsbehandler.

2. Når en mail ankommer: Send den til den relevante sagsbehandler.

Systemet finder sagen eller ansøgningen ud fra mailens subject og sagsbehandleren ud fra Sagsrollen (Error: Reference source not found).

2. Hvis en sagkyndig ikke svarer til tiden: Send påmindelse til sagsbehandler og/eller den sagkyndige.

3. Hvis en kvartals- eller årsrapport ikke kommer til tiden: Send påmindelse til sagsbehandler og/eller ansøger.

4. Hvis en meddelelse i en sag ikke er blevet behandlet inden for en rimelig tid: Send påmindelse til ledelse.

5. Hvis en kvittering ikke er modtaget inden en rimelig tid: Send påmindelse til Regnskab.

E2. Udskrifter og rapporterKravene er dækket af task C22 og C25.

E3. Forretningsregler og komplekse beregningerIngen.

E4. SystemadministrationSystemadministrationen omfatter følgende subtask

Subtask vedr. systemadministration: Eksempel på løsning: Kode:

1. Indstil standardlængden af tidsovervågninger, fx det antal dage der skal gå inden en manglende rapport giver en påmindelse.

2. Angiv hvilke dataændringer der skal stoppe hvilke tidsovervågninger.

3. Angiv hvilke handlinger der skal starte tidsovervågning.

4. Angiv hvilke sagsbehandlere der kan erstatte hvilke andre.

5. Angiv hvem der skal have mails der ikke automatisk fordeles.

6. Oprette, rette og fjerne uddelingsområder, grupper og grupperoller.

7. Definer nye felter for dataklasserne i kapitel D. Eksempel: data om en ansøgnings succes.

8. Modificer skærmbilleder så de også viser de nye felter og tillader indtastning til dem.


10

F. Systemets integration med eksterne systemerSystemet skal i større eller mindre grad integreres med de eksterne systemer der er vist i figur F (kontekst diagram). Integrationen består mest af dataoverførsler.

Integrationer der skal støttes: Eksempel på løsning: Code:

F1. Kundens mail-system. Alle mails der vedrører sager eller ansøgninger skal arkiveres af sagssystemet.

F2. Kundens web-site. Ansøgninger skal kunne modtages via kundens web-site og ansøgere skal kunne se hvor langt deres sag er kommet.

F3. CPR-registret. Sagssystemet skal validere CPR-numre, bl.a. af hensyn til skatteindberet-ning. Kan også hente postadressen.

F4. CVR-registret. Sagssystemet skal validere CVR-numre, bl.a. af hensyn til skatteindberet-ning. Kan også hente postadressen.

Integrationer der eventuelt skal støttes, men som kan gøres manuelt:

Eksempel på løsning: Code:

F5. Skat. Indberetning til Skat af de udbetalte midler.

F6. Multidata. Import af løndata til økonomisystemet.

F7. Banker. Eksport af betalingsordrer. Import af værdipapir-transaktioner og kurser.

F8. Excel. Eksport af data fra sagssystemet til viderebehandling i Excel. Se C25, ad-hoc rapport.

F9. Portmann. I dag eksporteres data fra Portmann til Excel, men muligheder for at overføre kurser til økonomi er velkomne.


11

Figur F: Integrationer

Dobbelte linier:Leverandøren integrerer

F6. Multidata

F8. Excel

F7. Banker

F1. Outlook

F9. PortmannF2. CMS

Økonomi

eDoc

Sagssystem

F5. Skat

Økonomi

Sagsbehandlere

Ansøgere

F3. CPR

F4. CVR

G. Teknisk it-arkitektur

G1. Leverandøren eller tredjepart har driftsansvar

Krav til platformen: Eksempel på løsning: Kode:

1. Leverandøren eller en tredjepart udpeget af leverandøren, driver systemet og bruger det nødvendige udstyr for at overholde kravene i L1, L2 og L3.

H. SikkerhedH1. Adgangsret for brugereLog-in, mv. er ikke selvstændige task for brugerne, men subtask der optræder i mange forskellige task. Systemet skal støtte følgende subtask i forbindelse med brugernes adgang til systemet.

Subtask vedr. brugeres adgang: Eksempel på løsning: Kode:

1. Identificér brugeren.(Se afsnit H5-3 om længden af password).

Brugeren identificerer sig selv med brugernavn og password.

2. Brugeren har været væk fra systemet i et stykke tid. Undgå at en anden bruger anvender systemet med den førstes rettigheder.

Systemet timer ud efter 10 min.

2p. Problem: Hvis systemet timer ud, er det besværligt at logge på igen.

Systemet kræver kun password.

2q. Problem: Hvis systemet timer ud, kan indtastet data gå tabt.

3. Kontrollér at kun autoriserede brugere har adgang til system og data. (Se kravnoten nedenfor).

3p. Undgå at brugerne har password for hvert system.

Hver bruger har kun ét brugernavn og ét password (single sign-on).

Kravnote: Mulige adgangsrettigheder1. Ret til at se alt sagsdata i kapitel D (D1, D2, D3, D5, D8 og D11 der vedrører en af disse).2. Ret til at ændre sagsdata i kapitel D.3. Ret til at se regnskabsdata.4. Ret til at ændre regnskabsdata.5. Ret til at konfigurere systemet, herunder ændre grupper, medlemmer, uddelingsområder og

skabeloner.

Den enkelte medarbejder kan have flere rettigheder. Fx kan en økonomimedarbejder have rettigheder 1, 3 og 4.

H2. SikkerhedsadministrationSikkerhedsadministratorens arbejde omfatter nedenstående subtask.

Subtask vedr. sikkerhedsadministration: Eksempel på løsning: Kode:

1. Tildel eller fjern rettigheder for en bruger.

1a. Opret brugeren først.

2. Få oversigt over hvem der har ret til hvad og om der fx er en rettighed som ingen har.


12

I. Brugervenlighed og designI1. Indlæring og effektivitet i daglig brugKunden vil allerede inden kontraktunderskrift sikre sig at sagssystemet har den fornødne brugervenlighed for medarbejderne. Der er derfor ikke brugervenlighedskrav her.

Web-delen er rettet mod offentligheden og her er brugervenlighed afgørende. Nedenstående krav er kun relevant for den part der leverer web-delen, fx hovedleverandøren, en web-leverandør eller kundens egen stab.

Krav: Eksempel på løsning:

1. Besøgende på web-delen skal kunne udføre alle task i område 5 uden kritiske usability-problemer (se kravnoten nedenfor).

Der udføres tænke-højt test med 5 tilfældigt valgte brugere fra målgruppen. Der må højst observeres __ kritiske usability-problemer.

2. Fejlmeddelelserne skal være forståelige og hjælpsomme.

Under tænke-højt testen vises et udvalg af fejlmeddelelser for brugeren, som skal forklare hvad meddelelsen betyder og hvad han skal gøre. __% af forklaringerne skal være acceptable.

Kravnote: Alvorlige og kritiske usability-problemerEt alvorligt problem er en situation hvor brugeren:a. ikke kan gennemføre opgaven på egen hånd,b. eller tror den er udført selvom den ikke er,c. eller klager over at det her er virkelig besværligt,d. eller forsøgslederen kan se at brugeren ikke anvender systemet effektivt.

Et kritisk usability-problem er et alvorligt usability-problem som er observeret for mere end én bruger.

Kravnote: TestopgaverEn god testopgave svarer til en opgave en rigtig bruger kunne udføre. Den skal præsenteres på sådan en måde at den ikke vejleder brugeren. Her er et eksempel på en god og en dårlig testopgave:

Testopgave 1 (god): Se hvad X-Fonden støtter: Du er interesseret i støtte til miljøprojekter. Støtter fonden det? Hvordan søger du? Hvordan vil ansøgningen blive behandlet.

Testopgave 2 (dårlig - vejleder brugeren): Søg støtte til miljø: Gå ind på X-Fonden.dk. Vælg Uddelingsområder …


13

J. Andre krav og leverancerJ1. Andre standarder der skal følges

Krav: Eksempler på løsning: Kode:

1. Systemet skal overholde god regnskabsskik. Leverandøren skal sørge for certificeringen.

2. Systemet skal overholde lovgivningen om behandling af personoplysninger.

J2. UddannelseKunden ønsker at varetage en stor del af uddannelsen selv. Det tænkes gjort ved først at uddanne superbrugere, der så kan uddanne andre.


1. Leverandøren skal uddanne 3 superbrugere, så de kan varetage uddannelsen af andre medarbejdere. Uddannelsen skal gøre superbrugerne i stand til at udføre alle task i kapitel C, inklusive alle varianter, inden for deres respektive arbejdsområder.

Uddannelsen af en superbruger kan ske på ___ dage. (Kunden forventer at 3 dage er nok).

2. Leverandøren skal uddanne 2 it-medarbejdere så de kan varetage kundens del af drift og support.

Uddannelsen af en it-medarbejder kan ske på ___ dage. (Kunden forventer at 10 dage er nok).

3. Uddannelserne skal gennemføres inden for den sidste måned før overtagelsen, således at medarbejderne straks kan bruge systemet og ikke allerede har glemt hvordan. Om nødvendigt må uddannelsen gentages og overtagelsen udskydes.

J3. DokumentationDet forventes at kun superbrugere vil læse dokumentationen. Der er derfor ikke behov for begynderdokumentation.


1. Der skal senest en måned efter overtagelsen være dokumentation til rådighed af alle systemets funktioner set fra et brugerperspektiv. Dokumentationen skal være anvendelig for superbrugerne.

2. Der skal senest ved overtagelsen være tilstrækkelig dokumentation til at kunden kan varetage sin del af drift og support.

3. Al dokumentation skal leveres på maskinlæsbar form, og kunden skal frit kunne modificere den og kopiere den til eget brug.


14

J4. Datakonvertering

Leverandøren skal overføre data fra de eksisterende systemer:

Eksempler på løsning: Kode:

1. Overfør regnskabsdata fra Navision med tilhørende dokumenter.

2. Valider data og tilfør manglende data manuelt. Leverandøren bedes beskrive hvordan.

3. Overfør e-mails fra Lotus Notes. Fordel mails ud i nye sagsmapper.

Mindre vigtigt

J5. InstallationInstallationen skal ske hos driftsoperatøren.


1. Leverandøren skal installere alt hvad leverancen omfatter.

2. Leverandøren skal ligeledes installere de konverterede data.

3. Leverandøren skal hjælpe kunden med idriftsættelsen.

J6. UdfasningI dette afsnit betyder "kunden" hans egen IT-stab eller tredjepart bemyndiget af ham.


1. Leverandøren skal på kundens anmodning udtrække alt data beskrevet i kapitel D, samt alt økonomidata, på en form der er egnet til import i andre systemer.

2. Kunden skal selv kunne udtrække alt data beskrevet i kapitel D, samt alt økonomidata, på en form der er egnet til import i andre systemer.

3. Leverandøren skal udføre arbejdet til en fair pris der dækker de brugte timer og materialer.

4. Leverandøren skal loyalt hjælpe med at udfase systemet.


15

K. Kundens leverancerNedenstående liste af kundens leverancer skal være udtømmende, og leverandøren kan ikke forvente yderligere leverancer. Leverandøren må derfor i sit tilbud tilføje til listen om nødvendigt.

Kunden leverer: Eksempler på løsning: Kode:

1. Kontor med en it-arbejdsplads fra en måned før planlagt installationsprøve til en måned efter overtagelsen.

N/A

2. Uddrag af produktionsdata til testformål og det fulde produktionsdata til konvertering.

N/A

3. Ekspertise på anvendelsesområdet, svarende til en halv medarbejder over hele projektets løbetid.

N/A

4. Testpersoner til usability-tests. N/A

5. En halvtids projektleder. N/A

6. Superbrugere der selv lærer systemet så de kan uddanne andre brugere.

N/A

7. Ekspertise til validering af konverteret data. N/A

8. Frikøbte rettigheder til at integrere med de systemer der er nævnt i kapitel F.

N/A

L. Drift, support og vedligeholdDette kapitel beskriver leverandørens ansvar efter at selve produktet er leveret. Kravene kan kun delvis verificeres (testes) ved overtagelsen. Den egentlige verifikation sker senere, ved driftsprøven. Nogle af kravene er kun relevante hvis leverandøren har driftsansvar, andre kun hvis han har support-ansvar, etc.


16

Documents

Kravspecifikation til Sagsbehandling, økonomisystem og CMS af Søren Lauesen, ITU