Kravspecifikation    Home      English 

Y-Fonden    CMS krav    Use cases versus task    Bog: Software Requirements    Publikationer om krav

Problem-orienterede krav - SL-07

Systemudviklere og it-konsulenter spørger ofte efter en eksemplarisk kravspecifikation de kan tage udgangspunkt i til deres konkrete projekt. SL-07 er sådan en kravspecifikation. Det er en skabelon udfyldt med et komplekst eksempel: Kravene til et elektronisk patientjournal system (EPJ). Der er en kontrakt der passer til. Tradionelle krav beskriver hvad systemet skal gøre. Problemorienterede krav (SL-07 krav) beskriver hvad systemet skal bruges til, og de problemer det skal løse. Vi lader leverandøren vise hvordan hans løsning støtter os og håndterer problemerne.

Kunden kan vurdere hvor godt løsningen støtter brugerne, etc. og bruge det i leverandørvalget. SL-07 krav har mange andre fordele: Fem gange kortere, fem gange hurtigere at skrive, fem gange hurtigere at besvare, og forretningsmæssige mål der nås. Ulempe: Det tager fem dage at lære metoden.

Metoden er til rådighed som en vejledning i at skrive SL-07 krav, illustreret med den elektroniske patientjournal. Der er også selve krav-dokumentet til kopiering, inklusiv figurerne. Og en kontrakt der passer til kravene. Forside af Vejledning til kravskabelon

Dansk version 7: On-line vejledning (pdf),   EPJ-krav (docx),   Figurer (pptx),   Kontrakt til kravene (docx)

Engelsk version 7: On-line Guide booklet (pdf),   EHR Requirements (docx),   Figures (pptx),   Contract for the requirements (docx)

Vejledningerne kan også købes på Amazon som hæfter på ca. 127 sider. Pris ca. 300 DKK.

Kravene dækker funktionelle krav, sikkerhed, brugervenlighed, integration, støtte af anskaffelsesprocessen, udfasning af systemet, osv. Alle krav er verificerbare. Ca 30% af kravene svarer til det der traditionelt er use cases eller user stories. Typisk kan 50% af kravene kopieres til andre anvendelsesområder.

Sørg for at læse on-line vejledningen som to sider overfor hinanden. Evt. kan du downloade den først. Vejledningen viser EPJ-kravene afsnit for afsnit på højre side, og forklarer på venstre side hvorfor de er skrevet sådan, og hvad man ikke skal skrive. Der er også afsnit om at finde kravene, vælge leverandør, teste systemet, og styre hele processen.

Alle krav står i tabeller. Kolonne 1 er kundens behov - hvad han skal bruge systemet til, eller det problem der skal fjernes. Kolonne 2 kan være en løsning kunden forestiller sig (med sort), og senere leverandørens tilbudte løsning (med rødt). Nogle beskrivelser er så lange at de ikke passer ind i tabellerne. Så kan man bare skrive dem udenfor. Kig på Y-Fondens krav og løsninger nedenfor, for at se hvordan det tager sig ud i praksis.

Vil du have hjælp til at skrive problem-orienterede krav? Så send en mail til: slauesen@itu.dk

SL-07 kontrakten er ligesom kravene blevet problem-orienteret. Resultatet er en kontrakt på 8 sider med 4 bilag (et af dem er kravspecifikationen). Traditionelle kontrakter som K02, er over 50 sider med 16 bilag. Se IT-kontrakter (dansk)

EPJ-kravene er blevet genbrugt med succes i over 150 projekter af meget forskellig art, offentlige udbud såvel som in-house projekter, agile så vel som vandfald. Eksempler: Styring af hjemmehjælp i en kommune, inkl. ruteoptimering; en medicinalvirksomheds innovative dokumentstyringssystem; administration af støtte til udsatte voksne; elektronisk dyrlægejournal; lagerstyring for udstyr til filmproduktion; skadeanmeldelser med brug af GIS til at dokumentere situationen.

Historien bag SL-07: Jeg skrev den eksemplariske EPJ-kravspecifikation i 2007 på bestilling af VTU (Ministeriet for Videnskab, Teknologi og Udvikling) som led i arbejdet med Statens K02 kontrakt. Mine studerende gav kravspecifikationen navnet SL-07. EPJ-eksemplet stammer fra disse år. Jeg har opdateret SL-07 flere gange siden.


Y-Fonden: Problemorienterede krav i praksis

