Den mest komplette veiledningen for kravhåndtering og sporbarhet

Gjør og ikke må for skrivekrav

Hvis du er som folk flest, liker du sannsynligvis ikke skrivekrav. Det er ikke det mest spennende i verden, men det er en kritisk del av produktutviklingen. Et bedre kravdokument kan spare organisasjonen din for en formue med tydelig kommunikasjon mellom utvikleren og produktinteressentene. Dette gjenspeiler igjen på tvers av organisasjonen, inkludert større åpenhet, mindre etterarbeid og forbedret produktivitet.

Mens hver organisasjon har forskjellige krav og metoder, forblir det grunnleggende for skrivekrav de samme. I denne artikkelen vil vi dele noen tips som kan hjelpe deg å forbedre dine skriveferdigheter og hjelpe deg med å skrive klare og klare kravspesifikasjoner.

Hva er kravspesifikasjon?

Kravspesifikasjon, også kjent som dokumentasjon, er en prosess med å notere ned alle system- og brukerkrav i form av et dokument. Disse kravene må være klare, fullstendige, omfattende og konsistente.

Under fangstaktiviteten samler vi alle kravene fra ulike kilder. Under analyse- og forhandlingsaktivitetene analyserer og forstår vi disse kravene. Nå må vi utarbeide et formelt dokument som forklarer disse kravene. Det er det som er kravspesifikasjonen. For å være presis er det prosessen med å dokumentere alle bruker- og systembehov og begrensninger på en klar og nøyaktig måte.

Hva betyr "beste praksis" i kravhåndtering?

Det er så interessant for meg at alle snakker om å ønske opplæring i «beste praksis». Dette begrepet brukes ofte for å beskrive hva slags rådgivning vi også kan tilby. Hva betyr det egentlig? Jeg tror alle av oss har matet inn i myten om at beste praksis kan være grunnlaget for opplæring av individer. Beste praksis er ikke opplært, de er erfarne.

Hvis vi sammenligner den beste praksis-tilnærmingen til naturen, vet vi at det ikke bare er den sterkeste, men den mest produktive arten som overlever. Det er en av grunnene til at det er så vanskelig å endre prosesser i en organisasjon. Tenk på det et øyeblikk. De sterkeste og mest produktive beskriver sannsynligvis flertallet av individene du har i omtrent hvilken som helst gruppe i organisasjonen din. Jeg har sett dette om og om igjen i System Engineering-feltet. De sterkeste og mest produktive ingeniørene har ofte gjort jobben sin i mange år og har en bestemt måte de gjør denne jobben på. Å be dem om å prøve nye teknikker og verktøy er ofte fåfengt, siden de ikke vet hvordan dette skal forbedre den allerede fantastiske jobben de gjør. Praksisen deres kommer til å overleve hvis vi fortsetter å skyve en beste praksis tilnærming til dem.

Utfordringer når du skriver krav

Det er ulike utfordringer folk møter når de skriver krav.

Dårlig papirarbeid – I noen organisasjoner er dokumentasjon av prosesser enten ikke-eksisterende eller ikke på nivå. I dette tilfellet blir innsamling av krav en to-trinns prosess: først reversere den eksisterende prosessen, og deretter identifisere områder som trenger forbedring og optimalisering. For å bekrefte at kravene er konkretiserte og nøyaktige, er det nøkkelen til å identifisere sentrale interessenter og fageksperter, og engasjere dem direkte. Å tegne forretningsprosesskart og visualisere arbeidsflyter er to utmerkede måter å gjøre det på. Dette hjelper til med å eliminere ukorrekte forutsetninger samtidig som det gir et fullstendig bilde. Å tegne prosesskart og vise prosesser er to nyttige tilnærminger for dette formålet.

Motstridende krav – Når interessenter har ulike prioriteringer for sine forretningsmål, fører dette til krav som kommer i konflikt med hverandre. I slike tilfeller er det en forretningsanalytikers ansvar å dokumentere alle krav i detalj, identifisere hvilke forespørsler som motsetter seg hverandre, og gi interessenter mulighet til å bestemme hva som prioriteres.

Du kan ikke ta beslutninger uten å høre interessentenes innspill, og som forretningsanalytiker har du kanskje noen ideer om hva som bør prioriteres. Det er fortsatt viktig å høre interessentenes perspektiv. Å sette opp en meningsmåling kan være en av metodene for å få klarhet i hva som betyr mest for flertallet av interessentene.

