Den mest komplette guide til kravstyring og sporbarhed

Sådan skriver du gode krav

Q: Visure Krav ALM Platform for kravspecifikation

Visure Requirements ALM Platform er en af de mest pålidelige applikationslivscyklusstyringsplatforme, 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.

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.

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.

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.

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.

20 tips til at skrive bedre krav

Hver organisation har en anden arbejdsmetode, og derfor et andet sæt krav. Derfor kan processen med kravstyring også variere. Men en ting, der forbliver konsekvent, er de grundlæggende krav til skrivekrav. Nedenfor er 20 tips til at skrive bedre krav.

En ad gangen – 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.

Tal "hvad" ikke "hvordan" – Fokus skal være på, hvad systemet vil gøre, ikke hvordan det gør det. Undgå desuden at dykke for dybt ned i designemner såsom feltnavne, programmeringssprogsobjekter og softwareobjekter. Hvis du finder dig selv at diskutere disse emner i kravspecifikationsdokumentet, så tag et skridt tilbage – det betyder sandsynligvis, at du bliver for specifik.

verificerbar – En anden ting, man skal huske på, når man organiserer krav, er, at de altid skal være testbare. Det betyder, at det skal være muligt at verificere, at systemet lever op til det pågældende krav. Dette linker også til vores næste punkt – sporbarhed. Hvis et krav er fyldt med vage udtryk, så bliver det sværere at analysere og verificere, om systemet rent faktisk lever op til disse standarder. Sigt derfor så vidt muligt efter klarhed og præcision i dit sprog, så kravindsamlingen ikke er en tvetydig proces.

Sporbarhed – Sporbarhed i projektledelse refererer til at sikre, at krav er knyttet til andre komponenter i projektet. Dette giver projektledere, udviklere og interessenter mulighed for at holde styr på et kravs hele livscyklus fra start til slut i alle retninger såvel som med andre dele af systemet. Hvis du styrer sporbarheden korrekt, kan du undgå kode, der ikke svarer til noget krav ('stray'-kode), og sikre dig, at hver testcase dækker mindst ét krav. Du kan gøre krav sporbare ved at mærke dem med en unik identifikator og give oplysninger om deres kilde i et centralt lager, der er tilgængeligt for alle teammedlemmer.

Gennemførlig – Sørg for, at projektets budget og tidslinje er gennemførlig sammen med tilgængelige ressourcer. Hvis disse forhold kan understøtte kravet, så er det muligt at komme videre med planen.

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.

Undtagelser – Et krav bør ikke have en flugtklausul. For eksempel, "Systemet skal bestemme antallet af loginforsøg, undtagen når brugeren tydeligt har indtastet et forkert brugernavn".

Aktiv stemme – Skriv altid med en aktiv stemme, og sørg for, at en af skuespillerne er genstand for hver sætning.

Sig nej til "udleje"-klausuler – Forsøg at holde dig væk fra undladende sætninger som men, undtagen, og kun hvis det er nødvendigt.

Ingen forkortelser – Ethvert krav skal være en hel sætning uden nogen akronymer eller jargon.

Emne & prædikat – For hvert krav skal der være et emne (bruger/system) og et prædikat (tilsigtet resultat, handling eller tilstand).

Klarhed – Undgå tvetydighed forårsaget af brugen af akronymer som, osv., ca. og lignende.

Brug de rigtige vilkår – Ukendte termer som brugervenlig, alsidig og robust kan skabe vanskeligheder, når man forsøger at definere testcases. Disse ord har ofte forskellige betydninger for forskellige mennesker.

Spekulationer kan forårsage skade – Gæt ikke; lav ikke lister over funktioner, der er udelukkede. At sige, at du vil have et system til at håndtere alle uventede fejl, er ren fantasi, da intet system nogensinde vil være 100 procent, hvad du ønsker, det skal være. Undgå dobbeltarbejde og modstridende udsagn.

Undgå indstillinger – Giv ikke ideer eller muligheder. Du kan se disse i enhver erklæring, der inkluderer sætningerne kan, kunne, kunne eller burde.

Organiseret papirarbejde gør underværker – Hold kravene organiseret ét sted for at forbedre læsbarheden af dit dokument og undgå at spilde tid på at krydshenvise flere kilder.

Tal med hvad vi har – Henvis ikke til et endnu ikke-defineret krav. Dit mål er at gøre dokumentet så behageligt at læse som muligt.

Hvad skal bruges og hvor? – "Skal" skal bruges, hvor krav er angivet, "Vil" skal bruges til at repræsentere kendsgerninger; & "Bør" for at repræsentere et mål, der skal nås.

Korrekt – Sørg for, at hver sætning er komplet og grammatisk korrekt med et korrekt emne, verbum og prædikat.

Fokus – Etabler fokus ved at eliminere tumult, for lange sætninger og henvisninger til forældede papirer.

Visure Krav ALM Platform

Visure Krav ALM Platform 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!

Glem ikke at dele dette opslag!