En af de vigtigste dele af ethvert softwareudviklingsprojekt er at skabe detaljerede, nøjagtige krav. Uden en klar forståelse af, hvad der skal bygges, er det umuligt at skabe et slutprodukt af høj kvalitet. Desværre er det ofte lettere sagt end gjort at skrive gode krav. Den primære årsag til, at folk skriver dårlige krav, er, at de ikke har haft nogen uddannelse eller erfaring med at skrive gode krav. Har du eller dine medarbejdere problemer med at skrive gode krav, kan du med fordel få vejledning i, hvordan du skriver gode krav. Ved at tage dig tid til at lære at skrive bedre krav, kan du forbedre den overordnede kvalitet af dine softwareudviklingsprojekter – og spare dig selv for en masse hovedpine hen ad vejen.

Hvorfor mislykkes systemtekniske projekter?

Hvorfor fejler projekter i stærkt regulerede industrier? Mange forskere har undersøgt, hvorfor systemer og softwareprojekter fejler. Standish-gruppen foretog forskning i 2009, som fremhæver, at de fleste årsager til, at projekter mislykkes, er relateret til krav.

Det er en af ​​hovedårsagerne til, at det at skrive gode krav er afgørende for projektets succes. Derudover giver det at skrive gode krav mange andre fordele på tværs af teams.

Hvad er kravspecifikation?

Kravspecifikation er en proces, hvor krav defineres, dokumenteres og analyseres. Det er en vigtig del af softwareudvikling, fordi det sikrer, at alle interessenter er enige om softwarens funktionalitet, før udviklingen begynder. Ved at gøre dette reduceres sandsynligheden for misforståelser og omarbejdelser senere.

Kravspecifikation, også kendt som dokumentation, er en proces med at notere eller skrive alle system- og brugerkrav i form af et dokument. Disse krav skal være klare, fuldstændige, omfattende og konsekvente.

Krav Engineering Process

Der er nogle få aktiviteter, vi står over for, når vi arbejder med kravene. I Requirements Engineering-cyklussen er der fem hovedaktiviteter, nemlig

1. Krav Elicitation – Dette er processen med at indsamle, gennemgå og forstå interessenternes og brugernes behov og begrænsninger for sæsonen. Brugere har brug for domæneoplysninger, eksisterende systemoplysninger, regulativer, standarder osv. Baseret på disse oplysninger fremkalder vi kravene. Herefter går vi over til kravanalyse og forhandling. 
2. Kravanalyse og forhandling – Analyse er processen med at forfine brugernes behov og begrænsninger på grundlag af indsamlet og fremkaldt information. Derefter går vi til dokumentationsaktiviteten. 
3. Krav Dokumentation/Specifikation – Efter at have fået kravspecifikationerne går vi videre til dokumentationsdelen. Vi dokumenterer brugernes behov og begrænsninger klart og præcist. 
4. Validering af krav – Til sidst, i valideringsaktiviteten, indsætter vi, at sæsonkravene er fuldstændige, kortfattede og klare. 
5. Kravstyring – Kravstyring er en måde at indsamle, analysere, forfine og prioritere alle produkter eller krav i udviklingsfasen. I denne fase etableres også solid sporbarhed mellem kravene og informationskilderne. 

Når vi afslutter disse fem aktiviteter, gentager vi dem igen og igen, indtil vi får et sæt aftalte kravdokumenter, der er formelle specifikationer.

Hvorfor er det vigtigt at skrive gode krav?

Der er mange fordele ved at have gode kravspecifikationer. Nogle af dem er anført nedenfor:

• Er med til at sikre, at alle interessenter har en fælles forståelse af det system, der skal udvikles. Dette undgår enhver misforståelse under senere udviklingsstadier.
• Fungerer som referencepunkt for alle interessenter under udviklingsprocessen.
• Hjælper med at identificere eventuelle huller i kravene på et tidligt tidspunkt.
• Reducerer de samlede omkostninger og udviklingstid, da det undgår omarbejde på grund af ændringer i krav.

Hvad opnår vi ved at skrive store krav?

Der er mange ting, store krav hjælper med at opnå. Nogle af dem er anført nedenfor:

• Store krav er med til at sikre, at det system, der udvikles, lever op til brugernes behov.
• De tjener som grundlag for at teste systemet for at sikre, at det fungerer som forventet.
• De hjælper med at reducere de samlede omkostninger og udviklingstid ved at undgå omarbejde på grund af ændringer i krav.
• Store krav er med til at gøre udviklingsprocessen mere effektiv.