Utilgjengelighet for brukerinndata – Noen årsaker kan bidra til at sluttbrukere ikke er tilgjengelige, og hver av dem krever sin egen løsning. Noen ganger er for eksempel sluttbrukere så opptatt av det daglige arbeidet at de ikke er villige til å delta i kravinnsamlingsaktiviteter.

I slike tilfeller er det beste en forretningsanalytiker kan gjøre å begrense antall og lengde på engasjementer. Før møtet vil det å gjøre så mye research som mulig bidra til å gjøre diskusjonen mer organisert og informativ. Det er nesten som å gjøre kravsamling til kravvalideringsøkter. definere fokusgrupper og identifisere de best egnede sluttbrukerne for hver gruppe

Fokuser på grensesnitt i stedet for erfaring – Mange interessenter og sluttbrukere har en klar visjon om hvordan den nye løsningen skal fremstå, men de vet ikke hva den skal utrette. Ethvert systems brukergrensesnitt er avgjørende, men det bør ikke definere eller forstyrre funksjonaliteten.

Forretningsanalytikere bør alltid huske å holde design- og funksjonskrav atskilt i dokumentasjonen. Ved å bruke mer generelle verktøy som diagrammer, brukerhistorier eller low-fi-prototyper i stedet for designutkast, kan de opprettholde fokus på de funksjonelle aspektene ved kravinnsamling.

Innspill fra interessenter – Når interessenter eller sluttbrukere prøver å fortelle designere hvordan systemet skal fungere i stedet for hva systemet skal gjøre, kan det føre til suboptimale design. For å unngå dette, valider hvert potensielt "falske krav" ved å spørre "hvorfor?" til du kommer til det virkelige problemet som må løses.

Kommunikasjonsproblemer – Blant problemene som kan føre til feilkommunikasjon mellom en forretningsanalytiker og andre parter er språkbarrierer, feil antagelser, utilstrekkelig forklart ordforråd og overbruk av faguttrykk.

Den ideelle tilnærmingen for å unngå dette problemet er å samhandle ofte og utvikle toveissamtaler. Dokumenter behovene du har oppdaget og send dem inn for fagfellevurdering og kritikk til en rekke fagspesialister, lag en ordliste med sjargong og dobbeltsjekk lokalene.

10 bør og ikke gjøre når du skriver krav:

Gjør #1. En om gangen – Hvert krav bør behandles som en diskret testsak. Konjunksjoner som og, eller, og så videre bør ikke brukes fordi de kan føre til at man går glipp av krav. Dette er spesielt viktig siden termer som disse kan føre til at programvareutviklere og testere overser kravene. Å dele opp kompliserte behov i mindre deler til hver enkelt kan testes separat er en måte å forhindre at dette skjer.

Ikke #1. Snakk "hva" ikke "hvordan" – Fokuset bør være på hva systemet skal gjøre, ikke hvordan det gjør det. Unngå i tillegg å gå for dypt inn i designemner som feltnavn, programmeringsspråkobjekter og programvareobjekter. Hvis du finner deg selv i å diskutere disse emnene i kravspesifikasjonsdokumentet, ta et skritt tilbake – dette betyr sannsynligvis at du blir for spesifikk.

Gjør #2. Sporbarhet – Sporbarhet i prosjektledelse refererer til å sikre at krav er knyttet til andre komponenter i prosjektet. Dette lar prosjektledere, utviklere og interessenter holde styr på et kravs hele livssyklus fra begynnelse til slutt i alle retninger, så vel som med andre deler av systemet. Hvis du administrerer sporbarhet på riktig måte, kan du unngå kode som ikke samsvarer med noe krav ('stray'-kode), og sørge for at hver testcase dekker minst ett krav. Du kan gjøre krav sporbare ved å merke dem med en unik identifikator og gi informasjon om kilden deres i et sentralt arkiv tilgjengelig for alle teammedlemmer.

Ikke #2. Ingen unntak – Et krav skal ikke ha en rømningsklausul. For eksempel, "Systemet skal bestemme antall påloggingsforsøk, bortsett fra når brukeren tydelig har oppgitt feil brukernavn".

Gjør #3. Gjennomførbart – Sørg for at prosjektbudsjettet og tidslinjen er gjennomførbare, sammen med tilgjengelige ressurser. Hvis denne betingelsen kan støtte kravet, er det mulig å gå videre med planen.

Ikke #3. Si nei til "utslipp"-klausuler – Prøv å holde deg unna utslitte setninger som men, unntatt, og bare hvis det er nødvendig.

Gjør #4. Konsistens – Oppretthold et konsekvent detaljnivå. For eksempel, for brukerkrav, bør en sluttbruker være gjenstand for hver setning. På samme måte, for systemkrav, bør et system være gjenstand for hver setning.

