Det er stort sett to typer krav: Systemkrav – Systemkrav kan kalles utvidet versjon av brukerkravene. Systemkrav fungerer som startpunktet for enhver ny systemdesign. Disse kravene er en detaljert beskrivelse av brukerkravene systemet skal tilfredsstille. Brukerkrav – Brukerkrav er en kombinasjon av funksjonelle og ikke-funksjonelle krav. Disse brukerkravene må utformes på en slik måte at de er lett forståelige for brukere som ikke har noen form for teknisk kunnskap. Derfor må de skrives på naturlig språk ved hjelp av enkle tabeller, skjemaer og diagrammer. Sørg også for at dokumentet ikke har detaljer om systemdesign, programvare eller formelle notasjoner.

Den mest komplette veiledningen for kravhåndtering og sporbarhet

Kravsteknikk

For å produsere et kvalitetsprodukt er det viktig med nøyaktige krav fra kunden. Dette starter med kravprosjekteringsprosessen, som kan deles inn i fem trinn: innhente krav, dokumentere krav, analysere og verifisere krav, administrere endringer i krav og avslutte kravfasen. I dette blogginnlegget vil vi diskutere hvert av disse trinnene i detalj og vise hvordan de bidrar til å produsere et produkt av høy kvalitet.

Hva er krav- og kravteknikk?

Det er to begreper her, "Krav" og "Kravteknikk". Et krav er nøyaktig definert som en tilstand eller en evne som en bruker trenger for å løse et problem eller oppnå et mål. Krav er med andre ord forhold eller evner som må oppfylles eller innehas av et system for å tilfredsstille en kontrakt, standarder, spesifikasjoner og annen formell dokumentasjon.

Krav Engineering er definert som prosessen med å definere, dokumentere og vedlikeholde kravene. Disiplinen omfatter alle teknikkene, metodene og prosedyrene knyttet til definisjon og styring av brukernes behov knyttet til systemet som studeres.

Alt i alt er Requirements Engineering et sett med aktiviteter som er opptatt av å identifisere og kommunisere hensikten med et system eller programvare og konteksten det skal brukes i.

Derfor fungerer Requirements Engineering som en bro mellom de virkelige behovene til brukerne, kundene og andre valgkretser som er påvirket av programvare eller system og mulighetene og mulighetene som tilbys av programvareintensive teknologier.

Hva er prinsippene for Requirements Engineering?

De to grunnleggende prinsippene for Requirements Engineering er problemet og løsningen av kravteknikken.

Det er nyttig å skille problemet og løsningen når kravene skal samles.
Denne separasjonen kan aldri oppnås fullt ut i det praktiske livet.

Kravteknikk handler om å bygge det riktige systemet. I bunn og grunn handler det om å bygge et system som passer brukerens problemer. Dette er en problemorientert del. Det handler i bunn og grunn om å designe, verifisere, implementere og vedlikeholde systemet som er laget for å sikre at det passer brukerens problemer. Dette er den løsningsorienterte delen.

Krav Engineering Process

Det er noen få aktiviteter vi møter når vi jobber med kravene. I Requirements Engineering-syklusen er det fem hovedaktiviteter, nemlig,

Krav Elicitation – dette er prosessen med å gjennomgå, dokumentere og forstå interessentene og brukernes behov og begrensninger for sesongen. Brukere trenger domeneinformasjon, eksisterende systeminformasjon, forskrifter, standarder osv. Basert på denne informasjonen fremkaller vi kravene. Etter dette går vi over til kravanalyse og forhandling.
Kravanalyse og forhandling – analyse er prosessen med å avgrense brukernes behov og begrensninger på grunnlag av innsamlet og fremkalt informasjon. Deretter går vi til dokumentasjonsaktiviteten.
Krav Dokumentasjon/Spesifikasjon – etter å ha fått kravspesifikasjonene går vi til dokumentasjonsdelen. Vi dokumenterer brukernes behov og begrensninger klart og presist.
Validering av krav – til slutt, i valideringsaktiviteten, legger vi inn at sesongkravene er fullstendige, konsise og klare.
Kravshåndtering – Kravstyring er en måte å samle, analysere, foredle og prioritere alle produktene eller kravene på i utviklingsfasen.

