Kvalitet i højsædet - Kravspecifikation

Skrevet af Christian Lund

Det mest vitale i et større it-projekt, er at få skrevet en fyldestgørende kravspecifikation. Grundigt forarbejde sikrer, at kunden får det ønskede produkt. En kravspecifikation bruges til at afstemme interessenternes behov og forventninger for et system. Kravspecifikationen er ofte en kontrakt mellem kunde og leverandør, men bruges også til egenudvikling, hvor begge parter er afdelinger i samme virksomhed. At definere krav er noget af det vigtigste ved systemudvikling og samtidig en af de sværeste områder.

Kunden skal kunne validere kravene for at se de afspejler hans behov, han skal kunne læse og forstå kravspecifikationen, og herved sige dette system er hvad jeg skal bruge. Kravene skal når produktet er færdig kunne verificeres ved at gennemgå det, for at se det overholder forventninger og at alle kravene er med i produktet.

I WeloveSoftware bruger vi kravskabelon SL-07 som udgangspunkt til en kravspecifikation. Skabelonen er baseret på offentlige udbud efter EU-reglerne, den er dog med succes blevet brugt i over mange forskellige typer projekter. Lige fra udbud til egenudvikling, samt både agile og vandfalds projekter.

Følgende bygger på mange års praktisk erfaring og teori fra bogen “Software Requirements - Styles and Techniques” [Lauesen, 2002] og ”Vejledning til kravskabelon SL-07” [Lauesen, 2017], der begge er skrevet af Søren Lauesen.

Krav kan opdeles i fire undergrupper:

Datakrav
Kravene beskriver hvad der skal registreres, det som kommer ind og ud af databasen. Denne del udgør ca. 30 % af en kravene i en kravspecifikation.

Kvalitetskrav
Hvor hurtig skal systemet gøre tingene for optimal performance. Hvor brugervenligt skal softwaren være og hvor nem skal den være at vedligeholde? Denne del udgør ca. 15 % af en kravene.

Funktionskrav, brugergrænseflade
Hvilke funktioner skal systemet vise og hvordan kan det betjenes. Hvad sker der når man trykker på en knap og hvad kan man ellers gøre i de forskellige skærmbilleder. Hvordan er arbejdsopgaver (task) defineret, diagrammer og prototype. Denne del udgør ca. 30 % af en kravene.

Funktionskrav, eksterne systemer
Hvilke systemer skal softwaren integreres med og hvilke dele skal tredjepart skal kunne integrere med. Denne del udgør ca. 15 % af en kravene.

Derudover er der ledelseskrav, hvad må softwaren koste at udvikle og hvad sker der hvis noget går galt. Kravene skal tilgodese de forretningsmæssige mål.

Et godt krav er defineret som: korrekt, komplet, utvetydig, konsistent, redigerbar, verificerbar
og sporbar.

Et krav kan defineres på fire niveauer målsætnings-, domæne-, produkt- og design-niveau:

Målsætnings-niveau
Disser krav beskrives fra forretningen. Dette kan være at fjerne fejlkilder til fejlregistreringer. At automatisere opgaver for at opnå besparelser. Hurtigere at kunne planlægge vagtplaner.

Domæne-niveau
De forskellige arbejdsområder har hver deres krav til hvad softwaren skal kunne, altså hvilke bruger aktiviteter og task produktet skal understøtte. Dette kan være at man på systemet skal kunne oprette fakturaer og sende dem med e-mail. Systemet skal registrere og bruge erfaringsdata
 ved arbejdsopgaverne.

Produkt-niveau
Krav som beskriver funktioner i produktet. F.eks. systemet skal selv kunne udregne den billigste vagtplan, systemet skal have en registreringsfunktion og en genfindingsfunktion for erfaringsdata.

Design-niveau
Her bliver kravene beskrevet i detaljer, der gør at tingene skal se ud eller gøre på en bestemt måde. Som softwaren skal have skærmbilleder der ligner denne skitse, menuerne skal være en dropdown.

Projekttype

I Figur 1 Ses de forskellige projekttyper, som der kan udvikles efter. For projekter hvor der er en virksomhed, der ønsker deres eget produkt udviklet af ekstern leverandør. Vil det være projekttypen efter regning eller fastpris-projekt.

Figur 1

Figur 1, Projekttyper

Projektmodel

