Visure-løsninger


Support
Tilmeld
Login
Start gratis prøveversion

Krav til skrivemåder og ikke-måder

Krav til skrivemåder og ikke-måder

Indholdsfortegnelse

Hvis du er som de fleste andre, nyder du sandsynligvis ikke skrivekrav. Det er ikke det mest spændende i verden, men det er en kritisk del af produktudviklingen. Et bedre kravdokument kan spare din organisation en formue med klar kommunikation mellem udvikleren og produktinteressenter. Dette afspejler igen på tværs af organisationen, herunder større gennemsigtighed, mindre omarbejde og forbedret produktivitet.

Mens hver organisation har forskellige krav og metoder, forbliver det grundlæggende for skrivekrav de samme. I denne artikel vil vi dele et par tips, der kan hjælpe dig med at forbedre dine krav til skrivefærdigheder og hjælpe dig med at skrive klare og klare kravspecifikationer.

Hvad er kravspecifikation?

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

Under indfangningsaktiviteten samler vi alle kravene fra forskellige kilder. Under analyse- og forhandlingsaktiviteterne analyserer og forstår vi disse krav. Nu skal vi udarbejde et formelt dokument, der forklarer disse krav. Det er det, der er kravspecifikationen. For at være præcis er det processen med at dokumentere alle bruger- og systembehov og begrænsninger på en klar og præcis måde.

Hvad betyder "bedste praksis" i kravstyring?

Det er så interessant for mig, at alle taler om, at de gerne vil have træning i "best practices". Dette udtryk bruges ofte til at beskrive den form for rådgivning, vi også kan tilbyde. Hvad betyder det egentlig? Jeg tror på, at vi alle har fodret ind i myten om, at bedste praksis kan være grundlaget for træning af individer. Bedste praksis er ikke trænet, de er erfarne.

Hvis vi sammenligner den bedste praksis-tilgang til naturen, ved vi, at det ikke kun er den stærkeste, men den mest produktive art, der overlever. Det er en af ​​grundene til, at det er så svært at ændre processer i en organisation. Tænk over det et øjeblik. De stærkeste og mest produktive beskriver nok størstedelen af ​​individer, du har i stort set enhver gruppe i din organisation. Jeg har set dette igen og igen i System Engineering-området. De stærkeste og mest produktive ingeniører har ofte udført deres arbejde i mange år og har en bestemt måde, de udfører dette job på. At bede dem om at prøve nye teknikker og værktøjer er ofte nyttesløst, da de ikke ved, hvordan dette vil forbedre det allerede vidunderlige arbejde, de udfører. Deres praksis vil overleve, hvis vi fortsætter med at skubbe en best-practice tilgang til dem.

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.

10 må og lad være med at skrive krav:

Gør #1. 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.

Lad være med at #1. 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.

Gør #2. 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.

Lad være med at #2. Ingen 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".

Gør #3. Gennemførlig – Sørg for, at projektets budget og tidslinje er gennemførlig sammen med tilgængelige ressourcer. Hvis denne betingelse kan understøtte kravet, så er det muligt at gå videre med planen.

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

Gør #4. 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.

Lad være med at #4. Ingen forkortelser – Ethvert krav skal være en hel sætning uden nogen akronymer eller jargon.

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

Lad være med at #5. Vær ikke tvetydig – Brug ikke tvetydige udtryk som f.eks ca osv., og flere udtryk som det i kravdokumentet. Sørg for at forklare kravene på en sådan måde, at alle involverede forstår dem korrekt. Vage udsagn kan føre til fejlfortolkninger og kan forårsage konflikter mellem forskellige interessenter.

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

Lad være med at #6. 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.

Gør #7. 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.

Lad være med at #7. Undgå indstillinger – Giv ikke ideer eller muligheder. Du kan se disse i enhver erklæring, der inkluderer sætningerne kan, kunne, kunne eller burde.

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

Lad være med at #8. Tal ikke i fremtiden – Henvis ikke til et endnu ikke-defineret krav. Dit mål er at gøre dokumentet så behageligt at læse som muligt.

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

Lad være med at #9. 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.

Gør #10. 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.

Lad være med at #10. Brug ikke ukendte vilkår – Brug ikke ukendte udtryk som "brugervenlig, alsidig og robust", da det kan skabe vanskeligheder, når du forsøger at definere testcases. Disse ord har ofte forskellige betydninger for forskellige mennesker.

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

Kravspecifikation er en kritisk proces i softwareudvikling, men det kan være udfordrende at skrive gode krav. De 20 tips, vi har givet, skulle hjælpe dig med at skrive bedre krav, hvilket gør processen nemmere for alle involverede. Hvis du ønsker at tage dine kravskrivning til næste niveau, kan du overveje at bruge et værktøj som Visure Requirements ALM Platform. Anmod om en Gratis 30-dages prøve i dag og se, hvordan vores platform kan hjælpe dig med at strømline dine kravindsamlings- og styringsprocesser.

Glem ikke at dele dette opslag!

Top

Implementering af AI Best Practices for at optimere flyelektronikkravene

September 12th, 2024

11:5 EST | 8 CEST | XNUMX PST

Fernando Valera

Fernando Valera

CTO, Visure Solutions

Reza Madjidi

Reza Madjidi

CEO, ConsuNova Inc.

En integreret tilgang med Visure Solutions og ConsuNova Inc.

Lær, hvordan AI hjælper med at optimere flyelektronikkravene til sikker start og landing