Når vi sluttfører disse fem aktivitetene, gjentar vi dem gang på gang til vi får et sett med avtalte kravdokumenter som er formelle spesifikasjoner.

Krav Elicitation

Som vi har diskutert før, er kravfremkalling prosessen med å gjennomgå, dokumentere og forstå brukerbehovene og begrensningene for sesongen. Brukere trenger domeneinformasjon, eksisterende systeminformasjon, forskrifter, standarder osv. Basert på denne informasjonen fremkaller vi kravene. Vi bruker ordet "Elicitation" i stedet for "Gathering" fordi innsamling tolkes som bare å plukke opp kravene og sette dem inn i et dokument. På den annen side er elicitation en mer kompleks prosess. Du får ikke kravene like lett som du får mens du samler. Det krever ekstra innsats.

Under fremkallingen spør du brukeren eller kunden:

Hva er deres mål for systemet/produktet?
Hva skal oppnås?
Hvordan passer de sesongmessige behovene inn i virksomhetens behov?
Hvordan skal sesongproduktet/systemet brukes regelmessig?

Det høres enkelt ut, men det er det ikke!

I følge Ian Sommerville og Pete Sawyer er Requirements Elicitation prosessen med å oppdage kravene til et system ved å kommunisere med kunder, systembrukere og andre som har en andel i systemutviklingen. Siden "samle" eller "fange" ikke høres veldig nøyaktig ut, bruker vi ordet "fremkalling".

"Jeg vet at du tror at du forsto det du tror jeg sa, men jeg er ikke sikker på at du innser at det du hørte ikke er det jeg mente" - Robert McCloskey, talsmann for utenriksdepartementet.

Det han mente med sitatet er at noen ganger misforstår folk hva andre sier til dem. Noen ganger er det de sier ikke det de har i tankene. Til slutt førte hele denne feilkommunikasjonen til feil ved kravinnsamlingen.

Hva er trinnene under fremkalling?

TRINN 1

Kilde til krav:

Det finnes ulike kilder som vi kan samle kravene våre fra. Noen av dem inkluderer:

Interessenter
Eksisterende systemer
Eksisterende dokumenter
Konkurrenter og andre lignende systemer
Grensesnitt med systemene
Lover og standarder
Selskapets retningslinjer

TRINN 2

Angi prosjektets omfang:

Følgende trinn kan følges for å sette opp omfanget av prosjektet:

Finn ut hvorfor prosjektet er igangsatt
Eiendom definerer de viktigste målene som skal oppnås gjennom prosjektet
Tegn en arbeidsoppgave for prosjektet som vil hjelpe deg å fordele arbeidet på riktig måte blant teammedlemmene
List opp varene som skal leveres på slutten av prosjektet
Velg de viktigste milepælene som skal oppnås
Identifiser de store begrensningene teamet kan møte under utviklingen av prosjektet
Opprett en liste over elementer som er ekskludert fra listen over omfangselementer
Få interessentene til å signere omfangsdokumentet da det gir en bekreftelse på at de er informert om prosjektet og dets innhold.

TRINN 3

Fremkallingsoppgaver:

Planleggingsfremkalling:

Hvorfor bør dette spesielle kravet implementeres og fordelene det vil gi? – Mål for prosjektet
Hvem vil være ansvarlig for å lage den? – Fagfolk for fremkallingsarbeid
Når vil det være best å implementere det? – Planlegg et estimat kilder
Hvordan vil det bli implementert? – Strategier og prosedyrer
Og risikoene

Under fremkalling:

Bekreft prosjektets levedyktighet. Finn ut om prosjektet virkelig er verdt det eller ikke
Forstå problemene og problemene fra en interessents perspektiv
Trekk ut essensen av kravene oppgitt av interessentene
Finn ut bedre måter å gjøre jobben på for brukerne
Innovasjon er nøkkelen til seier

