Kravspesifikasjon

Kravspesifikasjon handler om å definere hva systemet skal gjøre og hvilke kvalitetsegenskaper det skal ha. God kravspesifikasjon er fundamentet for et vellykket prosjekt -- uklare krav er en av de vanligste årsakene til at IT-prosjekter feiler. Det finnes to hovedtyper krav:

Funksjonelle krav: Beskriver konkret funksjonalitet systemet skal tilby -- hva systemet skal gjøre. Funksjonelle krav kan uttrykkes som brukerhistorier. Eksempel: 'Systemet skal la kunden søke etter ledige plagg etter type og dato', 'Systemet skal sende ordrebekreftelse på e-post etter gjennomført betaling.'
Ikke-funksjonelle krav: Beskriver kvalitetsegenskaper og begrensninger -- hvordan systemet skal fungere. Deles inn i tre kategorier ifølge Sommerville:
- Produktkrav: Ytelse, palitelighet, sikkerhet, brukervennlighet, portabilitet. Eksempel: 'Systemet skal svare på søk innen 2 sekunder ved opptil 1000 samtidige brukere.'
- Organisatoriske krav: Leveransefrister, standarder, utviklingsmetode, programmeringssprak. Eksempel: 'Systemet skal utvikles med Scrum i sprinter på 2 uker', 'Koden skal følge ISO 27001-standarden.'
- Eksterne krav: Lovkrav, etiske krav, interoperabilitet med andre systemer. Eksempel: 'Systemet skal tilfredsstille WCAG 2.0 AA', 'Systemet skal overholde GDPR artikkel 25 (innebygd personvern).'

Alle ikke-funksjonelle krav skal være testbare og malbare. 'Systemet skal være raskt' er for vagt og ikke testbart. 'Systemet skal svare innen 2 sekunder på 95% av forespørsler malt med JMeter' er testbart. Eksamen ber deg alltid forklare HVORDAN hvert ikke-funksjonelt krav kan testes.

Brukerhistorier

En brukerhistorie (user story) følger formatet: Som [rolle], ønsker jeg [funksjonalitet], slik at [nytte]. Alle tre delene må være med. Brukerhistorier brukes til å beskrive funksjonelle krav fra brukerens perspektiv og legges i produktkøn (Product Backlog). De skal være korte og konsise -- en fullstendig brukerhistorie bør få plass på en post-it-lapp. Brukerhistorier skal prioriteres, og på eksamen bes du typisk om å sette dem i prioritert rekkefølge med begrunnelse.

Tips for å finne brukerhistorier: Les caseteksten og identifiser alle ROLLER (kunde, administrator, utleier osv.) og alle HANDLINGER de utfører. Kombiner roller og handlinger til brukerhistorier med en tydelig nytte-del.

Interessenter

En interessentanalyse identifiserer alle som påvirkes av eller har interesse i systemet. Interessenter deles i primære aktører (de som bruker systemet direkte og initierer interaksjon) og sekundære aktører (de som påvirkes indirekte, støtter systemet, eller har overordnet interesse). For hvert system bør du identifisere minst 5-6 interessenter med navn på rollen og hvilken spesifikk interesse de har knyttet til utvikling og/eller drift av systemet. Sett dette opp i en oversiktlig tabell med kolonnene: Rolle, Interesse, Primær/Sekundær.

Rikt bilde

Et rikt bilde (rich picture) er en uformell, håndtegnet illustrasjon som viser interessenter, deres relasjoner til hverandre og til systemet, og potensielle konflikter. Rikt bilde brukes tidlig i prosjektet for å få en helhetlig oversikt over problemomradet og for å skape felles forståelse i teamet. Det er IKKE et UML-diagram -- det bruker frie tegninger, bobler, piler og stikkord.

Eksempel 1: Brukerhistorier for Festklar.no (V2020)

Prioritert liste med minst tre forskjellige aktører: 1. Som kunde, ønsker jeg å søke etter ledige kjoler etter dato og type, slik at jeg kan finne et plagg til festen min. 2. Som kunde, ønsker jeg å betale med Vipps eller kort, slik at betalingen er enkel og sikker. 3. Som utleier, ønsker jeg å registrere mine egne plagg for utleie med bilder og beskrivelse, slik at jeg kan tjene penger. 4. Som administrator, ønsker jeg å se statistikk over utleide plagg per periode, slik at jeg kan planlegge innkjop og markedsforing. 5. Som medlem av kundeklubben, ønsker jeg å betale med opptjente poeng, slik at jeg får belonning for lojalitet. 6. Som renseri, ønsker jeg å motta bestillinger for rensing med hentedato, slik at jeg kan planlegge kapasiteten. Begrunnelse for prioritering: Søk og betaling (1-2) er kjernefiinksjonaliteten, utleie (3) er viktig for tilbudssiden, statistikk (4) for forretningsstyring.

Eksempel 2: Ikke-funksjonelle krav for Festklar.no (V2020)

Produktkrav (ytelse): Nettsiden skal laste inn på under 3 sekunder ved opptil 500 samtidige brukere. Testbart med: JMeter belastningstesting. Organisatorisk krav: Systemet skal utvikles med kontinuerlig integrasjon og automatiserte tester, og ny kode skal reviews for merge. Testbart ved: sjekke at CI/CD-pipeline er konfigurert og at alle PRer har minst en godkjenning. Eksternt krav (lov): Systemet skal overholde GDPR for lagring og behandling av kundedata. Testbart ved: gjennomføre en personvernkonsekvensutredning (DPIA). Produktkrav (sikkerhet): Betalingsinformasjon skal krypteres med TLS 1.2 eller nyere og aldri lagres i klartekst. Testbart med: SSL Labs-test og kodegjennomgang av databasehandtering.

Studieguide: Kravspesifikasjon og brukerhistorier

Studieguide: Kravspesifikasjon og brukerhistorier