To gange om året modtager og vurderer Y-Fonden ca. 300 ansøgninger, og giver bevilling til nogle af dem. Processen er indviklet og omfatter ansøgere, sekretariat, bedømmelsesudvalg, revisor, web-redaktør, udbetalinger, indberetning til Skat, og et nyt web-site. Fonden havde brug for et IT-systen til at støtte procssen. Fra januar 2013 til marts 2013 undersøgte jeg behovene og skrev en SL-07 kravspecifikation. Derefter var jeg projektleder for anskaffelsesprocessen indtil den var afsluttet i september 2014 - 9 måneder forsinket. Kravspecifikation, den vindende leverandørs tilbud, og andre projektdokumenter er til rådighed på anonymiseret form. Se nedenfor.

Erfaringerne blev publiceret ved REFSQ 2018 konferencen: Lauesen, Soren: Problem-Oriented Requirements in Practice - a Case Study. In: E. Kamsties et al. (Eds.): REFSQ 2018, LNCS 10753, pp. 3–19, 2018, Springer, https://doi.org/10.1007/978-3-319-77243-1_1.

Ved REFSQ konferencen blev det anerkendt at dette var den første og eneste publikation af en virkelig IT-kravspecifikation. Den viste endda også det vindende tilbud, diskussion af tvister, vurdering af resultatet, mv.

Der var 34 siders kravspecifikation, skrevet som problem-orienterede krav. Leverandørerne beskrev deres løsning i kolonne 2, undertiden suppleret med en løsningsnote. Fx brugte den vindende leverandør en løsningsnote til at vise et detaljeret skærmbillede med et meget nyttigt overblik over ansøgningerne. Hans svar bestod af kravspecifikationen udbygget med løsningsdelene, i alt 44 sider. Svaret blev til et bilag til kontrakten: Krav og løsning til sagsbehandling og CMS (pdf, 44 pages)

Vi valgte leverandør ud fra den økonomiske gevinst, risikoen og den samlede omkostning: Indstilling til bestyrelsen: Valg af IT-system til Y-Fonden (docx). Dokumentet indeholder også en efter-vurdering af projektet: Blev målene nået? Og hvorfor blev vi forsinket?

Projektet blev 9 måneder forsinket. Hvad skete der undervejs? The Y-foundation project by month (docx)

Under afprøvningen opdagede vi mange fejl og ændringsønsker (issues). Vi registrerede dem vi ikke kunne håndtere med det samme. Ved de første test registrerede vi 23, senere 107. Her er en liste af alle 130: List of all issues/errors during the project (docx), List of all issues/errors during the project (xlsx)

Den måde kravene var skrevet på, gjorde det relativt let at skrive et test script for accepttesten (dvs. kundens test af systemet): Testplan (doc)


CMS requirements - template with examples

(Miriam Tang and Jan Keller Pedersen, 2007, 80 pages): Download (pdf)

Miriam og Jan har stor erfaring med Contents Management Systemer (CMS), dvs. værktøjer man bruger til at lave hjemmesider (Web-sites). De kender alle de problemer web-redaktører løber ind i. De ville skrive en kandidatafhandling om at vælge det rigtige CMS. Det viste sig at være svært fordi redaktørerne havde meget forskellige behov, som ikke kunne kvantificeres.

I 2007 var SL-07 skabelonen ved at være færdig, og de brugte den til at beskrive CMS-kravene. Organisationer der vil købe et CMS, kan bruge disse krav og ændre dem efter eget behov. For mig som vejleder, var det fascinerende at se hvordan redaktørernes problemer blev udtrykt i SL-07. Det tillod en fair sammenligning af CMS-systemerne ud fra den enkelte redaktørs krav.

Miriam og Jan modificerede resultatet en smule til brug for en konkret CMS-anskafffelse og sendte kravene til flere CMS-leverandører og potentielle kunder for at få kommentarer. Kommentarerne var meget positive: kravene afspejlede de virkelige behov og problemer på en konstruktiv måde.


Use-cases kontra task beskrivelser - et eksperiment

Use-cases er vidt udbredt som en væsentlig del af kravene, også når man ikke forventer at der skal programmeres noget (fx ved køb af standardsystemer). Er use-cases effektive som krav? For at besvare det spørgsmål, lavede vi et eksperiment i 2009. Vi inviterede professionelle og forskere til at besvare den samme opgave: Specificer krav for anskaffelse af et nyt system til at støtte en hotline. Vi fik 15 svar. 8 brugte traditionelle use-cases, som specificerer en dialog mellem bruger og system. 7 brugte task metoden fra SL-07. Et task specificerer kundens behov uden at specificere en dialog. Kunden kan også specificere at noget er et problem uden at vide om dette problem har en løsning.

