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

Version 1.4 03-02-2013, 13:57
Sidst rettet af: Soren Lauesen

Kravspecifikation til
Sagsbehandling, økonomisystem og CMS
(i det følgende kaldet Sagssystemet)

Kunde
X-Fonden
Leverandør
…
Leverancen omfatter
Levering, drift og vedligehold af Sagssystemet

Indhold
A. Baggrund og vejledning til leverandøren...............3 D6. Grupperolle........................................................22
A1. Baggrund og vision..............................................3 D7. Person_Org.......................................................23
A2. Vejledning til leverandøren..................................5 D8. Honorar..............................................................23
B. Overordnede behov..................................................6 D9. Uddelingsområde...............................................24
B1. Forretningsmæssige mål.....................................6 D10. Land.................................................................24
B2. Tidligt bevis for gennemførlighed (proof of D11. Dokument........................................................25
concept)...............................................................7 D12. Skabelon..........................................................25
B3. Minimumskrav......................................................7 D13. Rapportering....................................................26
B4. Tildelingskriterie...................................................7 E. Andre funktionelle krav..........................................27
C. Task systemet skal støtte........................................8 E1. System-genererede hændelser.........................27
Arbejdsområde 1: Sagsbehandling.............................8 E2. Udskrifter og rapporter.......................................27
C10. Modtag henvendelse om en sag........................8 E3. Forretningsregler og komplekse beregninger....27
C11. Forbered møde i arbejdsgruppe eller bestyrelse E4. Systemadministration.........................................28
...........................................................................10 F. Systemets integration med eksterne systemer. . .29
C12. Efterbehandling efter møde i arbejdsgruppe eller G. Teknisk it-arkitektur...............................................30
bestyrelse..........................................................10 G1. Leverandøren eller tredjepart har driftsansvar. .30
C13. Overvåg afstemning.........................................11 H. Sikkerhed................................................................31
C14. Tildel ny sagsbehandler...................................11 H1. Adgangsret for brugere......................................31
Arbejdsområde 2: Økonomi.......................................12 H2. Sikkerhedsadministration...................................31
C20. Modtag anvisning eller faktura.........................12 H3. Sikring mod tab af data......................................31
C21. Modtag kvittering for betaling...........................12 H4. Sikring mod utilsigtet brugeradfærd...................32
C22. Rapportér til bestyrelse....................................13 H5. Sikring mod trusler.............................................32
C23. Bogfør værdipapir-transaktioner......................13 I. Brugervenlighed og design.....................................33
C24. Registrér andre oplysninger.............................14 I1. Indlæring og effektivitet i daglig brug...................33
C25. Ad-hoc rapport.................................................14 I2. Tilgængelighed og Look-and-Feel.......................33
Arbejdsområde 3: Arbejdsgrupper og bestyrelse. . .14 J. Andre krav og leverancer.......................................34
Arbejdsområde 4: Web-redaktion..............................15 J1. Andre standarder der skal følges.......................34
C40. Rediger fondens web-site................................15 J2. Uddannelse........................................................34
Arbejdsområde 5: Ansøgere og offentligheden.......17 J3. Dokumentation...................................................34
C50. Besøg fondens web-site..................................17 J4. Datakonvertering................................................35
C51. Ansøg om støtte..............................................17 J5. Installation..........................................................35
Arbejdsområde 6: Sagkyndige..................................17 J6. Udfasning...........................................................35
D. Data systemet skal anvende..................................18 K. Kundens leverancer...............................................36
D0. Fælles felter.......................................................19 L. Drift, support og vedligehold.................................37
D1. Sag....................................................................19 L1. Svartider.............................................................37
D2. Ansøgning..........................................................20 L2. Tilgængelighed (driftseffektivitet).......................38
D3. Udbetaling..........................................................21 L3. Datalagring.........................................................38
D4. Gruppe...............................................................21 L4. Support...............................................................39
D5. Sagsrolle............................................................22 L5. 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.

2

A. Baggrund og vejledning til leverandøren
A.1. Baggrund og vision
X-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.

Figur A1: Eksisterende system
Ansøgere

Domino
LotusNotes
web-server
Sagsbehandlere

Portmann
Sagsbehandlere
Windows
files
Excel
Økonomi
Formue- Skat
NAV
forvaltning

Banker
Multidata
Økonomi

Figur A2: Vision om nyt system
Ansøgere

Outlook

Sagsbehandlere Sagssystem
Sagsbehandlere
CMS Dobbelte linier:
Portmann Leverandøren integrerer

