Kravsteknik

Kravsteknik

Indholdsfortegnelse

For at producere et kvalitetsprodukt er det vigtigt at have præcise krav fra kunden. Dette begynder med kravkonstruktionsprocessen, som kan opdeles i fem trin: indsamling af krav, dokumentation af krav, analyse og verificering af krav, håndtering af ændringer af krav og lukning af kravfasen. I dette blogindlæg vil vi diskutere hvert af disse trin i detaljer og vise, hvordan de hjælper med at producere et produkt af høj kvalitet.

Hvad er krav- og kravteknik?

Der er to udtryk her, "Krav" og "Kravteknik". Et krav er præcist defineret som en betingelse eller en evne, som en bruger har brug for for at løse et problem eller nå et mål. Krav er med andre ord betingelser eller kapaciteter, der skal opfyldes eller besiddes af et system for at opfylde en kontrakt, standarder, specifikationer og anden formel dokumentation. 

Krav Engineering er defineret som processen med at definere, dokumentere og vedligeholde kravene. Disciplinen omfatter alle teknikker, metoder og procedurer relateret til definition og styring af brugernes behov relateret til det system, der undersøges. 

Alt i alt er Requirements Engineering et sæt aktiviteter, der er beskæftiget med at identificere og kommunikere formålet med et system eller software og den kontekst, hvori det vil blive brugt. 

Derfor fungerer Requirements Engineering som en bro mellem de virkelige behov hos brugere, kunder og andre kredse, der er påvirket af software eller system, og de muligheder og muligheder, som softwareintensive teknologier giver.

Hvad er principperne for Requirements Engineering?

De to grundlæggende principper for Requirements Engineering er problemet og løsningen af ​​kravteknik. 

  • Det er nyttigt at adskille problemet og løsningen, når kravene skal samles.
  • Denne adskillelse kan aldrig opnås fuldt ud i det praktiske liv.

Requirement engineering handler om at bygge det rigtige system. Grundlæggende handler det om at bygge et system, der passer til brugerens problemer. Dette er en problemorienteret del. Det handler grundlæggende om at designe, verificere, implementere og vedligeholde det system, der er skabt for at sikre, at det passer til brugerens problemer. Dette er den løsningsorienterede del.

Krav Engineering Process

Der er nogle få aktiviteter, vi står over for, når vi arbejder med kravene. I Requirements Engineering-cyklussen er der fem hovedaktiviteter, nemlig

  1. Krav Elicitation – dette er processen med at gennemgå, dokumentere og forstå interessenterne og brugernes behov og begrænsninger for sæsonen. Brugere har brug for domæneoplysninger, eksisterende systemoplysninger, regulativer, standarder osv. Baseret på disse oplysninger fremkalder vi kravene. Herefter går vi over til kravanalyse og forhandling. 
  2. Kravanalyse og forhandling – analyse er processen med at forfine brugernes behov og begrænsninger på grundlag af indsamlet og fremkaldt information. Derefter går vi til dokumentationsaktiviteten. 
  3. Krav Dokumentation/Specifikation – efter at have fået kravspecifikationerne går vi videre til dokumentationsdelen. Vi dokumenterer brugernes behov og begrænsninger klart og præcist. 
  4. Validering af krav – til sidst, i valideringsaktiviteten, indsætter vi, at sæsonkravene er fuldstændige, kortfattede og klare. 
  5. Kravstyring – Kravstyring er en måde at indsamle, analysere, forfine og prioritere alle produkter eller krav i udviklingsfasen.

Når vi afslutter disse fem aktiviteter, gentager vi dem igen og igen, indtil vi får et sæt aftalte kravdokumenter, der er formelle specifikationer.

Krav Elicitation

