Den mest komplette veiledningen for kravhåndtering og sporbarhet

Hvordan implementere et kravstyringsverktøy

Hvordan implementere et kravstyringsverktøy?

For å implementere et kravstyringsverktøy er det flere trinn du kan ta.

Først må du identifisere interessentene og brukerne av verktøyet. Dette inkluderer prosjektledere, forretningsanalytikere, utviklere, testere og andre personer som skal bruke det. Du må også bestemme hvilken type kravstyringssystem som er best for organisasjonen din basert på størrelsen, kompleksiteten til prosjekter og andre faktorer.

Deretter bør du bestemme hvilket programvareverktøy eller plattform du vil bruke for kravsbehandlingsprosessen. Det er mange forskjellige typer tilgjengelig på markedet i dag, for eksempel Visure. Når du har bestemt deg for hvilken som er best for organisasjonens behov, er det på tide å sette opp systemet. Dette kan inkludere å opprette brukerkontoer, sette opp tilgangsnivåer for forskjellige brukere og konfigurere innstillinger for å sikre riktig funksjonalitet til programvaren.

Når kravstyringsverktøyet ditt er satt opp riktig, er det på tide å begynne å bruke det! Du bør definere maler for innsamling og organisering av krav fra interessenter. I tillegg bør du opprette en prosess og et regelsett som sikrer at hvert krav er korrekt dokumentert, slik at de spores deretter gjennom hele livssyklusen. Til slutt bør du etablere en gjennomgangsprosess slik at alle endringer eller oppdateringer av et krav blir ordentlig gjennomgått før de implementeres.

Hvorfor trenger du et kravstyringsverktøy?

Det er ingen hemmelighet at dårlige krav fører til produkter av dårlig kvalitet, og at disse prosjektene ofte er fylt med omfangskryp. Utfordringene med en dokumentbasert tilnærming til krav er mange, blant annet at det er vanskelig å holde dem oppdatert i den stadig skiftende programvareutviklingen. Selv om du har gjort en strålende jobb med å samle og dokumentere brukerkrav, har oppgaven med å håndtere kravene så vidt begynt.

Her er noen hovedgrunner til å bruke et automatisert verktøy for kravhåndtering i følge Karl Wiegers (www.processimpact.com artikkel om automatisering av kravhåndtering).

Administrer versjoner og endringer. De fleste systemer utgis på en iterativ (eller smidig) måte i dag. Dette betyr at krav vil ha versjoner knyttet til utgivelsen. Å kunne spore endringer og identifisere virkningen av endringer i å kontrollere endring og omfangskryp.

Lagre tilleggsinformasjon om kravet i kravattributter. Det er så mye mer vi trenger å vite om et krav annet enn kravets uttalelse. For eksempel status for kravene, prioritet, hvem som ba om det og teststatus. Dette er bare noen få forslag.

Koble krav til andre systemelementer. For å sikre at alle krav er en del av produktet, alle krav testes, endringer evalueres osv. må vi kunne koble krav til andre systemelementer.

Spor status. Tenk å kunne lage en liste over alle krav som ikke er godkjent, alle krav som ikke er knyttet til krav på lavere nivå, og alle krav som ikke er testet. Dette er den typen informasjon som hjelper oss å virkelig vite statusen til prosjektet.

Se undergrupper av krav. Tenk på å kunne se alle høyprioriterte krav som ikke har tildelt en testmetode. Eller et sikkerhetskontor som ønsker å gjennomgå kun de sikkerhetsrelaterte kravene. Å kunne filtrere krav til kun å inkludere informasjon brukeren er interessert i å se, reduserer tiden som kreves for å gjennomgå disse kravene.

Kontroller tilgang. Du vil være sikker på at forretningsanalytikere bare kan endre brukerkrav; systemanalytikere kan bare endre systemkrav og så videre. Når den er godkjent, må tilgangen til kravene begrenses, slik at ingen ytterligere endringer kan gjøres uten gjennomgang.

Kommuniser med interessenter. Varsling om endringer er avgjørende for å sikre at interessenter er klar over alle potensielle endringer. De fleste kravstyringsverktøy kan hjelpe til med automatisk å gi denne typen varsling.

For de av oss som har brukt kravstyringsverktøy, er det vanskelig å tenke seg å gå tilbake til å gjøre det arbeidet på papiret. Og jeg tror det er få av oss som vil velge å gå tilbake til den metoden. Jeg personlig ville tatt ethvert kravstyringsverktøy fremfor en dokumentbasert tilnærming. Imidlertid er det utrolig for meg at mange organisasjoner av alle størrelser fortsetter å stole på dokumentbaserte verktøy for å håndtere kravene sine. Å bruke et kravstyringsverktøy er et nødvendig første skritt for å få kontroll over kravene.

Før du kjøper et kravstyringsverktøy...

Det er ingen hemmelighet at profesjonelle kravtekniske løsninger bidrar til å forbedre effektiviteten når du arbeider med krav. De bidrar også til å minimere antallet feil som typisk vil føre til kostbare korreksjoner når de blir funnet i senere faser av utviklingslivssyklusen.

Derfor er mange selskaper på utkikk etter slike kravtekniske løsninger, men dessverre gjelder samme regel som for nesten alle andre typer programvareverktøy også for kravtekniske løsninger: en tosk med et verktøy forblir en tosk...

