features functional requirements
Denne vejledning forklarer typerne, funktionerne, sammenligningen af funktionelle vs ikke-funktionelle krav og forretning vs funktionelle krav med eksempler:
Funktionelle krav definerer, hvad et softwaresystem skal gøre. Det definerer en funktion af et softwaresystem eller dets modul. Funktionalitet måles som et sæt indgange til systemet, der testes, til output fra systemet.
Funktionskravsimplementering i et system er planlagt i systemdesignfasen, mens det i tilfælde af ikke-funktionelle krav er planlagt i dokumentet Systemarkitektur. Det funktionelle krav understøtter generering af de ikke-funktionelle krav.
Hvad du lærer:
Funktionelle krav og ikke-funktionelle krav
Funktionelle krav
Lad os forstå, hvad der er funktionelle krav ved hjælp af eksempler-
Eksempel: I et ADAS-projekt til bilindustrien kan et funktionelt krav til surround-view-systemet være 'Bagkamera skal opdage en trussel eller genstand'. Ikke-funktionelle krav her kunne være 'hvor hurtigt alarmen til en bruger skal vises, når en trussel opdages af kamerasensorer'.
Tag en anden eksempel af Infotainment-systemprojektet. Brugeren aktiverer Bluetooth her fra HMI og kontrollerer, om Bluetooth er aktiveret eller ej. Bemærk , bliver andre Bluetooth-tjenester aktiveret (fra grå til fed), når brugeren aktiverer Bluetooth.
ls kommando i unix med eksempler
Så funktionelle krav taler om et bestemt systemresultat, når en opgave udføres af dem af brugeren. På den anden side giver det ikke-funktionelle krav systemets eller dets komponents samlede opførsel og ikke funktion.
Typer af funktionelle krav
Funktionelle krav kan omfatte følgende komponenter, der kan måles som en del af funktionstestning:
# 1) Interoperabilitet: Krav beskriver, om et softwaresystem er interoperabelt på tværs af forskellige systemer.
Eksempel: For Bluetooth-funktionelle krav i bilinfotainmentsystemet, når brugeren parrer en Bluetooth-aktiveret Android-baseret smartphone til QNX-baseret infotainment-system, skal vi være i stand til at overføre telefonbogen til infotainment-systemet eller streame musik fra vores telefon til infotainment-systemet.
Så interoperabilitet kontrollerer, om kommunikation mellem de to forskellige enheder er mulig eller ej.
En anden eksempel er fra e-mail-servicesystemerne som Gmail. Gmail tillader import af e-mails fra en anden mail-udvekslingsserver som Yahoo.com eller Rediffmail.com. Dette er muligt på grund af interoperabilitet mellem e-mail-servere.
# 2) Sikkerhed: Det funktionelle krav beskriver sikkerhedsaspektet ved softwarekrav.
Eksempel: Cybersikkerhedsbaserede tjenester i ADAS surround-view-kamerabaseret system, der bruger Controller Area Network (CAN), der beskytter systemet mod sikkerhedstruslen.
En anden eksempel er fra det sociale netværkssite Facebook . En brugers data skal være sikre og må ikke lækkes til en udenforstående. Vi håber, at dette eksempel på Facebook giver en bredere forståelse af sikkerhed for læsere på grund af for nylig forekomst af databrud på Facebook og de konsekvenser, som Facebook står over for.
# 3) Nøjagtighed: Nøjagtighed definerer, at data indtastet i systemet beregnes korrekt og bruges af systemet, og at output er korrekt.
Eksempel: Når et CAN-signalværdi transmitteres via CAN-bussen af en ECU (dvs. ABS-enhed, HVAC-enhed, instrumentklyngeenhed osv.) I Controller Area Network, vil en anden ECU være i stand til at identificere, om de sendte data er korrekte eller ikke via CRC-kontrol.
En anden eksempel kan være fra en onlinebankløsning. Når brugeren modtager en fond, skal det modtagne beløb krediteres nøjagtigt på kontoen, og ingen variation i nøjagtigheden accepteres.
# 4) Overholdelse: Overensstemmelsesfunktionelle krav bekræfter, at det udviklede system er i overensstemmelse med industrielle standarder.
Eksempel: Uanset om Bluetooth-profilfunktioner (nemlig lydstreaming via A2DP, telefonopkald via HFP) er i overensstemmelse med Bluetooth SIG-frigivelsesprofilversioner.
En anden eksempel kan være, at Apple Car spiller i bilinfotainment-systemet. Appen i infotainment får et certifikat fra Æble hvis alle de forudsætninger, der er nævnt på Apples websted, er opfyldt af tredjeparts Car Play-enheder (infotainment i dette tilfælde).
En anden eksempel kan være fra en webbaseret applikation til jernbanebilletsystemet. Webstedet skal følge cybersikkerhedsretningslinjerne og overholde World Wide Web med hensyn til tilgængelighed.
Eksempel på kravformular:
Vi har allerede set, hvad funktionskrav er med nogle eksempler. Lad os nu se, hvordan et funktionelt krav ville se ud, når det blev integreret i kravstyringsværktøjer som IBM DOORS. Der er flere attributter, der skal tages i betragtning, når der dokumenteres et funktionelt krav i værktøjet Kravstyring.
Nedenfor er et par attributter, der skal tages i betragtning:
- Objekt type: Denne attribut forklarer, hvilket afsnit i kravdokumentet der er en del af denne attribut. De kan være overskrift, forklaring, krav osv. For det meste tages afsnittet 'Krav' i betragtning til implementering og test, mens overskrifts- og forklaringsafsnit bruges som understøttende beskrivelser for krav til bedre forståelse.
- Ansvarlige person: En forfatter, der har dokumenteret kravet i kravstyringsværktøj.
- Projekt / systemnavn: Det projekt, som kravet gælder for, for eksempel, “Infotainment Systems for XYZ OEM (Original Equipment Manufacturer) et bilfirma eller webapplikation for ABC-bankselskab”.
- Kravsversion nummer: Dette felt / attribut underretter kravets versionsnummer, hvis kravet har gennemgået flere ændringer på grund af kundeopdateringer eller ændringer i systemdesign.
- Krav-id: Denne attribut nævner det unikke krav-id. Krav-id bruges til let at spore kravene i databasen og også til effektivt at kortlægge kravene i kode. Det kan også bruges til at give en henvisning til kravene, mens du logger fejl i fejlsporingsværktøjer.
- Kravbeskrivelse: Denne attribut er en af de vigtigste attributter, der forklarer kravet. Ved at læse denne attribut ville en ingeniør være i stand til at forstå kravet.
- Kravsstatus: Kravstatusattribut siger om status for et krav i kravstyringsværktøjet, dvs. om det er accepteret, ventet, afvist eller slettet projektet.
- Kommentarer: Denne attribut giver den ansvarlige person eller kravadministrator mulighed for at dokumentere enhver kommentar om kravet. Eksempel: en mulig kommentar til et funktionelt krav kunne være 'afhængighed af en tredjeparts softwarepakke for at implementere kravet'.
Et øjebliksbillede fra DOORS
Udledning af funktionelle krav fra forretningskrav
Dette er allerede dækket som en del af afsnittet “ Afledning af funktionelle krav fra forretningskrav ' under Kravsanalyse artikel.
Forretningskrav Vs funktionelle krav
Denne forskel er løst dækket af Kravsanalyse artikel. Det vil vi dog prøve fremhæv et par flere punkter her i nedenstående tabel:
| Sl. Ingen. | Forretningskrav | Funktionelle krav |
|---|---|---|
| 7 | For eksempel, i online banksystemet kunne et forretningskrav være 'Som bruger skal jeg være i stand til at få kontant transaktionsopgørelse'. | Funktionelt krav i dette online banksystem kan være: 'Når brugeren angiver datointervallet i transaktionsforespørgsel, bruges dette input af Server, og websiden forsynes med de nødvendige kontanttransaktionsdata'. |
| en | Forretningskrav siger 'hvad' aspekt af kundekrav. Eksempel, Hvad skal være synligt for brugeren, når brugeren logger på. | Funktionelle krav siger 'hvordan' aspekt af forretningskrav. Eksempel, Hvordan websiden skal vise brugerloginside, når brugeren godkender. |
| to | Forretningskrav identificeres af forretningsanalytikere. | Funktionelle krav oprettes / afledes af udviklere / softwarearkitekt |
| 3 | De understreger fordelene for organisationen og er relateret til forretningsmål. | Deres mål er opfyldelse af kundekrav. |
| 4 | Forretningskrav er fra kunden. | Funktionelle krav er afledt af softwarekrav, som igen er afledt af forretningskrav. |
| 5 | Forretningskrav testes ikke direkte af softwaretestingeniører. De testes for det meste af kunden. | Funktionelle krav testes af softwaretestingeniører og testes generelt ikke af kunder. |
| 6 | Forretningskravet er et krav på højt niveau. | Et funktionelt krav er et detaljeret teknisk kravdokument. |
Ikke-funktionelt krav
Det ikke-funktionelle krav siger om 'hvad et system skal være' snarere end 'hvad et system skal gøre' (funktionskrav). De stammer for det meste fra funktionelle krav baseret på input fra kunden og andre interessenter. Ikke-funktionelle krav til implementering af krav er dokumenteret i dokumentet Systemarkitektur.
Ikke-funktionelle krav forklarer kvalitetsaspekterne af det system, der skal konstrueres, dvs. ydeevne, bærbarhed, brugervenlighed osv. Ikke-funktionelle krav, i modsætning til funktionelle krav, implementeres trinvist i ethvert system.
URPS (Usability, Pålidelighed, Performance og Supportability) fra FURPS (Funktionalitet, anvendelighed, pålidelighed, ydeevne og support) kvalitetsattributter, der er meget udbredt i it-branchen til at måle kvaliteten af en softwareudvikler, er alle dækket af ikke-funktionelle krav. Derudover er der også andre kvalitetsattributter (detaljer i næste afsnit).
Wikipedia kalder det ikke-funktionelle krav undertiden 'hjælpeprogrammer' på grund af tilstedeværelsen af forskellige kvalitetsattributter som bærbarhed og stabilitet.
Typer af ikke-funktionelle krav
Ikke-funktionelle krav består af nedenstående undertyper (ikke udtømmende):
# 1) Ydeevne:
En præstationsattributtype af ikke-funktionelle krav måler systemets ydeevne. Eksempel: I ADAS surround view-systemet skal “bagkameraudsigt vises inden for 2 sekunder efter start af biltændingen”.
En anden eksempel ydeevne kan være fra et infotainment-system Navigationssystem. 'Når en bruger går til navigationsskærmen og indtaster destinationen, skal ruten beregnes inden for' X 'sekunder'. En til eksempel fra loginsiden til webapplikationen. 'Det tager tid for brugerprofilsiden at indlæse efter login.'
Husk at måling af systemets ydeevne er forskellig fra belastningsmåling. Under belastningstestning indlæser vi systemets CPU og RAM og kontrollerer systemgennemstrømningen. I tilfælde af ydeevne tester vi systemgennemstrømning under normale belastnings- / belastningsforhold.
# 2) Brugervenlighed :
Usability måler anvendeligheden af det softwaresystem, der udvikles.
For eksempel , er der udviklet en mobil webapplikation, der giver dig information om blikkenslagere og elektrikerens tilgængelighed i dit område.
Indgangen til denne app er postnummer og radius (i kilometer) fra din nuværende placering. Men for at indtaste disse data, hvis brugeren skal gennemse flere skærme og dataindtastningsindstillingen vises i små tekstfelter, der ikke er let synlige for en bruger, så er denne app ikke brugervenlig, og derfor vil appens anvendelighed være meget lav.
# 3) Vedligeholdelse :
Vedligeholdelse af et softwaresystem er den lethed, hvormed systemet kan vedligeholdes. Hvis gennemsnitstiden mellem fejl (MTBF) er lav, eller gennemsnitstid til reparation (MTTR) er høj for det system, der udvikles, betragtes systemets vedligeholdelsesevne som lav.
Vedligeholdelse måles ofte på kodeniveau ved hjælp af cyklomatisk kompleksitet. Cyklomatisk kompleksitet siger, at jo mindre kompleks koden er, jo lettere er det at vedligeholde softwaren.
Eksempel: Der udvikles et softwaresystem, der har det store antal døde koder (koder, der ikke bruges af andre funktioner eller moduler), meget komplekst på grund af overdreven brug af hvis / ellers tilstand, indlejrede sløjfer osv., Eller hvis systemet er enormt med koder, der kører i mange millioner linjer med koder og ingen ordentlige kommentarer. Et sådant system har lav vedligeholdelsesevne.
En anden eksempel kunne være en webside for online shopping. Hvis der er mange eksterne links på hjemmesiden, så brugeren kan få et overblik over produktet (dette for at spare på hukommelsen), er vedligeholdelsesevnen på dette websted lav. Dette skyldes, at hvis det eksterne websideslink ændres, skal det også opdateres på online shoppingwebstedet og det for ofte.
# 4) Pålidelighed :
Pålidelighed er et andet aspekt af tilgængelighed. Denne kvalitetsattribut understreger tilgængeligheden af et system under visse betingelser. Det måles som MTBF ligesom vedligeholdelsesevne.
Eksempel: Gensidigt eksklusive funktioner som bakkamera og Trailer i ADAS surround-kamerasystem skal fungere pålideligt i systemet uden interferens med hinanden. Når en bruger kalder på Trailer-funktionen, bør bagfra ikke forstyrre og omvendt, da begge funktioner har adgang til bilens bageste kamera.
En anden eksempel fra online forsikringsskadesystemet. Når en bruger begynder at rapportere om krav og derefter uploader relevante udgiftsregninger, skal systemet give tilstrækkelig tid til upload til at fuldføre og bør ikke annullere uploadprocessen hurtigt.
# 5) Bærbarhed:
Portabilitet betyder et softwaresystems evne til at arbejde i et andet miljø, hvis den underliggende afhængige ramme forbliver den samme.
Eksempel: Softwaresystem / komponent i et infotainment-system udviklet (nemlig Bluetooth-tjeneste eller multimedietjeneste) til en bilbilsproducent skal tillade brug i et andet infotainment-system med ringe eller ingen ændring i kode, selvom de to infotainment-systemer er helt forskellige .
Lad os tage en anden eksempel fra WhatsApp. Det er muligt at installere og bruge messaging-tjenesten på IOS, Android, Windows, Tablet, Laptop og Telefon.
# 6) Understøttelse:
Servicevilkår for et softwaresystem er en service / teknisk eksperts evne til at installere softwaresystemet i et realtidsmiljø, overvåge systemet, mens det kører, identificere eventuelle tekniske problemer i systemet og give en løsning til løsning af problemet.
Brugervenlighed er mulig, hvis systemet er udviklet til at lette servicevilkår.
Eksempel: Tilvejebringelse af periodisk påmindelse til brugeren om en softwareopdatering, der giver logning / sporingsmekanisme til fejlretningsproblemer, automatisk gendannelse fra fejl via tilbageføringsmekanisme (rull softwaresystemet tilbage til tidligere arbejdstilstandstilstand).
En anden eksempel fra Rediffmail. Da der var en opdatering i versionen af den webbaserede mailservice, tillod systemet brugeren at skifte til en nyere version af mailsystemet og holde den ældre intakt i nogle måneder. Dette forbedrer også brugeroplevelsen.
# 7) Tilpasningsevne:
Et systems tilpasningsevne defineres som et softwaresystems evne til at tilpasse sig ændringer i et miljø uden nogen ændring i dets adfærd.
Eksempel: Blokeringsfri bremsesystem i bil skal fungere som standard under alle vejrforhold (varmt eller koldt). En anden eksempel kunne være et Android-operativsystem. Det bruges i forskellige typer enheder, nemlig. Smartphones, tablet-computere og infotainment-systemer og er meget tilpasselige.
Ud over de 7 ikke-funktionelle krav, der er anført ovenfor, har vi mange andre som:
mysql interview spørgsmål og svar til 3 års erfaring
Tilgængelighed, Backup, Kapacitet, Overholdelse, Dataintegritet, Datalagring, Afhængighed, Implementering, Dokumentation, Holdbarhed, Effektivitet, Udnyttelighed, Udvidelsesmulighed, Fejlhåndtering, Fejltolerance, Interoperabilitet, Modificerbarhed, Driftsmæssighed, Privatliv, Læsbarhed, Rapportering, Modstandsdygtighed, Genanvendelighed, Robusthed, skalerbarhed, stabilitet, testbarhed, gennemstrømning, gennemsigtighed, integrerbarhed.
Dækning af alle disse ikke-funktionelle krav falder uden for denne artikels anvendelsesområde. Du kan dog læse mere om disse ikke-funktionelle kravstyper i Wikipedia.
Udledning af ikke-funktionelle krav fra funktionelle krav
Ikke-funktionelle krav kan afledes på mange måder, men den bedste og mest industrielle afprøvede måde er fra funktionelle krav.
Lad os tage eksemplet fra vores infotainment-systemer, som vi allerede har taget et par steder i denne artikel. Brugeren kan udføre mange handlinger på Infotainment-systemet, dvs. skift sang, skift sangkilde fra USB til FM- eller Bluetooth-lyd, indstil navigationsdestination, opdater infotainmentsoftware via en softwareopdatering osv.
# 1) Samling af ikke-funktionelle krav:
Vi viser en liste over de opgaver, der udføres af en bruger, hvilket er en del af funktionelle krav. Når brugerhandlingerne er noteret i UML-use case-diagrammet (hver ovale), starter vi relevante spørgsmål (hvert rektangel) om hver brugers handlinger. Svarene på disse spørgsmål vil give vores ikke-funktionelle krav.
# 2) Kategorisering af ikke-funktionelle krav:
Det næste trin er kategoriseringen af ikke-funktionelle krav, som vi har identificeret via spørgsmål. På dette stadium kan vi kontrollere det mulige svar og kategorisere svarene til mulige ikke-funktionelle kategorier eller forskellige kvaliteter.
På billedet nedenfor kan du se de mulige kvalitetsattributter identificeret fra svarene.
Funktionelle Vs ikke-funktionelle krav
Vi har allerede set, hvad funktionelle og ikke-funktionelle krav er, og hvordan de afledes. Lad os se på de store forskelle mellem funktionelle og ikke-funktionelle krav.
| Sl. ingen | Funktionelle krav (FR) | Ikke-funktionelle krav (NFR) |
|---|---|---|
| 7 | Funktionelle krav udgør skelettet til implementering af softwaresystem | Ikke-funktionelle krav kompletterer SW-systemet ved at hjælpe de funktionelle krav med at holde sammen, som en muskel. |
| en | De siger, hvad et system skal gøre. | De siger, hvad et system skal være. |
| to | De er beskrevet i dokumentet System Design. | De er detaljeret i systemarkitekturdokumentet. |
| 3 | De taler om funktionsmåden for en funktion eller funktion. | De taler om funktionsmåden for et helt system eller en komponent af systemet og ikke om en bestemt funktion. |
| 4 | Brugeren sender input og kontrollerer, om output vises korrekt. | Når brugeren sender et input, kan følgende spørgsmål besvares af NFR'er: i) Hvor lang tid tager det at vise output? ii) Er output i overensstemmelse med tiden? iii) Er der andre måder at overføre inputparameteren på? iv) Hvor let er det at overføre inputparameteren? |
| 5 | I en webapplikation skal brugeren kunne logge på via godkendelse er FR | Hvor lang tid tager det i en webapplikation at logge ind på hjemmesiden, udseendet på login-siden, brugervenligheden af en webside osv. Er en del af NFR |
| 6 | Funktionelle krav stammer først fra softwarekrav. | Ikke-funktionelle krav er afledt af funktionelle krav. |
| 8 | Funktionelle krav kan eksistere uden et ikke-funktionelt krav. | Ikke-funktionelle krav kan ikke eksistere uden funktionelle krav. |
| 9 | Et funktionelt krav giver konkret information om en funktion, Eksempel , Profilbillede på Facebook skal være synligt ved login. | Et funktionelt krav kan have mange ikke-funktionelle kravattributter. Eksempel, tid til at logge ind (ydeevne), udseende og følelse af profilsiden (brugervenlighed), antal brugere, der kan logge ind ad gangen (kapacitet, ydeevne) |
| 10 | Der kan udledes funktionelle krav fra SW-krav til næsten alle forretningskrav | NFR'er savnes ofte for at blive dokumenteret, da relevante spørgsmål ikke stilles til FR'er. |
| elleve | Implementering af et funktionelt krav udføres normalt i en softwarebygning. | NFR'er implementeres gennem hele projektets livscyklus, indtil den ønskede adfærd er opnået. |
| 12 | Disse er mest synlige for kunden. | Disse er for det meste ikke synlige for kunden, men kan opleves på lang sigt. Eksempel, Brugervenlighed, ydeevne osv. Kan kun opleves på lang sigt, men kan slet ikke ses. |
Konklusion
Krav udgør den grundlæggende byggesten til udvikling af ethvert softwaresystem. Det er muligt at opbygge et system med funktionelle krav, men dets evner kan ikke bestemmes eller måles. Når det er sagt, er det meget vigtigt at have funktionelle krav af god kvalitet afledt af et forretningskrav for at have et fungerende softwaresystem af høj kvalitet.
Derfor giver funktionelle krav retningen til implementering af et softwaresystem, men ikke-funktionelle krav bestemmer kvaliteten af implementeringen, som slutbrugerne vil opleve.
Anbefalet læsning
- Hvordan testes softwarekravspecifikation (SRS)?
- Funktionel testning mod ikke-funktionel testning
- Hvordan testes en ansøgning uden krav?
- Hvad er kravanalyse og indsamling i SDLC?
- 5 dødbringende fejl i kravstyring og hvordan man kan overvinde dem
- Funktioner af funktionelle krav og ikke-funktionelle krav
- Sådan oprettes krav Sporbarhedsmatrix (RTM): Eksempel og eksempelskabelon
- Top 20+ Bedste krav til styringsværktøjer (Den komplette liste)