Følgende fremkalling:

Analyser resultatene for å forstå den innsamlede informasjonen på riktig måte
Forhandle et sammenhengende sett med krav som er akseptable for interessentene. Fastslå prioriteringene også
Registrer resultatene i spesifikasjonene til kravene

Fremkalling er en inkrementell prosess. Du må gjenta dette trinnet så mye som nødvendig.

Velg nå et passende sett med teknikker for hver kilde til krav. Bestem denne teknikken basert på kilden, systemet som skal utvikles, og så videre. Husk at ikke alle teknikkene kan brukes i alle situasjoner.

TRINN 4

Dokumentasjon av kravene –

Det siste trinnet i utløsningsprosessen er å fullføre alle kravene i form av et dokument. Dette dokumentet inneholder hovedsakelig merknadene og brukerkravene. Og disse kravene kommer til å være ufullstendige, inkonsekvente og uorganiserte. Men dette er bare utgangspunktet. Dokumentet kan redigeres nå og da, og ting kan legges til eller endres.

Kravanalyse og forhandling

Kravanalyse er vanligvis en prosedyre for å analysere, validere og tilpasse kravene som er dokumentert i fasen av kravfremkalling. Kravanalyse er med andre ord en prosess for å studere og forstå kravene som stilles av interessentene. Kravanalyse krever hyppig kommunikasjon med interessenter og sluttbrukere for å definere forventningene, løse konfliktene og til slutt dokumentere nøkkelkravene. Løsningene kan innebære problemer som:

Ulike typer oppsett for arbeidsflyten i bedriften
Sette opp nytt system som skal brukes fra nå av osv.

En ting å huske på er at kravfremkalling og kravanalyse fungerer sammen. De to mater hverandre. Når vi begynner å samle kravene, fremkaller vi dem og analyserer dem samtidig.

Mål for behovsanalyse

Det første og fremste målet med kravanalyse er å forstå kravene og behovene til brukerne
Når vi bruker ulike kilder for å samle kravene, kan det være noen konflikter mellom dem. Kravanalyse handler om å finne disse konfliktene blant kravene som stilles av brukerne og løse dem.
Forhandle kravene med brukere og interessenter. Det er ingen måte systemet vårt kan oppfylle alle kravene på den nøyaktige måten de er forklart av interessenter og brukere.
Vi blir nødt til å forhandle og prioritere kravene. Noen krav er kanskje ikke store for oss, men de kan være ganske viktige for sluttbrukerne. For å forstå dem må vi analysere og prioritere kravene til interessentene.
Vi må utdype kravene som stilles av brukere og system. Dette hjelper samtidig med å dokumentere kravene i kravspesifikasjonene. Dette hjelper også utviklerne med å utvikle, designe og teste bedre ettersom de forstår kravene på en forseggjort og bedre måte.
Vi må klassifisere kravene i forskjellige kategorier og underkategorier og videre tildele disse kravene til forskjellige undersystemer.
Vi må også vurdere kravene til kvaliteten som ønskes av organisasjonen.
Til slutt må vi sørge for ikke å gå glipp av noe viktig.

Krav Dokumentasjon/Spesifikasjon

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.

Metode for å dokumentere krav

Ører ville vært en effektiv metodikk her. Det står for Enkel tilnærming til kravsyntaks. I denne metoden skriver vi et klart, konsist og forståelig språk. Dette forbedrer hele den tekniske arbeidsflyten for krav og forenkler arbeidet ved å gjøre ting ganske enkelt å forstå.

For å oppnå dette er det noen prinsipper som må huskes når du skriver kravene. De involverer:

Hvert krav må være i form av en fullstendig setning. Ingen punkttegn, akronymer, forkortelser eller buzzwords skal brukes. Prøv å lage korte, direkte og fullstendige setninger.

Sørg for at hvert krav har et riktig subjekt, predikat og verb. Emnet vil være brukertypen eller systemet vi snakker om. Predikatet vil være betingelsene eller handlingene eller ønskede resultater vi forventer. Vi må bruke ord som 'skal', 'vil' og 'må' for å uttrykke en slags nødvendighet, og ord som 'kan' for å uttrykke valgfrihet i kravet.

