features functional requirements
Denne opplæringen forklarer typene, funksjonene, sammenligningen av funksjonelle vs ikke-funksjonelle krav og forretning vs funksjonelle krav med eksempler:
Funksjonelle krav definerer hva et programvaresystem skal gjøre. Den definerer en funksjon av et programvaresystem eller dets modul. Funksjonalitet måles som et sett med innganger til systemet som testes til utgangen fra systemet.
Funksjonskravsimplementering i et system er planlagt i systemdesignfasen, mens det i tilfelle ikke-funksjonelle krav er planlagt i dokumentet Systemarkitektur. Funksjonskravet støtter generering av ikke-funksjonelle krav.
Hva du vil lære:
Funksjonelle krav og ikke-funksjonelle krav
Funksjonelle krav
La oss forstå hva som er funksjonelle krav ved hjelp av eksempler-
Eksempel: I et ADAS-prosjekt for biler kan et funksjonelt krav til surround-view-system være 'Bakre kamera skal oppdage en trussel eller gjenstand'. Ikke-funksjonelle krav her kan være 'hvor raskt varselet til en bruker skal vises når en trussel oppdages av kamerasensorer'.
Ta en til eksempel av infotainment systems-prosjektet. Brukeren aktiverer Bluetooth her fra HMI og sjekker om Bluetooth er aktivert eller ikke. Merk , blir andre Bluetooth-tjenester aktivert (fra grå til fet skrift) når brukeren aktiverer Bluetooth.
hva er den beste youtube til mp3
Så funksjonelle krav snakker om et bestemt systemutfall når brukeren utfører en oppgave på dem. På den annen side gir det ikke-funksjonelle kravet den generelle oppførselen til systemet eller dets komponent og ikke om funksjon.
Typer funksjonelle krav
Funksjonelle krav kan omfatte følgende komponenter som kan måles som en del av funksjonstesting:
# 1) Interoperabilitet: Krav beskriver om et programvaresystem er kompatibelt på tvers av forskjellige systemer.
Eksempel: For Bluetooth-funksjonelle krav i bilinfotainmentsystemet, når brukeren kobler en Bluetooth-aktivert Android-basert smarttelefon til QNX-basert infotainment-system, bør vi kunne overføre telefonboken til infotainment-systemet eller streame musikk fra vår telefon til infotainment-systemet.
Så interoperabilitet sjekker om kommunikasjon mellom de to forskjellige enhetene er mulig eller ikke.
En annen eksempel er fra e-posttjenestesystemene som Gmail. Gmail tillater import av e-post fra en annen e-postutvekslingsserver som Yahoo.com eller Rediffmail.com. Dette er mulig på grunn av interoperabilitet mellom e-postservere.
# 2) Sikkerhet: Det funksjonelle kravet beskriver sikkerhetsaspektet ved programvarekrav.
Eksempel: Cybersikkerhetsbaserte tjenester i ADAS surround-view-kamerabasert system som bruker Controller Area Network (CAN) som beskytter systemet mot sikkerhetstrusselen.
En annen eksempel er fra det sosiale nettverkssiden Facebook . En brukers data skal være sikre og må ikke lekke til en utenforstående. Vi håper dette eksempelet på Facebook gir leserne større sikkerhet for leserne på grunn av nylig forekomst av datainnbrudd på Facebook og konsekvensene som Facebook står overfor.
# 3) Nøyaktighet: Nøyaktighet definerer at data som er lagt inn i systemet blir beregnet riktig og brukt av systemet, og at utdataene er riktige.
Eksempel: I Controller Area Network, når en CAN-signalverdi overføres over CAN-bussen av en ECU (nemlig ABS-enhet, HVAC-enhet, instrumentklyngeenhet osv.), Vil en annen ECU kunne identifisere om de sendte dataene er riktige eller ikke via CRC-sjekk.
En annen eksempel kan være fra en nettbankløsning. Når brukeren mottar et fond, skal mottatte beløp krediteres nøyaktig på kontoen, og ingen variasjon i nøyaktighet aksepteres.
# 4) Overholdelse: Overensstemmelsesfunksjonelle krav validerer at det utviklede systemet er i samsvar med industrielle standarder.
Eksempel: Enten Bluetooth-profilfunksjoner (nemlig lydstrømming via A2DP, telefonsamtale via HFP) er kompatible med Bluetooth SIG-utgivelsesprofilversjoner.
En annen eksempel kan være Apple Car-spill i bilinfotainment-systemet. Appen i infotainment får et sertifikat fra eple hvis alle forutsetningene som er nevnt på Apples nettsted, er oppfylt av tredjeparts Car Play-enheter (infotainment i dette tilfellet).
En annen eksempel kan være fra et nettbasert program for jernbanebillettsystemet. Nettstedet bør følge retningslinjene for cybersikkerhet og overholde World Wide Web når det gjelder tilgjengelighet.
Eksempel på kravskjema:
Vi har allerede sett hva funksjonskrav er med noen eksempler. La oss nå se hvordan et funksjonelt krav vil se ut når det er integrert i verktøy for styringsbehov som IBM DOORS. Det er flere attributter som skal tas i betraktning mens du dokumenterer et funksjonskrav i Kravstyringsverktøyet.
Nedenfor er noen attributter som skal tas i betraktning:
- Objekt type: Dette attributtet forklarer hvilken del av kravdokumentet som er en del av dette attributtet. De kan være overskrift, forklaring, krav osv. For det meste vurderes 'Krav' -seksjonen for implementering og testing, mens overskrifts- og forklaringsseksjoner brukes som støttende beskrivelser for krav til bedre forståelse.
- Ansvarlig person: En forfatter som har dokumentert kravet i kravstyringsverktøy.
- Prosjekt / systemnavn: Prosjektet som kravet gjelder for, for eksempel, “Infotainment Systems for XYZ OEM (Original Equipment Manufacturer) et bilfirma eller webapplikasjon for ABC banks aksjeselskap”.
- Krav versjonsnummer: Dette feltet / attributtet varsler versjonsnummeret på kravet hvis kravet har gjennomgått flere endringer på grunn av kundeoppdateringer eller endringer i systemdesign.
- Krav-ID: Denne attributtet nevner det unike krav-ID-en. Krav-ID brukes til å spore kravene i databasen enkelt og også til å kartlegge kravene effektivt i koden. Den kan også brukes til å gi en referanse til kravene mens du logger feil i feilsporingsverktøy.
- Kravbeskrivelse: Denne attributtet er en av de viktigste attributtene som forklarer kravet. Ved å lese dette attributtet, vil en ingeniør kunne forstå kravet.
- Kravstatus: Kravstatusattributt sier om status for et krav i kravstyringsverktøyet, dvs. om det er akseptert, på vent, avvist eller slettet prosjektet.
- Kommentarer: Dette attributtet gir den ansvarlige personen eller kravansvarlig et alternativ til å dokumentere eventuelle kommentarer om kravet. Eksempel: en mulig kommentar til et funksjonelt krav kan være 'avhengighet av en tredjeparts programvarepakke for å implementere kravet'.
Et øyeblikksbilde fra DOORS
Utlede funksjonelle krav fra forretningskrav
Dette er allerede dekket som en del av seksjonen “ Utlede funksjonelle krav fra forretningskrav ' under Kravsanalyse artikkel.
Forretningskrav mot funksjonelle krav
Denne forskjellen er løst dekket i Kravsanalyse artikkel. Vi vil imidlertid prøve å fremhev noen flere punkter her i tabellen nedenfor:
| Sl. Nei. | Forretningskrav | Funksjonelle krav |
|---|---|---|
| 7 | For eksempel, i nettbanksystemet kan et forretningskrav være 'Som bruker skal jeg kunne få kontoutskrift'. | Funksjonelle krav i dette nettbanksystemet kan være: 'Når brukeren oppgir datoperioden i transaksjonsforespørselen, brukes denne inngangen av Server, og websiden er utstyrt med de nødvendige kontanttransaksdataene'. |
| en | Forretningskrav sier 'hva' aspekt av kundekrav. Eksempel, Hva skal være synlig for brukeren etter at brukeren logger på. | Funksjonelle krav sier 'hvordan' aspekt av forretningskrav. Eksempel, Hvordan websiden skal vise brukerinnloggingsside når brukeren autentiserer. |
| to | Forretningskrav identifiseres av forretningsanalytikere. | Funksjonelle krav er laget / avledet av utviklere / programvarearkitekt |
| 3 | De legger vekt på fordelen for organisasjonen og er relatert til forretningsmål. | Målet deres er oppfyllelse av kundekrav. |
| 4 | Forretningskrav er fra kunden. | Funksjonelle krav er avledet fra programvarekrav, som igjen er avledet av forretningskrav. |
| 5 | Forretningskrav testes ikke direkte av Software Test Engineers. De blir testet av kunden stort sett. | Funksjonelle krav blir testet av programvaretestingeniører og vanligvis ikke testet av kunder. |
| 6 | Forretningskravet er et krav på høyt nivå. | Et funksjonskrav er et detaljert teknisk kravdokument. |
Ikke-funksjonelt krav
Det ikke-funksjonelle kravet sier om 'hva et system skal være' i stedet for 'hva et system skal gjøre' (funksjonskrav). De kommer hovedsakelig fra funksjonelle krav basert på innspill fra kunden og andre interessenter. Ikke-funksjonelle krav til implementering av krav er dokumentert i dokumentet Systemarkitektur.
Ikke-funksjonelle krav forklarer kvalitetsaspektene av systemet som skal konstrueres, dvs. ytelse, bærbarhet, brukervennlighet osv. Ikke-funksjonelle krav, i motsetning til funksjonelle krav, implementeres trinnvis i ethvert system.
URPS (Brukervennlighet, pålitelighet, ytelse og støtte) fra FURPS (Funksjonalitet, brukervennlighet, pålitelighet, ytelse og supportability) kvalitetsattributter som er mye brukt i IT-bransjen for å måle kvaliteten på en programvareutvikler, er alle dekket av ikke-funksjonelle krav. Dessuten er det også andre kvalitetsattributter (detaljer i neste avsnitt).
Wikipedia kaller det ikke-funksjonelle kravet noen ganger 'ilities' på grunn av tilstedeværelsen av forskjellige kvalitetsattributter som bærbarhet og stabilitet.
Typer av ikke-funksjonelle krav
Ikke-funksjonelle krav består av nedenstående undertyper (ikke uttømmende):
# 1) Ytelse:
En ytelsesattributt type ikke-funksjonelt krav måler systemytelsen. Eksempel: I ADAS-surroundvisningssystemet skal 'kameraet bak vises innen 2 sekunder etter at biltenningen startet'.
En annen eksempel av ytelse kan være fra infotainment systems Navigasjonssystem. “Når en bruker går til navigasjonsskjermbildet og går inn i destinasjonen, skal ruten beregnes innen“ X ”sekunder. En til eksempel fra påloggingssiden for webapplikasjonen. 'Tiden det tar før brukerprofilsiden lastes inn etter pålogging.'
Husk at måling av systemytelse er forskjellig fra lastmåling. Under belastningstesting laster vi inn CPU og RAM og kontrollerer systemgjennomstrømningen. Ved ytelse tester vi systemgjennomstrømning under normale belastnings- / påkjenningsforhold.
# 2) Brukervennlighet :
Brukervennlighet måler brukervennligheten til programvaresystemet som utvikles.
For eksempel , er det utviklet en mobil webapplikasjon som gir deg informasjon om rørleggere og elektrikerens tilgjengelighet i ditt område.
Inndataene til denne appen er postnummer og radius (i kilometer) fra din nåværende posisjon. Men for å angi disse dataene, hvis brukeren må bla gjennom flere skjermer og datainntastingsalternativet vises i små tekstbokser som ikke er lett synlige for en bruker, så er denne appen ikke brukervennlig, og derfor vil appens brukervennlighet være veldig lav.
# 3) Vedlikehold :
Vedlikehold av et programvaresystem er hvor enkelt systemet kan vedlikeholdes. Hvis gjennomsnittstiden mellom feil (MTBF) er lav eller gjennomsnittlig reparasjonstid (MTTR) er høy for systemet som utvikles, anses systemets vedlikeholdbarhet som lav.
Vedlikehold blir ofte målt på kodenivå ved bruk av syklomatisk kompleksitet. Syklomatisk kompleksitet sier at jo mindre kompleks koden er, jo lettere er det å vedlikeholde programvaren.
Eksempel: Et programvaresystem er utviklet som har det høye antallet døde koder (koder som ikke brukes av andre funksjoner eller moduler), svært komplisert på grunn av overdreven bruk av hvis / annet tilstand, nestede sløyfer, etc. eller hvis systemet er enormt med koder som kjører i mange millioner linjer med koder og ingen ordentlige kommentarer. Et slikt system har lite vedlikeholdsevne.
En annen eksempel kan være av nettside for shopping. Hvis det er mange eksterne lenker på nettstedet slik at brukeren kan ha oversikt over produktet (dette for å spare på minnet), er vedlikeholdsevnen til dette nettstedet lav. Dette skyldes at hvis ekstern nettsidekobling endres, må den også oppdateres på netthandelnettstedet og det for ofte.
# 4) Pålitelighet :
Pålitelighet er et annet aspekt av tilgjengeligheten. Denne kvalitetsattributtet understreker tilgjengeligheten av et system under visse forhold. Det måles som MTBF akkurat som vedlikeholdsevne.
Eksempel: Gjensidig utelukkende funksjoner som ryggekamera og Trailer i ADAS surround-kamerasystem skal fungere pålitelig i systemet uten forstyrrelser med hverandre. Når en bruker henter Trailer-funksjonen, skal ikke baksiden forstyrre og omvendt, da begge funksjonene får tilgang til bakre kamera på bilen.
En annen eksempel fra det online forsikringsskadesystemet. Når en bruker starter kravrapportering og deretter laster opp relevante utgiftsregninger, bør systemet gi nok tid til opplasting til å fullføres, og bør ikke avbryte opplastingsprosessen raskt.
# 5) Bærbarhet:
Portabilitet betyr et programvaresystems evne til å jobbe i et annet miljø hvis det underliggende avhengige rammeverket forblir det samme.
Eksempel: Programvaresystem / komponent i et infotainment-system utviklet (nemlig Bluetooth-tjeneste eller multimedietjeneste) for en bilbilsprodusent, bør tillate bruk i et annet infotainment-system med liten eller ingen endring i kode, selv om de to infotainment-systemene er helt forskjellige .
programvareutvikling livssyklus designfase
La oss ta en til eksempel fra WhatsApp. Det er mulig å installere og bruke meldingstjenesten på IOS, Android, Windows, Tablet, Laptop og Phone.
# 6) Støtte
Servicevennlighet til et programvaresystem er evnen til en tjeneste / teknisk ekspert til å installere programvaresystemet i sanntidsmiljø, overvåke systemet mens det kjører, identifisere eventuelle tekniske problemer i systemet og gi en løsning for å løse problemet.
Servicevennlighet er mulig hvis systemet er utviklet for å lette servicen.
Eksempel: Tilby periodisk påminnelse popup til brukeren for en programvareoppdatering, som gir logging / sporingsmekanisme for feilsøkingsproblemer, automatisk gjenoppretting fra feil via tilbakeføringsmekanisme (rull programvaresystemet tilbake til tidligere arbeidstilstand).
En annen eksempel fra Rediffmail. Når det var en oppdatering i versjonen av den nettbaserte posttjenesten, tillot systemet brukeren å bytte til en nyere versjon av postsystemet og holde den eldre intakt i noen måneder. Dette forbedrer også brukeropplevelsen.
# 7) Tilpasningsevne:
Tilpasningsevnen til et system er definert som et programvaresystems evne til å tilpasse seg endringer i et miljø uten noen endring i dets atferd.
Eksempel: Låsbart bremsesystem i bilen skal fungere som standard under alle værforhold (varmt eller kaldt). En annen eksempel kan være et Android-operativsystem. Den brukes i forskjellige typer enheter, nemlig. Smarttelefoner, nettbrett og infotainment-systemer og er svært tilpasningsdyktige.
I tillegg til de 7 ikke-funksjonelle kravene som er oppført ovenfor, har vi mange andre som:
Tilgjengelighet, sikkerhetskopi, kapasitet, samsvar, dataintegritet, datalagring, avhengighet, distribusjon, dokumentasjon, holdbarhet, effektivitet, utnyttbarhet, utvidbarhet, feilhåndtering, feiltoleranse, interoperabilitet, modifiserbarhet, brukbarhet, personvern, lesbarhet, rapportering, motstandsdyktighet, gjenbrukbarhet, Robusthet, skalerbarhet, stabilitet, testbarhet, gjennomstrømning, gjennomsiktighet, integrerbarhet.
Å dekke alle disse ikke-funksjonelle kravene er utenfor omfanget av denne artikkelen. Du kan imidlertid lese mer om disse ikke-funksjonelle kravtypene i Wikipedia.
Utlede ikke-funksjonelle krav fra funksjonelle krav
Ikke-funksjonelle krav kan avledes på mange måter, men den beste og mest bransjene velprøvde måten er fra funksjonelle krav.
La oss ta eksemplet fra infotainmentsystemene som vi allerede har tatt noen få steder i denne artikkelen. Brukeren kan utføre mange handlinger på Infotainment-systemet, nemlig endre sangen, endre sangkilden fra USB til FM eller Bluetooth-lyd, angi navigasjonsdestinasjon, oppdatere infotainment-programvare via en programvareoppdatering, etc.
# 1) Samling av ikke-funksjonelle krav:
Vi vil liste oppgavene som utføres av en bruker, som er en del av funksjonelle krav. Når brukerhandlingene er notert i UML-saksdiagrammet (hver ovale), starter vi relevante spørsmål (hvert rektangel) om hver brukers handlinger. Svarene på disse spørsmålene vil gi våre ikke-funksjonelle krav.
# 2) Kategorisering av ikke-funksjonelle krav:
Det neste trinnet er kategoriseringen av ikke-funksjonelle krav som vi har identifisert via spørsmål. På dette stadiet kan vi sjekke det mulige svaret og kategorisere svarene til mulige ikke-funksjonelle kategorier eller forskjellige kvaliteter.
På bildet nedenfor kan du se mulige kvalitetsattributter identifisert fra svarene.
Funksjonelle kontra ikke-funksjonelle krav
Vi har allerede sett hva funksjonelle og ikke-funksjonelle krav er og hvordan de er avledet. La oss se på de store forskjellene mellom funksjonelle og ikke-funksjonelle krav.
| Sl. Nei | Funksjonelle krav (FR) | Ikke-funksjonelle krav (NFR) |
|---|---|---|
| 7 | Funksjonelle krav utgjør skjelettet for implementering av programvaresystem | Ikke-funksjonelle krav fullfører SW-systemet ved å hjelpe funksjonskravene til å holde sammen, som en muskel. |
| en | De sier hva et system skal gjøre. | De sier, hva et system skal være. |
| to | De er beskrevet i dokumentet System Design. | De er beskrevet i dokumentet Systemarkitektur. |
| 3 | De snakker om oppførselen til en funksjon eller funksjon. | De snakker om arbeidsoppførselen til et helt system eller en komponent av systemet og ikke en bestemt funksjon. |
| 4 | Brukeren vil sende inn og sjekke om utgangen vises riktig. | Når brukeren sender et inndata, kan følgende spørsmål besvares av NFRer: i) Hvor lang tid tar det å vise utdata? ii) Er produksjonen i samsvar med tiden? iii) Er det andre måter å overføre inndataparameteren på? iv) Hvor enkelt er det å overføre inndataparameteren? |
| 5 | I et webapplikasjon skal brukeren kunne logge på via autentisering er FR | Hvor lang tid det tar å logge inn på nettstedet, utseendet på innloggingssiden, brukervennligheten til en webside osv. Er en del av NFR i en webapplikasjon |
| 6 | Funksjonelle krav kommer først fra programvarekrav. | Ikke-funksjonelle krav er avledet fra funksjonelle krav. |
| 8 | Funksjonelle krav kan eksistere uten et ikke-funksjonelt krav. | Ikke-funksjonelle krav kan ikke eksistere uten funksjonelle krav. |
| 9 | Et funksjonskrav gir konkret informasjon om en funksjon, Eksempel , Profilbilde på Facebook skal være synlig ved pålogging. | Et funksjonskrav kan ha mange ikke-funksjonelle kravattributter. Eksempel, tid til å logge inn (ytelse), utseendet og følelsen til profilsiden (brukervennlighet), antall brukere som kan logge på om gangen (kapasitet, ytelse) |
| 10 | Å utlede funksjonelle krav fra SW-krav er mulig for nesten alle forretningskrav | NFR-er blir ofte savnet for å bli dokumentert, da relevante spørsmål ikke blir stilt om FR-er. |
| elleve | Implementering av et funksjonelt krav gjøres normalt i en programvarebygging. | NFR-er implementeres gjennom hele livssyklusen til prosjektet til ønsket oppførsel er oppnådd. |
| 12 | Disse er stort sett synlige for kunden. | Disse er stort sett ikke synlige for kunden, men kan oppleves på lang sikt. Eksempel, Brukervennlighet, ytelse osv. Kan bare oppleves på lang sikt, men kan ikke være synlig i det hele tatt. |
Konklusjon
Krav er grunnleggende byggestein for å utvikle et hvilket som helst programvaresystem. Det er mulig å bygge et system med funksjonelle krav, men dets evner kan ikke bestemmes eller måles. Når det er sagt, er det veldig viktig å ha funksjonelle krav av god kvalitet avledet av et forretningskrav for å ha et fungerende programvaresystem av høy kvalitet.
Derfor gir funksjonelle krav retningen for implementering av et programvaresystem, men ikke-funksjonelle krav bestemmer kvaliteten på implementeringen som sluttbrukerne vil oppleve.
Anbefalt lesing
- Hvordan teste programvarekravspesifikasjon (SRS)?
- Funksjonstesting mot ikke-funksjonell testing
- Hvordan teste en søknad uten krav?
- Hva er kravanalyse og samling i SDLC?
- 5 dødelige feil i kravhåndtering og hvordan du kan overvinne dem
- Funksjoner av funksjonelle krav og ikke-funksjonelle krav
- Hvordan lage krav Sporbarhetsmatrise (RTM): Eksempel og eksempelmal
- Topp 20+ beste verktøy for styringsverktøy (den komplette listen)