Udfordringer ved skrivekrav

Der er forskellige udfordringer, folk står over for, når de skriver krav.

Dårligt papirarbejde – I nogle organisationer er dokumentation af processer enten ikke-eksisterende eller ikke på niveau. I dette tilfælde bliver indsamling af krav en proces i to trin: først reverse engineering af den eksisterende proces, og derefter identificere områder, der skal forbedres og optimeres. For at bekræfte, at kravene er uddybet og præcise, er det nøglen til at identificere nøgleinteressenter og emneeksperter, og engagere sig direkte med dem. At tegne forretningsproceskort og visualisere arbejdsgange er to fremragende måder at gøre det på. Dette hjælper med at eliminere forkerte antagelser og giver samtidig et komplet billede. Tegning af proceskort og visning af processer er to nyttige tilgange til dette formål.

Modstridende krav – Når interessenter har forskellige prioriteter for deres forretningsmål, fører det til krav, der er i konflikt med hinanden. I tilfælde som disse er det en forretningsanalytikers ansvar at dokumentere alle krav i detaljer, identificere hvilke anmodninger, der modarbejder hinanden, og give interessenter mulighed for at beslutte, hvad der skal prioriteres.

Du kan ikke træffe beslutninger uden at høre interessenternes input, og som forretningsanalytiker har du måske nogle ideer om, hvad der bør prioriteres. Det er stadig afgørende at høre interessenternes perspektiv. Opsætning af en meningsmåling kan være en af ​​metoderne til at opnå klarhed over, hvad der betyder mest for flertallet af interessenter.

Utilgængelighed af brugerinput – Et par årsager kan bidrage til, at slutbrugere ikke er tilgængelige, og hver enkelt kræver sin egen løsning. For eksempel er slutbrugere nogle gange så optaget af deres daglige arbejde, at de ikke er villige til at deltage i kravindsamlingsaktiviteter.

I sådanne tilfælde er det bedste, en forretningsanalytiker kan gøre, at begrænse antallet og længden af ​​engagementer. Forud for mødet vil det at lave så meget research som muligt bidrage til at gøre diskussionen mere organiseret og informativ. Det er næsten som at omdanne kravindsamling til kravvalideringssessioner. at definere fokusgrupper og identificere de bedst egnede slutbrugere for hver gruppe

Fokus på grænseflade i stedet for oplevelse – Mange interessenter og slutbrugere har en klar vision om, hvordan den nye løsning skal fremstå, men de ved ikke, hvad den skal udrette. Ethvert systems brugergrænseflade er afgørende, men den bør ikke definere eller forstyrre funktionaliteten.

Forretningsanalytikere bør altid huske at holde design- og funktionskrav adskilt i deres dokumentation. Ved at bruge mere generelle værktøjer såsom diagrammer, brugerhistorier eller low-fi prototyper frem for designudkast, kan de bevare fokus på de funktionelle aspekter af kravindsamling.

Interessenternes input – Når interessenter eller slutbrugere forsøger at fortælle designere, hvordan systemet skal fungere i stedet for, hvad systemet skal gøre, kan det føre til suboptimale designs. For at afværge dette, valider hvert potentielt 'falske krav' ved at spørge 'hvorfor?' indtil du når frem til det virkelige problem, der skal løses.

Kommunikationsproblemer – Blandt de problemer, der kan føre til fejlkommunikation mellem en forretningsanalytiker og andre parter, er sprogbarrierer, forkerte antagelser, utilstrækkeligt forklaret ordforråd og overforbrug af tekniske termer.

Den ideelle tilgang til at undgå dette problem er at interagere ofte og udvikle tovejssamtaler. Dokumenter de behov, du har opdaget, og send dem til peer review og kritik til en række fagspecialister, lav en ordliste med jargon og dobbelttjek lokaler.

Standarder for skrivekrav?

EARS ville være en effektiv metode her. Det står for Easy Ahenvende sig til Rudstyr Syntax, af Alastair Marvin. I denne metode skriver vi et klart, kortfattet og forståeligt sprog. Dette forbedrer hele den tekniske arbejdsgang og forenkler arbejdet ved at gøre tingene ret nemme at forstå. 