Som vi diskuterede før, er kravfremkaldelse processen med at gennemgå, dokumentere og forstå brugernes behov og begrænsninger for sæsonen. Brugere har brug for domæneoplysninger, eksisterende systemoplysninger, regulativer, standarder osv. Baseret på disse oplysninger fremkalder vi kravene. Vi bruger ordet 'Elicitation' i stedet for 'Gathing', fordi indsamling fortolkes som blot at samle kravene op og indsætte dem i et dokument. På den anden side er elicitation en mere kompleks proces. Du får ikke kravene så let, som du får, mens du samler. Det kræver en ekstra indsats. 

Under elicitation spørger du brugeren eller kunden:

  • Hvad er deres mål for systemet/produktet? 
  • Hvad skal der opnås?
  • Hvordan passer sæsonens behov ind i virksomhedens behov?
  • Hvordan skal sæsonproduktet/-systemet bruges regelmæssigt?

Det lyder simpelt, men det er det slet ikke!

Ifølge Ian Sommerville og Pete Sawyer er Requirements Elicitation processen med at opdage kravene til et system ved at kommunikere med kunder, systembrugere og andre, der har en andel i systemudviklingen. Da 'samle' eller 'fange' ikke lyder særlig præcist, bruger vi ordet 'fremkaldelse'. 

"Jeg ved, at du tror, ​​at du forstod, hvad du tror, ​​jeg sagde, men jeg er ikke sikker på, at du indser, at det, du hørte, ikke er det, jeg mente" - Robert McCloskey, talsmand for udenrigsministeriet.

Hvad han mente med sit citat er nogle gange, at folk misforstår, hvad andre siger til dem. Nogle gange er det, de siger, ikke det, de har i tankerne. Til sidst førte hele denne fejlkommunikation til fejlindsamlingen af ​​krav.

Hvad er trinene under elicitation?

TRIN 1 

Kilde til krav:

Der er forskellige kilder, hvorfra vi kan samle vores krav. Nogle af dem omfatter:

  • Interessenter
  • Eksisterende systemer
  • Eksisterende dokumenter
  • Konkurrenter og andre lignende systemer
  • Interfaces med systemerne
  • Love og standarder
  • Virksomhedspolitikker

TRIN 2

Indstil projektets omfang:

Følgende trin kan følges for at opsætte omfanget af projektet:

  1. Find ud af, hvorfor projektet er igangsat 
  2. Ejendom definerer de vigtigste mål, der skal nås gennem projektet 
  3. Udarbejd en arbejdsopgørelse for projektet, som vil hjælpe dig med at opdele arbejdet korrekt blandt teammedlemmerne
  4. Liste op de varer, der skal leveres i slutningen af ​​projektet
  5. Vælg de vigtigste milepæle, der skal nås
  6. Identificer de store begrænsninger og begrænsninger, som teamet muligvis kan stå over for under udviklingen af ​​projektet
  7.  Opret en liste over elementer, der er udelukket fra listen over omfangselementer
  8. Få interessenterne til at underskrive scope-dokumentet, da det giver en bekræftelse på, at de er informeret om projektet og dets indhold. 

TRIN 3

Udviklingsopgaver:

Planlægningsfremkaldelse:

  • Hvorfor skal dette særlige krav implementeres og de fordele, det vil give? – Projektets mål 
  • Hvem vil være ansvarlig for at skabe den? – Fagfolk til elicitationsindsats
  • Hvornår er det bedste tidspunkt at implementere det? – Planlæg et estimat kilder 
  • Hvordan vil det blive implementeret? – Strategier og procedurer
  • Og risiciene 

Under elicitation:

  • Bekræft projektets levedygtighed. Find ud af, om projektet virkelig er det værd eller ej
  • Forstå problemerne og problemstillingerne fra en interessents perspektiv
  • Uddrag essensen af ​​kravene angivet af interessenterne
  • Find ud af bedre måder at gøre arbejdet for brugerne på
  • Innovation er nøglen til sejr

Følgende fremkaldelse:

  • Analyser resultaterne for korrekt at forstå den indsamlede information
  • Forhandle et sammenhængende sæt krav, der er acceptable for interessenterne. Fastlæg også prioriteterne
  • Registrer resultaterne i specifikationerne for kravene

