Se også: Y-Fonden CMS krav Use cases versus task Bog: Software Requirements Publikationer om krav
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 en elektronisk patientjournal. Der er også selve krav-dokumentet til kopiering, inklusiv figurerne. Og en kontrakt der passer til kravene.
Dansk version 9: On-line vejledning (pdf), EPJ-krav (docx), EPJ-figurer (pptx), Kontrakt til kravene (docx)
Engelsk version 9: On-line Guide booklet (pdf), EHR Requirements (docx), EHR figures (pptx), Contract for the requirements (docx)
Vejledningerne kan også købes på Amazon som hæfter på ca. 127 sider. Pris ca. 110 DKK. DK: 9798426357747. UK: 9798425802224.
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@os.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.
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 (docx)
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.
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)
Bogen 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+pptx)
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 (docx) 2022c: Mohammad Amin Kuhail and Soren Lauesen (2022): User Story Quality in Practice: A Case Study (pdf). 21 pages. A more readable version than the original in: Software 2022, 1, 223-243 https://doi.org/10.3390/software1030010
2018: Soren Lauesen: Problem-Oriented Requirements in Practice - a Case Study (pdf). 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 (pdf).
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 (pdf).
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 (pdf).
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(pdf).
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 (pdf).
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 (pdf).
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? (pdf) 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 (pdf). 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, pdf). 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 (pdf). 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 (pdf). 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 (pdf). 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.
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@os.dk.
Sørens andre publikationer om krav (de fleste er på engelsk)