Det er er tre forskellige projektmodeller til at udarbejde en kravspecifikation. Den “traditionelle” er beskrevet på produkt-niveau, hvilket egner sig godt til underleverandører og vedligeholdelse, da de er mere detaljeret. “Domæne” modellen er ofte fem gange hurtigere end den traditionelle, da den beskriver de arbejdsopgaver som systemet skal understøtte og ikke går i detaljer. Den sidste model er “Two-step” som er domæne modellen kombineret med en prototype på design-niveau. For projekttyperne efter regning og fastpris-projekt kan projektmodel “Domæne" eller “Two-Step” med fordel benyttes afhængig af projektet, Figur 2.

Figur 2

Figur 2, Anbefalede projektmodeller (? bruges men tvivlsom, * Variabel pris)

1. Datakrav

I mange systemer er indholdet i databasen en væsentlig del. Derfor er det vigtig at specificere de data som et system skal gemme. Derudover kan det være vigtig at redegøre for data som kommer ud og ind af systemet.

Data-model

I en data-model bliver data som skal gemmes i systemet specificeret. Et eksempel er Entity/Relationship model (E/R) som består af Hønseben. Hver kasse har en relation til en anden af samme type. Forbindelsen mellem boksene viser en ”en til mange relation”, der findes også andre typer relationer. Et eksempel er vist i Figur 3 for et hotel system, hvor en kunde “Guest” kan have flere ophold “Stay”. Hvert værelse “Room” har en status “Room state” som er tilknyttet ophold “Stay” for hver dato.

Figur 3

Figur 3, Entity/Relationship model (E/R): Eksempel Hotel system

Data dictionary

En databeskrivelse viser indholdet i en dataklasse, som er hver kasse i E/R diagrammet, hvilket kan sammenlignes med indholdet i en databasetabel. En kunde “Guest” indeholder f.eks. name, address1, passport, phone og email. I SL-07 står de i afsnit D som D1, D2, D3 osv. I Figur 4 er der vist et eksempel på en databeskrivelse for et hotel system.

Figur 4

Figur 4, Data dictionary: Eksempel Hotel system

2. Funktionskrav

Kontekstdiagram

Et kontekstdiagram bruges til at vise interaktionen mellem brugerne og computere. Selve softwaren er en kasse med dobbeltramme omringet af de integrerede systemer og forskellige brugere tegnet som tændstikmænd. Pile viser hvordan data forbinder softwaren med dens omgivelser. Den vej pilen peger, viser hvem der sender data, en dobbeltpil betyder at data går begge veje. Diagrammet giver et godt overblik for udviklere over de forskellige interfaces, viser hvad der skal udvikles og hvad der mangler. Samtidig er diagrammet nemt at læse for kunderne. Kontekstdiagram står i SL-07 under afsnit A ”Baggrund og vejledning til leverandøren”, da dette giver et overblik for læseren over softwaren, derudover i afsnit F ”Integration med eksterne systemer”, Figur 5.

Figur 5

Figur 5, Kontekstdiagram: Eksempel Hotel system

Event liste og function liste

Et hændelse (Event) er når systemet skal udføre en funktion. En event liste viser de hændelser, som der kan komme i systemet. Hændelser kan opdeles i domæne hændelser og produkt hændelser. Domænehændelse sker i forretningen, som når en gæst f.eks. booker, checker ind eller skifter rum. Produkthændelse er de funktioner som systemet skal understøtte under en hændelse som find ledig rum, opret gæst og opret booking. En event liste er god til at have som en checkliste for hvad der skal udvikles. Den skal dog kun bruges ifølge SL-07 på design-niveau.

Task beskrivelser

En task er hvad en bruger og systemet skal kunne gøre sammen for at fuldføre en opgave. De er skrevet som en struktureret tekst i forskellige arbejdsområder. Et arbejdsområde kan være en reception, herunder er der forskellige opgaver som booking, checkin og checkout. Arbejdsområder beskrives og der laves en brugerprofil for området f.eks. en receptionist. Der defineres en start og slut for et task, f.eks. gæsten ankommer. En start er ofte noget der sker i brugerens verden og slut er når der ikke kan gøres mere ved det lige nu, beskrevet som en fortjent “kaffepause”. Hvor hyppigt det sker (f.eks. 100 gæster om dagen) og om der er noget kendt vanskeligt ved opgaven, f.eks. en bus fuld med gæster. Herefter defineres de forskellige sub-tasks i en liste f.eks. find værelse, register gæst, aflever nøgle osv. Task beskrivelser står i SL-07 under afsnit C “Tasks systemet skal støtte”. I Figur 6 ses et eksempel på en task beskrivelse for et hotel system.

Figur 6

Figur 6, Task beskrivelse: Eksempel Hotel system