Ikke #4. Ingen forkortelser – Hvert krav skal være en hel setning uten noen akronymer eller sjargong.

Gjør #5. Aktiv stemme – Skriv alltid med en aktiv stemme, og pass på at en av skuespillerne er gjenstand for hver setning.

Ikke #5. Ikke vær tvetydig – Ikke bruk tvetydige termer som f.eks ca osv., og flere slike termer i kravdokumentet. Sørg for å forklare kravene på en slik måte at alle involverte forstår dem riktig. Vage utsagn kan føre til feiltolkninger og kan forårsake konflikter mellom ulike interessenter.

Gjør #6. Emne og predikat – For hvert krav må det være et emne (bruker/system) og et predikat (tilsiktet resultat, handling eller tilstand).

Ikke #6. Spekulasjoner kan forårsake skade – Ikke gjett; ikke lag lister over funksjoner som er uaktuelle. Å si at du vil at et system skal håndtere alle uventede feil er ren fantasi siden ingen system noen gang vil være 100 prosent hva du ønsker det skal være. Unngå duplisering og motstridende utsagn.

Gjør #7. verifiserbar – En annen ting å huske på når man organiserer krav, er at de alltid skal være testbare. Dette betyr at det må være mulig å verifisere at systemet oppfyller det aktuelle kravet. Dette lenker også til vårt neste punkt – sporbarhet. Hvis et krav er fullt av vage termer, blir det vanskeligere å analysere og verifisere om systemet faktisk oppfyller disse standardene ytelsesmessig. Derfor, så mye som mulig, sikte på klarhet og presisjon i språket ditt, slik at kravsamlingen ikke er en tvetydig prosess.

Ikke #7. Unngå alternativer – Ikke kom med ideer eller alternativer. Du kan se disse i en hvilken som helst uttalelse som inkluderer setningene kan, kan, kunne eller burde.

Gjør #8. Riktig – Sørg for at hver setning er fullstendig og grammatisk korrekt med et riktig emne, verb og predikat.

Ikke #8. Ikke snakk i fremtidig tid – Ikke referer til et ennå ikke-definert krav. Målet ditt er å gjøre dokumentet så behagelig å lese som mulig.

Gjør #9. Fokus – Etabler fokus ved å eliminere støyende, for lange fraser og referanser til utdaterte artikler.

Ikke #9. Hva bør brukes og hvor? – "Skal" skal brukes der krav er oppgitt, "Vil" skal brukes for å representere fakta; & "Bør" for å representere et mål som skal nås.

Gjør #10. Organisert papirarbeid gjør underverker – Hold kravene organisert på ett sted for å forbedre lesbarheten til dokumentet ditt og unngå å kaste bort tid på å krysshenvise til flere kilder.

Ikke #10. Ikke bruk ukjente vilkår – Ikke bruk ukjente begreper som "brukervennlig, allsidig og robust", da det kan skape vanskeligheter når du prøver å definere testtilfeller. Disse ordene har ofte forskjellige betydninger for forskjellige mennesker.

Visurekrav ALM-plattform

Visure er en av de mest pålitelige applikasjonslivssyklusadministrasjonsplattformene som spesialiserer seg på kravstyring for organisasjoner av alle størrelser over hele verden. De viktigste partnerne til Visure inkluderer forretningskritiske og sikkerhetskritiske selskaper. Selskapet integrerer gjennom hele Application Lifecycle Management-prosessene, inkludert risikostyring, problem- og defektsporing, sporbarhetsstyring, endringsstyring og forskjellige andre områder som kvalitetsanalyse, kravversjon og kraftig rapportering.

Hvis du ser etter et kravstyringsverktøy som vil hjelpe deg med både funksjonelle og ikke-funksjonelle krav, sjekk ut Visure Requirements. Med denne plattformen kan du enkelt opprette, administrere og spore alle prosjektets krav på ett sted.

konklusjonen

Kravspesifikasjon er en kritisk prosess i programvareutvikling, men det kan være utfordrende å skrive gode krav. De 20 tipsene vi har gitt bør hjelpe deg med å skrive bedre krav, slik at prosessen blir smidigere for alle involverte. Hvis du ønsker å ta skrivekravene dine til neste nivå, bør du vurdere å bruke et verktøy som Visure Requirements ALM Platform. Be om a Gratis 30-dagers prøveversjon i dag og se hvordan plattformen vår kan hjelpe deg med å strømlinjeforme prosessene for innsamling og administrasjon av krav.

Ikke glem å dele dette innlegget!