Fremkaldelse er en trinvis proces. Du skal gentage dette trin så meget som nødvendigt. 

Vælg nu et passende sæt af teknikker for hver kilde til krav. Bestem denne teknik baseret på kilden, det system, der skal udvikles, og så videre. Husk, at ikke alle teknikker kan bruges i enhver situation. 

TRIN 4

Dokumentation af kravene – 

Det sidste trin i elicitationsprocessen er at færdiggøre alle kravene i form af et dokument. Dette dokument indeholder hovedsageligt bemærkningerne og brugerkravene. Og disse krav vil være ufuldstændige, inkonsekvente og uorganiserede. Men dette er kun udgangspunktet. Dokumentet kan redigeres i ny og næ, og ting kan tilføjes eller ændres.

Kravanalyse og forhandling

Kravanalyse er typisk en procedure til at analysere, validere og tilpasse de krav, der er dokumenteret i fasen af ​​kravfremkaldelse. Kravanalyse er med andre ord en proces med at studere og forstå de krav, som interessenterne stiller. Kravanalyse kræver hyppig kommunikation med interessenterne og slutbrugerne for at definere forventningerne, løse konflikterne og endelig dokumentere de vigtigste krav. Løsningerne kan omfatte spørgsmål som:

  • Forskellige former for set-up for arbejdsgangen i virksomheden
  • Opsætning af nyt system, der skal bruges fra nu af mv. 

En ting, du skal huske på, er, at kravfremkaldelse og behovsanalyse arbejder sammen. De to fodrer hinanden. Når vi begynder at samle kravene, fremkalder vi dem og analyserer dem på samme tid.

Formål med kravanalyse

  1. Det første og fremmeste formål med kravanalyse er at forstå brugernes krav og behov 
  2. Når vi bruger forskellige kilder til at samle kravene, kan der være nogle konflikter mellem dem. Kravanalyse handler om at finde disse konflikter blandt de krav, som brugerne stiller, og løse dem. 
  3. Forhandle kravene med brugerne og interessenterne. Der er ingen måde, vores system kan opfylde alle kravene på den nøjagtige måde, de er forklaret af interessenter og brugere. 
  4. Vi bliver nødt til at forhandle og prioritere kravene. Nogle krav er måske ikke store for os, men de kan være ret vigtige for slutbrugerne. For at forstå dem er vi nødt til at analysere og prioritere interessenternes krav. 
  5. Vi skal uddybe de krav, som brugerne og systemet stiller. Dette hjælper samtidig med at kravene i kravspecifikationerne dokumenteres. Dette hjælper også udviklerne med at udvikle, designe og teste bedre, da de forstår kravene på en uddybet og bedre måde. 
  6. Vi skal klassificere kravene i forskellige kategorier og underkategorier og yderligere allokere disse krav til forskellige undersystemer. 
  7. Vi skal også evaluere kravene til den kvalitet, som organisationen ønsker. 
  8. Endelig skal vi sørge for ikke at gå glip af noget vigtigt.

Krav Dokumentation/Specifikation

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. 

Metode til at dokumentere krav

ØRE ville være en effektiv metode her. Det står for Nem tilgang til kravsyntaks. I denne metode skriver vi et klart, kortfattet og forståeligt sprog. Dette forbedrer hele den tekniske arbejdsgang og forenkler arbejdet ved at gøre tingene ret nemme at forstå. 

For at opnå dette er her nogle principper, som du skal huske på, mens du skriver kravene. De involverer:

Hvert krav skal være i form af en hel sætning. Der må ikke bruges punkttegn, akronymer, forkortelser eller buzzwords. Prøv at lave korte, direkte og komplette sætninger. 

Sørg for, at hvert krav har et korrekt emne, prædikat og verbum. Emnet ville være brugertypen eller det system, vi taler om. Prædikatet ville være de betingelser eller handlinger eller ønskede resultater, vi forventer. Vi skal bruge ord som 'skal', 'vil' og 'skal' for at udtrykke en form for nødvendighed, og ord som 'må' til at udtrykke valgfrihed i kravet. 