eDoc CPR
Excel
Økonomi CVR
Formue
Økonomi
Banker Skat

Multidata
Økonomi

Sagssystem til X-Fonden

3

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

B.1. Forretningsmæssige mål
Kundens 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 Løsningsvision Relaterede krav Evt. tidsfrist
system
1. Bedre støtte til a. Arkivér alt data om en sag C10 til C13, C20,
sagsbehandlingen og elektronisk i én "mappe". C21, F1-F7.
det tilhørende b. Etabler en fælles liste af
regnskab. kontaktpersoner.
c. Simplificér bogføring og udbetaling.
2. Bedre Et nyt web-system (CMS - Contents C40, C50, C51, F2,
kommunikation med Management System) Kap I.
målgrupperne via web-
sitet.

3. Bedre styring af Opdeling i flere forvaltninger. Sikring af C23, C24, F7, F9.
værdipapirerne. historik for transaktioner.

B.2. 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 N/A
kundens ekspertbrugere.
2. Brugervenlighed (alle krav i afsnit En prototype af web-delen (gerne på papir) N/A
I.1). Relevant for web-delen, men usability-testes med typiske brugere.
næppe for medarbejder-delen. Kan ske inden __ arbejdsdage.
Afhænger af hvem der skal levere
web-delen.
3. Svartider med det planlagte antal Et testsystem sættes op med simulation af det N/A
brugere (alle krav i Error: Reference forventede antal brugere. Svartiderne måles.
source not found). Kan ske inden __ arbejdsdage.

B.3. Minimumskrav
(Ikke relevant)


4

B.4. Tildelingskriterie
(Ikke relevant)


5

C. Task systemet skal støtte
Systemet 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: Sagsbehandling
Sagsbehandlingen 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.

C.10. Modtag henvendelse om en sag
Dette 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 Søgning på sagsnr, dele af
ansøgning. 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: Systemet opretter automatisk en on-
tilknyt den til en evt. eksisterende sag. 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 Visuelt overblik fx med farvekoder
sag. 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).


6

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 On-line tilgang til CPR og CVR
hensyn til skatteindberetning. Validér også
senere, fx for at se flytninger.
15. Tilknyt sagkyndige og konsulenter, kontakt dem Søgning på dele af navn eller e-mail-
og start tidsovervågning. Registrer data om dem adresse eller de der har haft kontakt
(se D7). 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.


7

C.1. Forbered møde i arbejdsgruppe eller bestyrelse
Dette 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.


8

Suibtask og varianter: Eksempel på løsning: Kode:
2. Dan oversigt over ansøgninger, deres status og Dan oversigten ved at klikke på sager
evt. bemærkninger. Opdel typisk i ansøgninger der skal med.
til anden behandling, ansøgninger til første
behandling og interessetilkendegivelser.
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.

C.2. Efterbehandling efter møde i arbejdsgruppe eller bestyrelse
Dette 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 C.1.
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, Skabelon
frister for (års)rapporter og manuelle tilføjelser.
5. Opdater sagernes status og arkivér alle
ændringer.
6. Registrer udbetalingsplan. Sendes i dag til Hvis data deles er der ingen grund til
Regnskab. at advisere Regnskab.
7. For sager hvor bestyrelsen skal stemme: Start
elektronisk afstemning med tidsovervågning.


9

D. Data systemet skal anvende
Systemet 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.

Figur D. Datamodel for Sagssystemet
Konti, depoter og web-elementer er ikke modelleret.
navn,
type (dæknote | ansøgning | budget |
rapport | udtalelse | . . . ),
navn navn, forkortelse medie( pdf | mail | . . . )

D9. UddelingsOmråde D10. Land D11. Dokument

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

D1. Sag D2. Ansøgning D3. Udbetaling

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

D13. Rapportering
navn, dato,
status (plan| faktisk| godkendt)
navn
rolleType (primærAnsøger | sekundærAnsøger |
D4. Gruppe D5. sagsbehandler| sagkyndig | kopiAfUdbet . . . ),
SagsRolle status (inviteret| accepteret| svaret)

D8. Honorar
D6. D7. Person_Org
GruppeRolle beløb, dato,
navn status (plan| faktisk)
adresse
rolleType email
(medlem| sagkyndig) CPR,CVR, fødselsdag . . .
D12. Skabelon
fagområde?
navn, tekst


10

D.0. Fælles felter
Alle 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.

D.1. Sag
En 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 …


11