Et andet eksempel er UML Use Case som blev introduceret af Ivar Jacobson i 1992 [Wikipedia, WWW, 1]. Use Cases er dog mest for teknikere og ekspertbrugere da overblikket hurtig mistes. Samtidig siger de ikke meget om de data som skal bruges til opgaverne (Task). Use cases kan ikke fange problemer med ukendt løsning, ofte de forretningskritiske behov, mennesker og computere er separeret i forhold til task. I Figur 7 er der vist et tilsvarende Use Case eksempel for hotel systemet. Derudover er der Data flow diagrammer (DFD) [Wikipedia, WWW, 2] der viser input og output til systemet. Samt ren XML (Extensible Markup Language) som dog ikke er overskueligt for brugerne, plus relationen er uklare for teknikere.

Figur 7

Figur 7, UML Use Case: Eksempel Hotel system

Decision table

En beslutningstabel er god til at beskrive de forskellige regler i forretningen. Udvikleren kan nemt se at programmet overholder de krav som er sat. I eksemplet Figur 8 er der vist hvornår der kan udløses rabat og hvor stor den skal være hvis kunden spørger. Hver kolonne er de forskellige muligheder for rabat, f.eks. viser kolonne et at der gives 25 % rabat hvis et dobbelt rum bliver brugt at en person. På denne måde sikres at systemet beregner rabatten rigtig, og der kan evt. laves et interface, så en superbruger selv kan rette i rabatterne.

Figur 8

Figur 8, Decision table: Eksempel hotel system

3. Kvalitetskrav

Kvalitetskrav er også kaldet for ikke funktionelle krav, disse beskriver f.eks. hvor let det skal det være at bruge systemet, hvor sikkert systemet skal være osv. Et kvalitetskrav vil ofte have et numerisk krav der skal overholdes, f.eks. at systemet skal vise ledige rum inden for 3 sekunder. Disse svartider er ofte et spørgsmål mellem cost og benefit. Hvis svartiden skal være mindre, vil systemet ofte blive dyrere. Samt billigere hvis det ikke gør noget, at det må tage 5 sekunder.

Kapacitetskrav

Definerer f.eks. hvor mange samtidige brugere der skal være på systemet, hvor mange poster tilføjes der i en database tabel per år. Nøjagtighedskrav kan være at et adresse felt skal indeholde max 100 tegn, og at det skal være muligt at bestille en billet 60 dage før.

Performancekrav

Definerer hvor hurtig systemet skal være. Dette kan f.eks. være at det skal være muligt at modtage 10 betalinger i sekundet, hvor meget CPU der skal være til rådighed osv.

Sikkerhedskrav

Er de risici der kan være ved at miste databasen og at harddisken går i stykker. Her opvejes mellem risici for at det sker. F.eks. at det estimeres at chancen for at miste databasen, er sandsynlig en gang hvert tiende år. Det kan også være et sikkerhedskrav, at produktet skal være duplikeret på to diske. I Figur 9 ses et eksempel på et risikovurderingsskema, og hvad det koster pr. tab hvis der sker noget. Her koster det f.eks. 1 million, hvis der kommer virus og dette er estimeret til at ske en gang om året.

Figur 9

Figur 9, Risikovurderingsskema

Vedligeholdelseskrav


Kan være hvor længe der skal gå før at en teknikker får kigget på et problem og at installation af en ny version skal sikre at databasen holdes intakt.

Usability

Hvad der skal usability testes er også en vigtig del i en kravspecifikation i følge SL-07, for at sikre de rigtige test bliver fuldført. Disse står beskrevet i afsnit I “Brugervenlighed og design”. Usability er beskrevet som en metode for sig selv i næste afsnit.

McCall og ISO 9126

En af de første lister for kvalitets krav er fra McCall og Matsumoto fra US Airforce i 1980 [McCall & Matsumoto, 1980]. De skiller mellem tre forskellige måder at bruge et system:

En kvalitetsmatrix ud fra McCall viser visuelt vigtigheden af de forskellige punkter, dette markeres ved om det er kritisk, vigtig, som vi plejer, mindre vigtig eller glem det.

I Figur 10 er et eksempel på en kvalitetsmatrix for et hotel system, følgende skal være anderledes:

  1. Oppetid er vigtig da det er svært at drive hotellet hvis systemet er nede og hermed få checket gæsterne ind.
  2. Produktet er også til mindre hoteller, som ikke altid har kvalificeret personale. Det skal være nemt at forstå hvordan systemet fungerer og hermed brugervenligt.
  3. Kunderne kan have mange forskellige regnskabssystemer, derfor er integrationen hertil vigtig.
  4. Dog er det mindre vigtig at kunne eksportere til f.eks. regneark.
  5. Personalet skal ideelt kunne installere systemet selv og skal være nemmere at gøre end