De beste kravenes ingeniørløsningene som Visure Requirement ALM-plattformen er svært fleksible ved å kunne støtte nesten alle typer krav ingeniørprosesser. Selvfølgelig er vi – som verktøyleverandør – glade for å selge deg noe programvare, men vi er overbevist om at dette alene ikke vil hjelpe deg. I stedet ønsker vi å hjelpe deg med å lykkes med å bruke produktene våre.

Så før du kjøper en kravteknisk løsning, må du forsikre deg om at du har definert en skikkelig kravteknikkprosess med visse aktiviteter tildelt bestemte roller. Vi kan selvfølgelig også dele våre erfaringer med deg på dette området. Hvis du kjenner de detaljerte egenskapene til prosessen din, er det mye lettere for deg å finne en passende løsning som passer behovene til prosessen din.

6 tips for vellykket implementering av et kravstyringsverktøy

For mange år siden brukte jeg flere år på å jobbe med et veldig komplekst våpenkontrollsystem. Som du kan forestille deg var kravene store, komplekse og endret seg ofte. Vi brukte mye tid på å bare prøve å administrere de irriterende endringene som fortsatte å bli sendt inn, både fra kunder og fra utviklerne. I de tidlige dagene hadde vi ingen kravstyringsverktøy for å hjelpe oss med å vurdere disse endringene. Vi brukte Interleaf og Excel (jeg kan høre stønn av smerte nå). Alt var manuelt, inkludert vår komplekse sporbarhet. Vi hadde et par folk som ikke gjorde annet enn å opprettholde sporbarhetsmatrisene og vurdere effekten av endringer. På dette tidspunktet hadde vi kun sporbarhet fra driftskonseptet til systemkrav til delsystemkrav. Jeg sier "bare", men på den tiden var det en stor prestasjon å bare ha dette nivået av sporbarhet.

Da vi hadde nok endringer utstedte vi et nytt systemkravdokument og nytt delsystemkravdokument. De stakkars entreprenørene måtte gå gjennom de enorme delsystemkravene og manuelt finne ut hva som hadde endret seg. Jeg kan ikke forestille meg tiden entreprenørene brukte bare på å finne ut hvilke endringer de måtte være bekymret for.

Det var midt i dette oppgraderingsprosjektet at kunden sa nok og ga teamet mitt i oppgave å evaluere og velge et kravstyringsverktøy. Verktøyet vi valgte er ikke viktig for akkurat denne diskusjonen, men det vi lærte av dette verktøyvalget og implementeringen er viktig. Her er noen erfaringer.

(1) - Det er ikke et eneste verktøy som vil glede alle. Vi hadde brukere som elsket utvalget vårt og de som kjempet mot oss hele veien. Uten en kunde som støtter og håndhever endringen, ville det ikke vært mulig på et stort program som dette. En bruker klaget på kolonnestørrelsen til den verktøygenererte sporbarhetsmatrisen, og ignorerte fullstendig det faktum at det sparte ham dager med manuell innsats.

(2) - Vår manuelle sporbarhet var ikke veldig ren. Når vi importerte all informasjonen vår til verktøyet og koblet den sammen, fant vi mange hull i sporbarheten. Det som var mer urovekkende var at vi hadde koblinger som egentlig ikke ga noen mening. Vi måtte gjøre mye arbeid for å rydde opp i sporbarhetsmatrisene våre.

(3) - Bare sporingskrav var flott, men nå kunne vi bruke samme innsats for å koble krav til testplaner og gikk så langt som å koble delsystemkrav til designdokumenter som vi kunne gjennomgå. Dette skjedde ikke over natten, men det skjedde. Etter hvert kunne vi spore systemkrav fra et delsystemkrav til et designdokument til en kodemodul. Vi brukte til og med et verktøy for å bestemme kompleksiteten til kodemoduler og brukte dette for å finne ut hvor vanskelig en endring ville være å implementere og teste.

(4) - Beregninger fra et kravverktøy er nøkkelen til å forstå fullstendigheten av testaktiviteter. Vi trodde ofte at vi var 50 % ferdige med testing. Tross alt ble 50 % av testene gjennomført. Det vi imidlertid fant ut var at vi var tilbøyelige til å teste de enkleste og mest forståtte delene av systemet først. Så selv om vi var 50 % fullførte, var alt som var igjen svært høy risiko. Vi lærte å prioritere testingen vår ved å se på kravprioriteringer og programvarekompleksitet, informasjonen vi ikke kunne bestemme gjennom manuell sporbarhet.

(5) – Det var veldig lett å bli overveldet. Start enkelt. Vi måtte gå tilbake til våre ambisiøse ideer og begynne med en enkel sporbarhetsmodell. Etter hvert som vi lærte og fikk mer erfaring med verktøyet, la vi til mer informasjon i modellen vår. Vi vurderte hele tiden prosessen vår for å finne ut hva annet vi kunne gjøre for å gjøre det bedre.

(6) - Ikke spar på trening og veiledning. Vi trente alle på prosjektet og skapte eksperter som hjalp brukerne med å komme over de første hindringene. Vi sendte ekspertene våre til våre entreprenører i flere uker av gangen for å hjelpe dem med å komme i gang med å bruke verktøyet. Vi hadde til og med vår egen interne brukergruppe. Vær forberedt på denne typen innsats.

For en flott læringsopplevelse dette var for meg. Hvis du er interessert i å ta fatt på en endring som dette for å forbedre kravprosessen din, ta kontakt med Visure Solutions. Vi vil gjerne diskutere prosessen din med deg.

Ikke glem å dele dette innlegget!