Kravspecifikation: Forskelle mellem versioner
Bar (diskussion | bidrag) m 1 version importeret |
Bar (diskussion | bidrag) Ingen redigeringsopsummering |
||
| Linje 14: | Linje 14: | ||
* Krav til installation, vedligeholdelse og drift. | * Krav til installation, vedligeholdelse og drift. | ||
Kravspecifikationen er ofte grundlaget for en kontrakt for udvikling af systemet. Har man for mange krav bliver systemet dyrt at udvikle. Har man for få krav, får man måske ikke det, man har behov for. Man må ikke tage noget for givet. Har man glemt noget kan det komme til at koste dyrt senere i projektet. Det handler om at formulere sig kort og præcist. Efter en kravspecifikation er udviklet vil man ofte afholde et formelt review. | Kravspecifikationen er ofte grundlaget for en kontrakt for udvikling af systemet. Har man for mange krav bliver systemet dyrt at udvikle. Har man for få krav, får man måske ikke det, man har behov for. Man må ikke tage noget for givet. Har man glemt noget kan det komme til at koste dyrt senere i projektet. Det handler om at formulere sig kort og præcist. Efter en kravspecifikation er udviklet vil man ofte afholde et formelt review. | ||
{{start-Arduino}} | |||
[[Kategori:Software_Udviklingsteknikker]] | [[Kategori:Software_Udviklingsteknikker]] | ||
Nuværende version fra 31. okt. 2022, 22:27
Som udgangspunkt starter man med at lave brainstorm over forslag og ønsker til systemet. Bemærk at i denne del af specifikationsfasen må man gerne tænke divergent. Senere i fasen gælder det om at konvergere indtil man har formuleret de specifikke krav, man har til systemet. Det er vigtigt at beskrive kravene klart og entydigt, da dem der udvikler systemet ofte ikke er de samme, som dem der specificerer det. Det er også vigtigt at få alle kravene med. Glemmer man noget, kan det blive dyrt at tilføje senere. Derfor er der også en række metoder og værktøjer, som på systematisk vis kan hjælpe med at analysere og definere krav.
Figur 1. Use Cases for en restaurant
En god metode til analyse af krav er brug af Use Cases (se figur 5). I modellen har man aktører (personer), som udfører aktiviteter ind i en proces. Ved at tegne denne sammenhæng, og efterfølgende beskrive processen i en ”Use Case beskrivelse” kan man få et godt holistisk overblik over systemet på en velstruktureret måde. Det er vigtigt at man overholder notationsformen, da den er standardiseret, så software udviklere nemt kan læse dem (Use Cases er en del af UML - Unified Modelling Language -standarden). Et eksempel på en Use Case beskrivelse kan findes i Use Case Eksempel 1.
Andre metoder, som kan benyttes til analyse og afklaring af specifikationer er Data Flow Analyser, State Transition diagrammer eller Objekt Orienteret Analyse.
Der findes ”Case værktøjer” som understøtter tegning af Use Cases (og andre software analyse metoder), men til små opgaver kommer man langt med tegneværktøjet draw.io, som er gratis.
Når man har dannet sig et overblik på systemet skal de specifikke krav nedskrives. Det gøres ofte i klar og tydelig tekst, og på listeform. Der er flere forskellige typer af krav.
- Funktionelle krav beskriver hvad systemet skal kunne
- Kvalitative krav beskriver hvor godt systemet skal fungere (Performance, Usability, Availability, Security)
- Krav til installation, vedligeholdelse og drift.
Kravspecifikationen er ofte grundlaget for en kontrakt for udvikling af systemet. Har man for mange krav bliver systemet dyrt at udvikle. Har man for få krav, får man måske ikke det, man har behov for. Man må ikke tage noget for givet. Har man glemt noget kan det komme til at koste dyrt senere i projektet. Det handler om at formulere sig kort og præcist. Efter en kravspecifikation er udviklet vil man ofte afholde et formelt review.