det nuværende.

Figur 10

Figur 10, Kvalitetsmatrix ud fra McCall: Eksempel hotel system

En anden standard er ISO 9126 fra 1991 der har seks niveauer Funktionalitet, Pålidelighed, Usability, Effektivitet, Vedligeholdelse og Portabilitet.

4. Andre krav

De grafiske skærmbilleder som brugerne ser, er ofte det som der tænkes på ved et nyt system. Bagved systemerne gemmer der sig andre vigtige dele som rapporter, platform krav og integration til
eksterne systemer.

Rapporter

Hvilke rapporter brugeren skal kunne få på skærmen eller have mulighed for at udskrive. Dette afhænger meget af hvilken type system det er, f.eks. vil et ERP system have behov for mange rapporter. Hvis der er særlige rapporter der ikke er beskrevet i SL-07 under afsnit C, vil disse skulle tilføjes afsnit E2. “Udskrift og rapporter”. F.eks. at systemet skal for superbruger kunne vise en oversigt over besøgende og betalinger på et website.

Platform krav

Det skal ofte defineres hvad kravene er til software og hardware for systemet. For et SaaS system kan dette være krav til server type, antal ram, plads osv. Hvilket sprog skal systemet udvikles i f.eks. php eller .net. Hvilken browsere skal systemet understøtte og version, f.eks. Internet Explorer >= 10, Firefox, Chrome, Safari osv. Dette er beskrevet i SL-07 under afsnit G “Teknisk IT-arkitektur”.

Integration

Hvilke eksterne systemer skal der integreres med, her bruges et kontekstdiagram til visuelt at vise sammenhængen mellem systemet. Disse systemer skal derefter beskrives, dette kunne f.eks. være integration til et økonomi system. Hvilke task skal støttes, er der både data import og eksport, svartider. Hvad skal der ske hvis svar udebliver, hvem skal adviseres. Integration står i SL-07 under afsnit F ”Integration med eksterne systemer”.

5. Sådan findes kravene

For at finde kravene er der forskellige typer af metoder, hvilken metode der skal vælges afhænger af projektet. Undervejs kan det ændre sig hvilken metode der er optimal for et kravområde, da andre metoder undervejs har ændret målet. Det gælder om at prøve sig frem med at teste de forskellige metoder, for at se hvad der virker. Det er bedst givet ud i stedet for at diskutere dem internt. Find f.eks. en virksomhed og lav et interview for at se om det giver noget, hvis ja kan der laves flere interviews.

Interessentanalyse

Interessenter er alle de mennesker der er involveret i projektet, det er vigtig at få styr på dem alle. Derefter finde ud af hvilke mål, risici og omkostninger de ser for systemet. Hvordan vil de gerne bidrage i projektet og hvilken slags løsninger ser de.

Interview

For at får viden om det nuværende arbejde og dagligdags problemer er et interview effektiv. Ved et nyt produkt kan det være at gå ud til de forskellige brugere som skal betjene softwaren, for at få klarlagt deres behov.

Observation

Det er ikke altid brugerne selv ved hvad deres behov er, derfor kan observation af deres daglige rutiner klarlægge det. Brugerne vil ikke altid svare det rigtige i et interview, en observation kan vise de faktisk ofte gør noget andet. Det som observation ikke fanger, er når noget en sjælden gang går galt.

Prototype

En prototype er en simpel version af det færdige system, hvilket giver udviklerne og brugerne mulighed for at se, hvordan systemet virker i praktisk. En prototype kan laves på produkt-niveau for at teste at systemet har alle funktionerne, det endelige produkt vil dog ikke se ud som prototypen. Alternativ på design-niveau hvor systemet ikke har funktion, men viser hvordan systemet vil kunne
se ud.

Brainstorm og Fokusgruppe

Ved en brainstorm bliver der samlet en gruppe af mennesker, de får her alle mulighed for at komme med deres idéer, som bliver skrevet ned. Der er både dårlige og gode idéer, men alle sammen kan lede til nye idéer. Det er efter brainstormen en god idé, ikke at dømme på forhånd hvad der er godt men tænke over det nogle dage.

En fokusgruppe er til forskel fra en brainstorm mere struktureret. Det starter med at deltagerne bliver præsenteret for den måde tingene bliver gjort på nu, de skal herefter finde den optimale måde at det kan gøres på. Der skal helst være flere grupper, hvor hver gruppe bagefter prioriterer, det som de synes der er vigtigst. Bagefter hjælper resultaterne til at klarlægge mål og krav til et nyt system.

Mål-domæne-analyse og Domæne-krav-analyse