Det viste sig at traditionelle use-cases ikke dækkede kundens behov på områder der var vigtige, men svære at støtte. Use-cases begrænsede også løsningsmulighederne alvorligt, fordi en use-case allerede er en slags løsning. Task havde ikke disse problemer og gav god mulighed for at sammenligne tilbudte løsninger. Resultaterne blev publiceret ved REFSQ 11 konferencen og fik prisen som Best Paper. SL-07 metoden bruger task i stedet for use-cases.

Publikation: Soren Lauesen & Mohammad Kuhail: Task descriptions versus use cases. In: Requirements Engineering (a Springer Journal): ISSN 0947-3602 Requirements Eng (2012) 17:3-18, DOI 10.1007/s00766-011-0140-1, November 2011. Hent artiklen (pdf, engelsk)

Eksperimentet: Hent den engelske opgavetekst (pdf), Hent den danske opgavetekst (pdf), Hent alle 15 besvarelser (zip)

Udvikling ud fra kravene: Opgaven startede som en 4-timers skriftlig eksamensopgave, hvor de studerende skulle lave datamodel, beskrive task, designe en grafisk brugergrænseflade, mv. Task-beskrivelser og datamodel havde tidligere vist sig nyttige til at designe og udvikle gode brugergrænseflader. For at tjekke det nok engang, udviklede og dokumenterede jeg et hotline-system i MS-Access, baseret på min egen besvarelse af opgaven. Du kan hente design-dokumenterne, database med VBA-programmet, test-dokumentationen, og lessons learned. Hent udviklingsdokumenterne (zip, engelsk)


Bog: Software requirements - styles and techniques

(Soren Lauesen, Pearson/Addison-Wesley, 2002, 600 sider) Hent  et uddrag (pdf)
Jeg skrev denne bog førend jeg rigtig forstod problem-orienterede krav: Behov til venstre og løsninger til højre. På det tidspunkt brugte jeg kun princippet i "task". Bogen forklarer og diskuterer også mange andre måder at formulere krav, en masse metoder til at afdække kravene, mange slags diagrammer, hvad der sker med kravene under udviklingen, osv.

Cover of Software RequirementsBogen blev annonceret sådan i 2002: De fleste IT systemer lever ikke op til forventningerne. Man når ikke sine forretningsmæssige mål og støtter ikke brugerne effektivt. Hvorfor? Fordi kravene ikke dækker det væsentlige. Underligt nok er det hurtigere at skrive en god kravspecikation, men man skal vide hvordan. Denne bog indeholder:

PowerPoint slides Hent dem (zip+ppt)
Indeholder alle figurerne fra bogen plus nogle ekstra. Der er en fil for hvert kapitel.

Pearson Education har copyright til materialet, men tillader kopiering til brug i undervisning. Det er en betingelse at kilden og copyright-betingelserne bevares på materialet. Det betyder at du kan vise slides - selvfølgelig - men også ændre dem og udlevere kopier, når blot kilden og copyrighten står der.

Lærermateriale Download (pdf), Download (doc)
Forslag til et 12-ugers kravkursus. Lærere kan få diverse opgaver - og løsninger til nogle af opgaverne. Da opgaverne bruges rundt om i verden, vil vi sikre os at løsningerne ikke er til rådighed på internettet. Kontakt mig hvis du er lærer på slauesen@itu.dk.


Sørens andre publikationer om krav (de fleste er på engelsk)

2018: Soren Lauesen: Problem-Oriented Requirements in Practice - a Case Study. In: E. Kamsties et al. (Eds.): REFSQ 2018, LNCS 10753, pp. 3–19, 2018, Springer, https://doi.org/10.1007/978-3-319-77243-1_1. Se mere her: Y-Fonden.

2011a: Soren Lauesen & Mohammad Kuhail: Task descriptions versus use cases. En udvidet version af publikationen herunder (use cases versus task descriptions). Indeholder også diskussioner fra konferencen, historien bag task-metoden, etc. Den endelige version er publiceret i Requirements Engineering (a Springer Journal): ISSN 0947-3602 Requirements Eng (2012) 17:3-18, DOI 10.1007/s00766-011-0140-1, November 2011. Se mere om use case eksperimentet.

2011b: Soren Lauesen & Mohammad Kuhail: Use cases versus task descriptions. In: D. Berry and X. Franch (Eds.): REFSQ 2011, LNCS 6606, pp. 106–120, 2011. Springer-Verlag Berlin Heidelberg 2011. Fik Best Paper Award på konferencen. Se mere om use case eksperimentet.

2005a: Soren Lauesen: COTS Tenders and Integration Requirements. Invited paper for Requirements Engineering Journal (REJ). En udvidet version af artiklen fra 2004. Indeholder alle de nødvendige integrationskrav. Har mindre om forskningsmetoden.