D.2. 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 Tildeles automatisk af systemet.
undernummer på sagens nummer så man
lettere kan se sammenhængen.
3. Navn: Et navn sagsbehandleren tildeler ud fra
ansøgningens ordlyd. Kan ændres senere.
4. Kreditorkonto: Den konto hvor udgifter og Tildeles automatisk af systemet.
betalinger til bevillingshaver bogføres.
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, status
Ansøgningens status kan være en af følgende:
1. Modtaget
2. Afvist inden første behandling
3. Skal til første behandling
4. Skal til anden behandling
5. Afventer møde
6. Bevilget
7. Afslået
8. Trukket tilbage


12

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.

E.1. 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 Systemet finder sagen eller
relevante sagsbehandler. 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.

E.2. Udskrifter og rapporter
Kravene er dækket af task C22 og C25.

E.3. Forretningsregler og komplekse beregninger
Ingen.

E.4. Systemadministration
Systemadministrationen 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.


13

F. Systemets integration med eksterne systemer
Systemet 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.

Figur F: Integrationer
Ansøgere

F1. Outlook
Sagssystem
Sagsbehandlere
F2. CMS Dobbelte linier:
F9. Portmann Leverandøren integrerer

eDoc F3. CPR
F8. Excel
F4. CVR

Økonomi
F7. Banker F5. Skat

F6. Multidata
Økonomi

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 Eksempel på løsning: Code:
gøres manuelt:
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.


14

G. Teknisk it-arkitektur
G.1. 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. Sikkerhed
H.1. Adgangsret for brugere
Log-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. Brugeren identificerer sig selv med
(Se afsnit H5-3 om længden af password). brugernavn og password.
2. Brugeren har været væk fra systemet i et stykke Systemet timer ud efter 10 min.
tid. Undgå at en anden bruger anvender
systemet med den førstes rettigheder.
2p. Problem: Hvis systemet timer ud, er det Systemet kræver kun password.
besværligt at logge på igen.
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 Hver bruger har kun ét brugernavn og
system. ét password (single sign-on).

Kravnote: Mulige adgangsrettigheder
1. 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.

H.2. Sikkerhedsadministration
Sikkerhedsadministratorens 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.


15

I. Brugervenlighed og design
I.1. Indlæring og effektivitet i daglig brug
Kunden 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 Der udføres tænke-højt test med 5
alle task i område 5 uden kritiske usability- tilfældigt valgte brugere fra
problemer (se kravnoten nedenfor). målgruppen. Der må højst observeres
__ kritiske usability-problemer.
2. Fejlmeddelelserne skal være forståelige og Under tænke-højt testen vises et
hjælpsomme. 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-problemer
Et 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: Testopgaver
En 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 …


16

J. Andre krav og leverancer
J.1. 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.

J.2. Uddannelse
Kunden ø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å Uddannelsen af en superbruger kan
de kan varetage uddannelsen af andre ske på ___ dage. (Kunden forventer
medarbejdere. Uddannelsen skal gøre at 3 dage er nok).
superbrugerne i stand til at udføre alle task i
kapitel C, inklusive alle varianter, inden for
deres respektive arbejdsområder.
2. Leverandøren skal uddanne 2 it-medarbejdere Uddannelsen af en it-medarbejder
så de kan varetage kundens del af drift og kan ske på ___ dage. (Kunden
support. 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.

J.3. Dokumentation
Det 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.


17

J.4. Datakonvertering
Leverandøren skal overføre data fra de eksisterende Eksempler på løsning: Kode:
systemer:
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 Mindre vigtigt
i nye sagsmapper.

J.5. Installation
Installationen 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.

J.6. Udfasning
I 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.


18

K. Kundens leverancer
Nedenstå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 N/A
planlagt installationsprøve til en måned efter
overtagelsen.
2. Uddrag af produktionsdata til testformål og det N/A
fulde produktionsdata til konvertering.
3. Ekspertise på anvendelsesområdet, svarende til N/A
en halv medarbejder over hele projektets
løbetid.
4. Testpersoner til usability-tests. N/A
5. En halvtids projektleder. N/A
6. Superbrugere der selv lærer systemet så de kan N/A
uddanne andre brugere.
7. Ekspertise til validering af konverteret data. N/A
8. Frikøbte rettigheder til at integrere med de N/A
systemer der er nævnt i kapitel F.

L. Drift, support og vedligehold
Dette 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.


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

Recommended

Recommended

More Related Content

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

Similar to Kravspecifikation til Sagsbehandling, økonomisystem og CMS af Søren Lauesen, ITU (16)

More from InfinIT - Innovationsnetværket for it

More from InfinIT - Innovationsnetværket for it (20)

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