Ofte glemmes relationen mellem forretningsmål og tasks i en kravspecifikation. Derfor er det vigtig at checke at det endelige system understøtter alle de vigtige mål, det gøres ved en mål-domæne-analyse.

En domæne-krav-analyse sikrer at alle krav er verificerbare. Det nytter ikke noget at have et krav, der siger at systemet skal være nemt at bruge, det må skrives om til hvad der sikrer, det er nemt at bruge.

6. Kontroller og valider kravene

Hvad skal der så til for at en kravspecifikation er fantastisk, i følge IEEE 830 [IEEE, 1998] er en god kravspecifikation defineret til at være følgende.

Ud over det som er nævnt i IEEE 830, er det vigtig der er sporbarhed fra mål til krav. Hvilket betyder at forretningens mål ikke må glemmes i analyserne, og at de skal være med som et krav. Det er også vigtig at kravene er forståelig af kunder og udviklere, ikke at de kun forstår ordene men også den rigtige betydning.

CRUD matrix

En måde at checke at der er konsistens, og at der ikke mangler noget i systemet er ved at lave en CRUD matrix.

I SQL er der fire kommandoer som er refereret til som CRUD, dette er INSERT (Create), SELECT (Read), UPDATE (Update), DELETE (Delete).

En anden variant er en CREDO matrix, her er Overview tilføjet som Create, Read, Edit, Delete + Overview. Overview bruges til at få et overblik over flere inputs eller søge efter dem, Overview er ikke standard for en CRUD matrix men er fundet nyttig til at supportere tasks.

Relationen mellem opgaver (Task) og dataklasser (Entity) er vist i tabellen. Hver celle i matrixen viser hvilke funktioner en bruger kan udføre på dataklassen for den specifikke opgave. I Figur 11 ses et eksempel på en CRUD matrix for et hotel system. Det er f.eks. ved check-in af en booking “checkinBooked” mulighed for at se allerede indtastede oplysninger for en “guest” eller
 opdatere oplysningerne.

Figur 11

Figur 11, CRUD matrix, Eksempel hotel system

7. Agil vs. vandfaldsmodel

Hvis du har læst om Lean Startup og MVP, tænker du måske hvordan hænger dette sammen med agil udvikling.

En kravspecifikation finder anvendelse i hele projektet som vist i Figur 12. I analysen bliver behov og krav fundet gennem interessenterne, hvor de samtidig bliver valideret. Selve kravspecifikationen er skrevet på dette grundlag. Hvis det er en ekstern leverandør, kan kontrakten bindes op på kravspecifikationen, kontraktdelen er derfor ikke relevant ved egenudvikling. De næste tre skridt er design, programmering og test. Der skal være sporbarhed både forlæns og baglæns, dette vil sige at kravene kan verificeres. Drift og vedligeholdelse er, når test har verificeret at produktet overholder alle krav. Hele flowet i Figur 12 kan køres som en vandfaldsmodel, et andet alternativ er at køre de tre steps design, programmering og test agil.

Figur 12

Figur 12, Anvendelse af kravspecifikation

For at bruge Lean Startup sammen med SL-07, kan en kravspecifikationen definere ens Minimum Viable Product (MVP). Planlægning foregår den anden vej rundt i Build-Measure-Learn feedback loopet. Planlægning kan derfor sammenlignes med analysen, der fører til en kravspecifikation for ens MVP. Hvad der skal læres, måles og hvilket produkt der skal bygges, står i en kravspecifikation skrevet efter skabelon SL-07.
Produktet bliver herfra designet, programmeret og testes ud fra kravspecifikationen “Build”. Ens MVP bliver herefter målt “Measure” som defineret i kravspecifikationen. Herefter kan man finde ud af “Learn”, om der skal forsættes eller skiftes kurs, begge dele gøres ved at opdatere kravspecifikationen. På denne måde kan hele flowet i Figur 12 køres i et agil loop i stedet for som en vandfaldsmodel.

8. Referencer

[Lauesen, 2002] Søren Lauesen, “Software requirements - Styles and techniques”, 2002, Pearson Education Limited
[Lauesen, 2017] Søren Lauesen, “Vejledning til kravskabelon SL-07”, 2017, 5. udgave, Lauesen Publishing
[Wikipedia, WWW, 1] wikipedia.org, "Use Case"
[Wikipedia, WWW, 2] wikipedia.org, "Data flow diagram"
[McCall & Matsumoto, 1980] Jim McCall & Matsumoto, “Software Quality Metrics Enhancements”, 1980, Rome Air Development Center
[IEEE, 1998] “IEEE Recommended Practice for Software Requirements Specifications”, 1998, IEEE