2005b: Soren Lauesen & Jens-Peder Vium: Communication Gaps in a Tender Process. Invited paper for Requirements Engineering Journal (REJ). En engelsk version af artiklen fra 2003. Den beskriver hele kravspecifikationen med uddrag af de mere interessante dele.

2004a: Soren Lauesen: COTS Tenders and Integration Requirements. Proceedings of the 12th International Requirements Engineering Conference, Kyoto, RE 2004, pp. 166-175. Viser hvordan man kan håndtere nogle af integrationskravene på sådan en måde at leverandøren får tilstrækkelig frihed, uden at få monopol på fremtidige udvidelser. Fik Best Paper Award på konferencen.

2004b: Soren Lauesen: Experiences from a tender process. In: Regnell et al. (eds.): Proceedings of REFSQ'04, Riga, Essener Informatik Beitrage, ISBN 3-922602-91-6, pp. 29-46. Et case studie af en stor anskaffelsesproces. Giver kundens syn på processen og de 5 leverandørers. Kunden brugte på egen hånd task-beskrivelser, men havde ingen erfaringer med det. Det gav mange problemer. Det nye system skulle integrere med ca. 20 andre systemer, men ingen vidste hvordan man skulle håndtere krav for det. Det fik mig (Lauesen) til at udvikle teknikker til integrationskrav.

2003a: Soren Lauesen & Jens-Peder Vium: Erfaringer fra en EU udbudsforretning - hvad gik godt og hvor var problemerne? En tidlig dansk udgave af den engelske artikel ovenfor. I modsætning til den engelske version, har den danske referater af interviews med leverandørerne.

2003b: Soren Lauesen: Task Descriptions as Functional Requirements. IEEE Software 2003, March/April, pp. 58-65. Denne artikel er den første videnskabelige publikation af task-begrebet, som jeg opfandt sammen med Marianne Mathiassen omkring 1997.

2002a: Soren Lauesen: Software requirements - styles and techniques (44 siders uddrag). Addison-Wesley/Pearson, 608 sider, ISBN 0 201 74570 4. Min lærebog om kravspecifikation: Mer om bogen

2002b: Soren Lauesen: Software requirements - styles and techniques. Publishing House of Electronics Industry, Beijing, 348 pages. (Skrevet på Simplified Chinese). Indeholder alt fra Addison-Wesley udgaven ovenfor, undtagen stikordsregistret.

2001: Soren Lauesen & Otto Vinter: Preventing Requirement Defects: An Experiment in Process Improvement. Requirements Engineering Journal (2001) 6, pp. 37-50. Springer Verlag, 2001. En undersøgelse af rapporterede fejl i Brüel & Kjærs produkter og hvordan man kan forebygge dem.

2000: Dansk Dataforening & Søren Lauesen: IT-anskaffelse, Kravspecifikationen. Dansk Dataforening, 75 sider. Nogle af de centrale dele af det der blev til Addison-Wesley lærebogen (2002a). Desværre brugte jeg den gang betegnelsen Use Case med løsninger i stedet for task beskrivelse. Jeg opfattede task som et specialtilfælde af use-cases, og havde endnu ikke forstået den fundamentale forskel. Det har givet meget forvirring i det danske IT-miljø.

1999: Søren Lauesen (1999): Software Requirements, Styles and Techniques. Samfundslitteratur, København, 190 sider (engelsk). En tidlig version af Addison-Wesley udgaven (2002): Software requirements - styles and techniques.

1998: Soren Lauesen & Houman Younessi: Six styles for usability requirements. In: Eric Dubois, Andreas L. Opdahl, Klaus Pohl (eds.): Proceedings of the Fourth International Workshop on Requirements Engineering: Foundations of Software Quality REFSQ’98, Presses Universitaires de Namur, pp. 155-166. Viser 6 forskellige måder at formulere krav til brugervenlighed.

1996: Soren Lauesen & Jens-Peder Vium: Lessons learned from assessing a success. In: Proceedings of Fifth European Conference on Software Quality, Irish Quality Association, Dublin, pp. 335-344. Et case-studie af anskaffelse af et ERP-system til et skibsværft. Skibsværftet ønskede et ERP system for at nå adskillige forretningsmæssige mål. Det vigtigste var at forbedre præcisionen af omkostningsberegningen på en ordre (pre-kalkulation) ved at bruge erfaringsdata. De troede systemet var en succes, men vores undersøgelse viste at det ikke var blevet bedre. De kritiske dele af systemet blev ikke brugt, fordi det var for besværligt. Årsagen var at man havde brugt traditionelle krav, hvor man ikke kan se arbejdskonteksten.