Hvert krav skal effektivt forklare det slutresultat, vi ønsker fra systemet. 

Kravet skal også beskrive den kvalitet, vi forventer af systemet. Det hjælper, når vi måler slutresultatet og ser, om kravet er korrekt implementeret eller ej.

Validering af krav

Validering er en proces, der bruges til at kontrollere, om systemet er op til mærket eller ej. Validering besvarer spørgsmålet: "Bygger vi det rigtige system?" Det handler om at teste og validere systemet og se om det system vi har bygget er rigtigt eller ej, og om det lever op til kundens forventninger eller ej. Forskellige metoder, der bruges til at validere systemet, inkluderer black-box-test, white-box-test, integrationstest og enhedstest. Validering kommer altid efter verifikation. 

Verifikation er en proces, der bruges til at kontrollere, om systemet når sine forventede mål eller ej uden fejl eller problemer. Bekræftelse besvarer spørgsmålet "Bygger vi produktet rigtigt?" Det handler om at teste og verificere om systemet lever op til kravene uden problemer. Forskellige metoder, der bruges til at verificere systemet, omfatter anmeldelser, gennemgange, inspektioner og skrivebordskontrol. Verifikation er en manuel proces, der udføres før validering.

Valideringsteknikker

Der er forskellige teknikker, der kan bruges til at validere kravene. De omfatter:

  • Kontrol – Mens vi tjekker kravene, korrekturlæser vi kravdokumenterne for at sikre, at ingen udløsningsnotater går glip af. Under disse kontroller kontrollerer vi også sporbarhedsniveauet mellem alle kravene. Til dette kræves oprettelsen af ​​en sporbarhedsmatrix. Denne matrix sikrer, at alle krav bliver overvejet seriøst, og at alt, hvad der er specificeret, er berettiget. Vi kontrollerer også kravenes format under disse kontroller. Vi ser om kravene er klare og velskrevne eller ej. 
  • Prototyping – Dette er en måde at bygge en model eller simulering af det system, der skal bygges af udviklerne. Dette er en meget populær teknik til kravvalidering blandt interessenter og brugere, da den hjælper dem med nemt at identificere problemerne. Vi kan bare nå ud til brugerne og interessenterne og få deres feedback. 
  • Test design – Under testdesign følger vi en lille procedure, hvor vi først færdiggør testteamet og derefter bygger et par testscenarier. Funktionstest kan udledes af selve kravspecifikationen, hvor hvert krav har en tilhørende test. Tværtimod er de ikke-funktionelle krav svære at teste, da hver test skal spores tilbage til sit krav. Formålet med dette er at finde ud af fejlene i specifikationen eller de detaljer, der er gået glip af. 
  • Kravgennemgang – Under kravgennemgangen analyserer en gruppe kyndige personer kravene på en struktureret og detaljeret måde og identificerer de potentielle problemer. Derefter samles de for at diskutere problemerne og finde ud af en måde at løse problemerne på. Der udarbejdes en tjekliste, der består af forskellige standarder, og bedømmerne markerer afkrydsningsfelterne for at give en formel gennemgang. Derefter foretages en endelig godkendelsessign-off.

Kravstyring

Ifølge Ian Sommerville er "Kravstyring processen med at håndtere skiftende krav under kravkonstruktionsprocessen og systemudviklingen."

Hovedformålet med kravstyring er at sikre klare, kortfattede og fejlfrie krav til ingeniørteamet, så de kan sørge for at opdage fejl i systemet og potentielt reducere projektets omkostninger såvel som risiko. 

Hovedanliggender for kravstyring

Der er nogle bekymringer omkring kravstyring. De omfatter:

  • Håndtering af ændringer i de aftalte krav
  • Håndtering af forholdet mellem alle kravene
  • Håndtering af afhængighederne mellem de kravdokumenter, der produceres under systemudviklingsprocessen.

Typer af krav