Hvert krav må effektivt forklare sluttresultatet vi ønsker fra systemet.

Kravet skal også beskrive kvaliteten vi forventer av systemet. Det hjelper når vi måler sluttresultatet og ser om kravet er riktig implementert eller ikke.

Validering av krav

Validering er en prosess som brukes for å sjekke om systemet er opp til merket eller ikke. Validering svarer på spørsmålet "Bygger vi det riktige systemet?" Det handler om å teste og validere systemet og se om systemet vi har bygget er riktig eller ikke og om det oppfyller kundens forventninger eller ikke. Ulike metoder som brukes for å validere systemet inkluderer black-box-testing, white-box-testing, integrasjonstesting og enhetstesting. Validering kommer alltid etter verifisering.

Verifikasjon er en prosess som brukes for å sjekke om systemet oppnår sine forventede mål eller ikke uten noen feil eller problemer. Bekreftelse svarer på spørsmålet "Bygger vi produktet riktig?" Det handler om å teste og verifisere om systemet oppfyller kravene uten problemer. Ulike metoder som brukes for å verifisere systemet inkluderer anmeldelser, gjennomganger, inspeksjoner og skrivebordskontroller. Verifisering er en manuell prosess som gjøres før validering.

Valideringsteknikker

Det finnes ulike teknikker som kan brukes for å validere kravene. De inkluderer:

Sjekker – Mens vi sjekker kravene, korrekturleser vi kravdokumentene for å sikre at ingen utløsningsnotater går glipp av. Under disse kontrollene sjekker vi også sporbarhetsnivået mellom alle kravene. For dette kreves det å lage en sporbarhetsmatrise. Denne matrisen sikrer at alle kravene blir vurdert seriøst og at alt som er spesifisert er begrunnet. Vi sjekker også formatet på kravene under disse kontrollene. Vi ser om kravene er klare og velskrevne eller ikke.
Prototyping – Dette er en måte å bygge en modell eller simulering av systemet som skal bygges av utviklerne. Dette er en veldig populær teknikk for kravvalidering blant interessenter og brukere, da den hjelper dem å enkelt identifisere problemene. Vi kan bare nå ut til brukerne og interessentene og få deres tilbakemeldinger.
Testdesign – Under testdesign følger vi en liten prosedyre der vi først avslutter testteamet, og deretter bygger noen testscenarier. Funksjonstester kan utledes fra selve kravspesifikasjonen der hvert krav har en tilhørende test. Tvert imot er de ikke-funksjonelle kravene vanskelige å teste ettersom hver test må spores tilbake til sitt krav. Målet med dette er å finne ut feilene i spesifikasjonen eller detaljene som går glipp av.
Kravgjennomgang – Under kravgjennomgang analyserer en gruppe kunnskapsrike personer kravene på en strukturert og detaljert måte og identifiserer potensielle problemer. Etter det samles de for å diskutere problemene og finne ut en måte å løse problemene på. Det utarbeides en sjekkliste som består av ulike standarder og anmelderne krysser av i boksene for å gi en formell gjennomgang. Deretter utføres en endelig godkjenningssignering.

Kravshåndtering

I følge Ian Sommerville, "Kravstyring er prosessen med å håndtere endrede krav under kravutviklingsprosessen og systemutvikling."

Hovedformålet med kravstyring er å sikre klare, konsise og feilfrie krav til ingeniørteamet slik at de kan sørge for å oppdage feil i systemet og potensielt redusere prosjektkostnaden og risikoen.

Hovedanliggender for kravstyring

Det er noen bekymringer om kravhåndtering. De inkluderer:

Håndtere endringene i de avtalte kravene
Håndtere forholdet mellom alle kravene
Håndtere avhengighetene mellom kravdokumentene som produseres under systemutviklingsprosessen.

Typer krav

Det er stort sett to typer krav:

Systemkrav – Systemkrav kan kalles utvidet versjon av brukerkravene. Systemkrav fungerer som startpunktet for enhver ny systemdesign. Disse kravene er en detaljert beskrivelse av brukerkravene systemet skal tilfredsstille.
Brukerkrav – Brukerkrav er en kombinasjon av funksjonelle og ikke-funksjonelle krav. Disse brukerkravene må utformes på en slik måte at de er lett forståelige for brukere som ikke har noen form for teknisk kunnskap. Derfor må de skrives på naturlig språk ved hjelp av enkle tabeller, skjemaer og diagrammer. Sørg også for at dokumentet ikke har detaljer om systemdesign, programvare eller formelle notasjoner.

Visurekrav ALM-plattform

Visurekrav ALM-plattform er en av de mest pålitelige moderne ALM-plattformene som spesialiserer seg på kravstyring for organisasjoner av alle størrelser over hele verden.

Det er et må-ha-verktøy for team som bygger komplekse produkter, systemer og programvare, som krever ende-til-ende sporbarhet fra unnfangelse til testing og distribusjon, hele veien til kildekoden, sammen med standard sertifiseringsoverholdelse.

Visure Requirements er et bevist fleksibelt og komplett Requirements Engineering-verktøy, i stand til å strømlinjeforme prosessen med programvarekrav som en del av maskinvare- og mekaniske definisjonsprosessen. Visure Requirements hjelper effektivt prosjektsamarbeid og øker programvarekvaliteten gjennom Requirements-registrering, analyse, spesifikasjon, validering og verifisering, administrasjon og gjenbruk.

Visure Solutions kan bidra til å overvinne utfordringene med produkt- og innebygd utvikling,

Forbedre definisjonskvaliteten som et viktig første skritt i å øke programvarekvaliteten
Få kontroll over utviklings- og reguleringsprosesser på nytt
Standardiser og håndhev kravdefinisjonen i hele organisasjonen
Støtt effektiv gjenbruk av krav på tvers av prosjektgrupper og produktlinjer og varianter
Formaliser en felles kravspesifikasjonsstruktur, og håndter endringer gjennom hele livssyklusen
Oppnå full sporbarhet gjennom alle elementer, fra krav til testing til utførelse
Spor alle aspekter av utviklingen enkelt, fra grafikk for risikberegning til rapporter om foreldreløse krav
Unngå fallgruver og reduser risiko på alle nivåer, fra å skrive bedre krav og prioritering av behov til å endre effektanalysefunksjoner.

Fordeler med å bruke Visure Requirements for produkt- og innebygd utvikling

Sertifiseringsstøtte for industristandarder, slik som DO-178B/C, IEC 61508, ISO 26262, IEC 62304, FMEA og GAMP5
En komplett plattform for alle behovsrelaterte aktiviteter
Prosesshåndhevelse gjennom en fleksibel løsning som støtter ulike prosessmodeller, inkludert Automotive SPICE, CMMI, V-model, Agile og ad hoc
Forbedret teamkommunikasjon og samarbeid gjennom rollebaserte evner
Støtte for produkter av bedre kvalitet, og reduserte programvarefeil.

Selskaper som aktivt bruker Visure, hevder en klar innvirkning med tidsriktige prosjektleveranser, prosjektoverholdelse og reduksjon i utviklingskostnader og syklustider.

konklusjonen

Kravutvikling er en kritisk prosess for å sikre at produktene og systemene vi bygger er det kundene våre trenger. Den fem-trinns prosessen som er skissert i denne artikkelen kan hjelpe deg med å få prosjektet ditt til en god start ved å få tilbakemelding fra interessenter tidlig og ofte og bruke denne tilbakemeldingen til å generere klare og konsise krav. Hvis du leter etter et verktøy for å hjelpe deg med å administrere ingeniørprosessen for krav, kan Visure Requirements ALM Platform hjelpe. Be om din Gratis 30-dagers prøveversjon i dag for å se hvordan plattformen vår kan gjøre ditt neste prosjekt til en suksess.

Ikke glem å dele dette innlegget!