For at opnå dette er her nogle principper, som du skal huske på, mens du skriver kravene. De involverer:

• Hvert krav skal være i form af en hel sætning. Der må ikke bruges punkttegn, akronymer, forkortelser eller buzzwords. Prøv at lave korte, direkte og komplette sætninger. 
• Sørg for, at hvert krav har et korrekt emne, prædikat og verbum. Emnet ville være brugertypen eller det system, vi taler om. Prædikatet ville være de betingelser eller handlinger eller ønskede resultater, vi forventer. Vi skal bruge ord som 'skal', 'vil' og 'skal' for at udtrykke en form for nødvendighed, og ord som 'må' til at udtrykke valgfrihed i kravet. 
• Hvert krav skal effektivt forklare det slutresultat, vi ønsker fra systemet. 
• Kravet skal også beskrive den kvalitet, vi forventer af systemet. Det hjælper, når vi måler slutresultatet og ser, om kravet er korrekt implementeret eller ej.

Væsentlige komponenter i et kravdokument:

Hovedafsnittene i en softwarekravspecifikation er:

• Forretningsdrivere – Grundene til, at kunden ønsker at bygge et system, er beskrevet i dette afsnit. Dette afsnit inkluderer yderligere de problemer, kunden står over for med det nuværende system, og de muligheder, det nye system vil give.
• Forretningsmodel – Den forretningsmodel, som systemet skal understøtte, diskuteres i dette afsnit. Det inkluderer yderligere forskellige andre detaljer som den organisatoriske og forretningsmæssige kontekst, hovedforretningsfunktioner og procesflowdiagrammer for systemet.
• Funktions- og systemkrav – Dette afsnit beskriver typisk krav, der er organiseret i en hierarkisk struktur. Funktionskravene er på øverste niveau, og de detaljerede systemkrav er angivet som underpunkter.
• Systembrugssager – Dette afsnit består af et Unified Modeling Language (UML) use case-diagram, der forklarer alle de eksterne nøgleenheder, der vil interagere med systemet, og de forskellige use cases, de skal udføre.
• Tekniske krav – Dette afsnit diskuterer alle de ikke-funktionelle krav, der udgør det tekniske miljø, og de tekniske begrænsninger, som softwaren vil fungere under.  
• Systemkvaliteter – I dette afsnit er systemets mange kvaliteter defineret, såsom pålidelighed, servicevenlighed, sikkerhed, skalerbarhed, tilgængelighed og vedligeholdelse.
• Begrænsninger og forudsætninger – Alle de begrænsninger, der er pålagt systemdesignet fra kundens synspunkt, er beskrevet i dette afsnit. De forskellige antagelser fra ingeniørteamet om, hvad de kan forvente under udviklingen, diskuteres også her.
• Acceptanskriterier – Nærmere oplysninger om alle de betingelser, der skal være opfyldt, før systemet overdrages til de endelige kunder, er beskrevet i dette afsnit.

Karakteristika for et softwarekravspecifikationsdokument:

• Klar – De skriftlige krav skal være klare, lette at læse og forståelige. Angiv tydeligt oplysningerne ved hjælp af bekræftende sætninger, der skal udveksles mellem aktørerne. Ethvert krav skal beskrive klare succeskriterier. Prøv at bruge et simpelt ordforråd og undgå forkortelser. For eksempel "Brugeren skal være i stand til at se revisionslograpporten".
• Atomic – Hvert krav bør behandles som et diskret testtilfælde. Konjunktioner som og, eller og så videre bør ikke bruges, fordi de kan føre til at man går glip af krav. Dette er især afgørende, da udtryk som disse kan få softwareudviklere og testere til at overse kravene. At opdele komplicerede behov i mindre dele, indtil hver enkelt kan testes separat, er en måde at forhindre dette i at ske.
• Utvetydig – Uklare, ufuldstændige eller modstridende krav kan føre til fejl og omarbejde. For at forhindre dette i at ske, bør kravene gennemgås af alle interessenter, før de færdiggøres. Dette vil hjælpe med at identificere eventuelle huller tidligt, som derefter kan løses.
• verificerbar – Alle i udviklingsteamet bør have adgang til dokumentet, så de kan henvise til det så ofte som nødvendigt. Fordi kravene skal være klare, ønsker teammedlemmer ikke mere information. De skal alle være tilgængelige i SRS-dokumentet.
• Nødvendig – Hvert krav skal dokumentere noget, som brugerne virkelig har brug for, eller noget, der kræves for at opfylde et standard- eller integrationsbehov på grund af eksistensen af ​​en ekstern grænseflade. Det er også vigtigt for hvert krav at have en autoriseret kilde.
• Design uafhængig – Hvert krav skal definere, hvad der er nødvendigt, ikke hvordan det skal implementeres. Kravene skal definere systemets egenskaber, der skal observeres eksternt, ikke de interne detaljer.
• Gennemførlig – Hvert krav skal være teknisk eksekverbart og bør implementeres under hensyntagen til budgettet, deadline og andre begrænsninger, der påvirker projektet. Kravene bør afspejle den faktiske situation, herunder omkostninger, tidslinje og teknologi. De bør ikke være betingede af fremtidige teknologiske fremskridt.
• Komplet – Kravdokumentet bør indeholde tilstrækkelig information til, at dit udviklingsteam og testere kan færdiggøre produktet og sikre, at det opfylder brugerens krav uden fejl.
• Korrekt – Krav specificeret i dokumenterne bør være meget præcise for at undgå enhver form for forvirring. De må ikke have smuthuller, tvetydigheder, subjektivitet, superlativer eller sammenligninger. For at kunne skrive korrekte krav skal vi derfor indhente korrekte oplysninger og korrekt dokumentere de indsamlede oplysninger.

Regler for sæt af korrekte krav

Der er visse regler, som kravene skal overholde for at blive kaldt "Korrekt".

• Komplet – Kravdokumentet bør indeholde tilstrækkelig information til, at dit udviklingsteam og testere kan færdiggøre produktet og sikre, at det opfylder brugerens krav uden fejl.
• Sammenhæng – Oprethold et ensartet detaljeringsniveau. For eksempel, for brugerkrav, bør en slutbruger være genstand for hver sætning. På samme måde, for systemkrav, bør et system være genstand for hver sætning.
• Modificerbarhed – Kravene kan ændre sig gennem projektets livscyklus. Kravloggen skal opbevares, og det bør være muligt at analysere effekten af ​​ændringer, der er foretaget heri, på andre krav og projektelementer.
• Prioritering – Kravene skal klassificeres ud fra et vigtigt synspunkt. Ikke alle de egenskaber, der ønskes for et system, er lige vigtige. Til det ville det være nyttigt at etablere en regel for at definere kravprioriteter på organisationsniveau og tilpasse den til hvert projekt. Og arbejde sammen med brugerne, så de kan prioritere kravene.

Visure Krav ALM Platform

Visure er en af ​​de mest betroede platforme til administration af applikationslivscyklus, der specialiserer sig i kravstyring for organisationer af alle størrelser over hele kloden. Visures største partnere omfatter forretningskritiske og sikkerhedskritiske virksomheder. Virksomheden integrerer gennem hele Application Lifecycle Management-processerne, herunder risikostyring, problem- og defektsporing, sporbarhedsstyring, ændringsstyring og forskellige andre områder som kvalitetsanalyse, kravversionering og effektiv rapportering.  

Hvis du leder efter et kravstyringsværktøj, der hjælper dig med både funktionelle og ikke-funktionelle krav, så tjek Visure Requirements. Med denne platform kan du nemt oprette, administrere og spore alle dit projekts krav på ét sted.

Konklusion

For at producere fantastisk software er det vigtigt at have en velskrevet kravspecifikation. Dette dokument beskriver kundens behov, og hvad systemet skal gøre for at leve op til deres forventninger. Det kan dog være udfordrende at skrive gode krav. Der er mange standarder og retningslinjer, der skal følges, og der er mange forskellige måder at skrive dem på afhængigt af det sprog og de værktøjer, du bruger. Visure Requirements ALM Platform tilbyder et kursus, der lærer dig, hvordan du skriver effektive kravspecifikationer ved hjælp af bedste praksis og industristandarder. Kurset dækker alle væsentlige komponenter i et kravdokument, fra struktur til formatering, samt hvordan man bruger forskellige sprog til skrivekrav. Det fremhæver også egenskaberne ved store krav, så du kan oprette dokumenter, dit team vil elske at arbejde med. Hvis du vil lære mere om at skrive effektive krav, kan du prøve Kravspecifikationskursus af Visure Requirements ALM Platform i dag!