Der er stort set to typer krav:

  1. Systemkrav – Systemkrav kan kaldes den udvidede version af brugerkravene. Systemkrav fungerer som udgangspunktet for ethvert nyt systemdesign. Disse krav er en detaljeret beskrivelse af de brugerkrav systemet skal opfylde. 
  2. Brugerkrav – Brugerkrav er en kombination af funktionelle og ikke-funktionelle krav. Disse brugerkrav skal udformes på en sådan måde, at de er let forståelige for brugere, der ikke har nogen form for teknisk viden. Derfor skal de skrives i naturligt sprog ved hjælp af simple tabeller, formularer og diagrammer. Sørg også for, at dokumentet ikke har detaljer om systemdesign, software eller formelle notationer.

Visure Krav ALM Platform

Visure Krav ALM Platform er en af ​​de mest betroede moderne ALM-platforme, der specialiserer sig i kravstyring for organisationer af alle størrelser over hele kloden. 

Det er et must-have-værktøj for teams, der bygger komplekse produkter, systemer og software, som kræver ende-til-ende-sporbarhed fra idé til test og implementering, hele vejen til kildekode, sammen med standardcertificeringsoverholdelse.

Visure Requirements er et bevist fleksibelt og komplet Requirements Engineering-værktøj, der er i stand til at strømline softwarekravsprocessen som en del af hardware- og mekaniske definitionsprocessen. Visure Requirements hjælper effektivt projektsamarbejde og øger softwarekvaliteten gennem Requirements-registrering, analyse, specifikation, validering og verifikation, styring og genbrug.

Visure Solutions kan hjælpe med at overvinde udfordringerne med produkt- og indlejret udvikling,

  • Forbedre definitionskvaliteten som et vigtigt første skridt i at øge softwarekvaliteten
  • Genvinde kontrol med udviklings- og reguleringsprocesser
  • Standardiser og håndhæv kravdefinitionen i hele organisationen
  • Støt effektiv genbrug af krav på tværs af projektteams og produktlinjer og varianter
  • Formaliser en fælles kravspecifikationsstruktur, og håndter ændringer gennem hele livscyklussen
  • opnå fuld sporbarhed gennem alle elementer, fra krav til test til udførelse
  • Spor let alle aspekter af udviklingen, lige fra grafik til risikoberegning til rapporter om forældreløse krav
  • Undgå faldgruber og dæmp risici på alle niveauer, fra at skrive bedre krav og prioritere behov til at ændre effektanalysekapaciteter.

Fordele ved at bruge visurkrav til produkt- og integreret udvikling

  • Certificeringsstøtte til industristandarder, såsom DO-178B/C, IEC 61508, ISO 26262, IEC 62304, FMEA og GAMP5
  • En komplet platform til alle kravrelaterede aktiviteter
  • Proceshåndhævelse gennem en fleksibel løsning, der understøtter forskellige procesmodeller, herunder Automotive SPICE, CMMI, V-model, Agile og ad hoc
  • Forbedret teamkommunikation og samarbejde gennem rollebaserede muligheder
  • Support til produkter af bedre kvalitet og reducerede softwarefejl.

Virksomheder, der aktivt bruger Visure, hævder en klar effekt med projektleverancer til tiden, projektoverholdelse og et fald i udviklingsomkostninger og cyklustider.

Konklusion

Requirements engineering er en kritisk proces for at sikre, at de produkter og systemer, vi bygger, er, hvad vores kunder har brug for. Den fem-trins proces, der er skitseret i denne artikel, kan hjælpe dig med at få dit projekt godt i gang ved at få feedback fra interessenter tidligt og ofte og bruge denne feedback til at generere klare og præcise krav. Hvis du leder efter et værktøj, der kan hjælpe dig med at administrere din kravkonstruktionsproces, kan Visure Requirements ALM Platform hjælpe. Anmod om din Gratis 30-dages prøve i dag for at se, hvordan vores platform kan gøre dit næste projekt til en succes.

Glem ikke at dele dette opslag!

Top