features functional requirements
Denna handledning förklarar typerna, funktionerna, jämförelsen mellan funktionella och icke-funktionella krav och affärsmässiga kontra funktionella krav med exempel:
Funktionella krav definierar vad ett mjukvarusystem ska göra. Den definierar en funktion av ett mjukvarusystem eller dess modul. Funktionalitet mäts som en uppsättning ingångar till systemet som testas till utgången från systemet.
Funktionskravsimplementering i ett system planeras i systemdesignfasen medan det i fall av icke-funktionella krav planeras i dokumentet Systemarkitektur. Funktionskravet stöder generering av icke-funktionella krav.
Vad du kommer att lära dig:
Funktionella krav och icke-funktionella krav
Funktionella krav
Låt oss förstå vad som är funktionella krav med hjälp av exempel-
Exempel: I ett ADAS-projekt för fordonsindustrin kan ett funktionellt krav för surround-view-systemet vara att 'Rear Camera should detect a hot or object'. Icke-funktionella krav här kan vara 'hur snabbt varningen för en användare ska visas när ett hot upptäcks av kamerasensorer'.
Ta en annan exempel av projektet Infotainment systems. Användaren aktiverar Bluetooth här från HMI och kontrollerar om Bluetooth är aktiverat eller inte. Notera , andra Bluetooth-tjänster aktiveras (från grå till fetstil) när användaren aktiverar Bluetooth.
bästa videokonverteraren för Windows 7
Så funktionella krav talar om ett visst systemresultat när en uppgift utförs av dem av användaren. Å andra sidan ger det icke-funktionella kravet systemets eller dess komponents övergripande beteende och inte funktion.
Typer av funktionella krav
Funktionskrav kan inkludera följande komponenter som kan mätas som en del av funktionstestning:
# 1) Interoperabilitet: Krav beskriver om ett mjukvarusystem är kompatibelt över olika system.
Exempel: För Bluetooth-funktionskrav i bilinfotainmentsystemet, när användaren kopplar ihop en Bluetooth-aktiverad Android-baserad smartphone till QNX-baserad infotainmentsystem, borde vi kunna överföra telefonboken till infotainment-systemet eller strömma musik från vår telefon till infotainment-systemet.
Så interoperabilitet kontrollerar om kommunikation mellan de två olika enheterna är möjlig eller inte.
Annan exempel kommer från e-posttjänstsystemen som Gmail. Gmail tillåter import av e-post från en annan e-postutbytesserver som Yahoo.com eller Rediffmail.com. Detta är möjligt på grund av interoperabilitet mellan e-postservrar.
# 2) Säkerhet: Det funktionella krav beskriver säkerhetsaspekten av programvarukrav.
Exempel: Cybersäkerhetsbaserade tjänster i ADAS surround-kamerabaserade system som använder Controller Area Network (CAN) som skyddar systemet från säkerhetshotet.
Annan exempel är från den sociala nätverkssajten Facebook . En användares data ska vara säkra och får inte läcka ut till en utomstående. Vi hoppas att det här exemplet på Facebook ger lägre säkerhet för läsarna på grund av senaste dataintrång på Facebook och de konsekvenser som Facebook står inför.
# 3) Noggrannhet: Noggrannhet definierar att data som matats in i systemet beräknas korrekt och används av systemet och att utdata är korrekt.
Exempel: När ett CAN-signalvärde sänds över CAN-bussen i en styrenhetsnätverk (dvs. ABS-enhet, HVAC-enhet, instrumentklusterenhet etc.) kommer en annan ECU att kunna identifiera om de skickade data är korrekta eller inte via CRC-kontroll.
Annan exempel kan vara från en onlinebanklösning. När användaren får en fond ska det mottagna beloppet krediteras exakt på kontot och ingen variation i noggrannheten accepteras.
# 4) Överensstämmelse: Funktionskrav för efterlevnad bekräftar att det utvecklade systemet överensstämmer med industristandarder.
Exempel: Oavsett om Bluetooth-profilfunktioner (dvs. ljudströmning via A2DP, telefonsamtal via HFP) överensstämmer med Bluetooth SIG-versioner av releaseprofiler.
Annan exempel kan vara det som Apple Car spelar i bilinfotainmentsystemet. Appen i infotainment får ett certifikat från Äpple om alla förutsättningar som nämns på Apples webbplats uppfylls av tredjeparts Car Play-enheter (infotainment i detta fall).
Annan exempel kan vara från en webbaserad applikation för järnvägsbiljettsystemet. Webbplatsen bör följa cybersäkerhetsriktlinjerna och följa Internet när det gäller tillgänglighet.
Exempel på kravformulär:
Vi har redan sett vad funktionskrav är med några exempel. Låt oss nu se hur ett funktionellt krav skulle se ut när det integrerades i kravhanteringsverktyg som IBM DOORS. Det finns flera attribut som ska tas i beaktande när du dokumenterar ett funktionskrav i kravhanteringsverktyget.
Nedan följer några attribut som ska beaktas:
- Objekt typ: Detta attribut förklarar vilket avsnitt i kravdokumentet som ingår i detta attribut. De kan vara rubrik, förklaring, krav osv. För det mesta beaktas avsnittet 'Krav' för implementering och testning medan rubriker och förklaringsavsnitt används som stödjande beskrivningar för krav för bättre förståelse.
- Ansvarsfull person: En författare som har dokumenterat kravet i kravhanteringsverktyget.
- Projekt / systemnamn: Projektet för vilket kravet gäller, till exempel, ”Infotainment Systems för XYZ OEM (originalutrustningstillverkare) ett bilföretag eller webbapplikation för ABC-aktiebolag”.
- Kravsversion nummer: Detta fält / attribut meddelar kravets versionsnummer om kravet har genomgått flera ändringar på grund av kunduppdateringar eller förändringar i systemdesign.
- Kravs-ID: Detta attribut nämner det unika krav-id: t. Krav-ID används för att enkelt spåra kraven i databasen och även för att effektivt kartlägga kraven i kod. Det kan också användas för att ge en hänvisning till kraven när du loggar in fel i spårningsverktygen.
- Kravsbeskrivning: Detta attribut är ett av de viktigaste attributen som förklarar kravet. Genom att läsa detta attribut skulle en ingenjör kunna förstå kravet.
- Kravstatus: Kravstatusattribut säger om status för ett krav i kravhanteringsverktyget, dvs om det godkänns, i vänteläge, avvisas eller tas bort projektet.
- Kommentarer: Detta attribut ger den ansvariga personen eller kravhanteraren möjlighet att dokumentera kommentarer om kravet. Exempel: en möjlig kommentar för ett funktionellt krav kan vara 'beroende av ett programvarupaket från tredje part för att implementera kravet'.
En ögonblicksbild från DOORS
Hämta funktionella krav från företagskrav
Detta omfattas redan som en del av avsnittet ” Hämta funktionella krav från företagskrav ' under Kravsanalys artikel.
Affärskrav mot funktionella krav
Denna skillnad täcks löst i Kravsanalys artikel. Vi kommer dock att försöka markera några fler punkter här i nedanstående tabell:
| Sl. Nej. | Affärskrav | Funktionella krav |
|---|---|---|
| 7 | Till exempel, i internetbanksystemet kan ett affärsbehov vara 'Som användare ska jag kunna få kontoutdrag'. | Funktionella krav i detta onlinebanksystem kan vara, 'När användaren anger datumintervallet i transaktionsfrågan, används denna ingång av Server och webbsidan förses med nödvändiga kontanttransaktionsdata'. |
| ett | Affärsbehov säger 'vad' aspekt av kundkrav. Exempel, Vad ska vara synligt för användaren efter att användaren loggat in. | Funktionella krav säger 'hur' aspekt av företagets krav. Exempel, Hur webbsidan ska visa användarnas inloggningssida när användaren autentiserar. |
| två | Affärsbehov identifieras av affärsanalytiker. | Funktionella krav skapas / härleds av utvecklare / programvaruarkitekt |
| 3 | De betonar nyttan för organisationen och är relaterade till affärsmål. | Deras mål är uppfyllande av kundkrav. |
| 4 | Företagets krav är från kunden. | Funktionella krav härrör från programvarukrav, vilket i sin tur härrör från företagskrav. |
| 5 | Företagskraven testas inte direkt av Software Test Engineers. De testas mest av kunden. | Funktionskrav testas av programvarutestingenjörer och testas vanligtvis inte av kunder. |
| 6 | Affärsbehovet är ett krav på hög nivå. | Ett funktionellt krav är ett detaljerat tekniskt kravdokument. |
Icke funktionellt krav
Det icke-funktionella kravet säger om 'vad ett system ska vara' snarare än 'vad ett system ska göra' (funktionskrav). De härrör främst från funktionella krav baserat på input från kunden och andra intressenter. Icke-funktionella detaljer för implementering av krav dokumenteras i dokumentet Systemarkitektur.
Icke-funktionella krav förklarar kvalitetsaspekterna hos systemet som ska konstrueras, nämligen. prestanda, bärbarhet, användbarhet etc. Icke-funktionella krav, till skillnad från funktionella krav, implementeras stegvis i alla system.
URPS (Användbarhet, pålitlighet, prestanda och support) från FURPS (Funktionalitet, användbarhet, tillförlitlighet, prestanda och support) kvalitetsattribut som används i stor utsträckning inom IT-branschen för att mäta kvaliteten hos en programvaruutvecklare, täcks alla av icke-funktionella krav. Dessutom finns det andra kvalitetsattribut också (detaljer i nästa avsnitt).
Wikipedia kallar det icke-funktionella kravet ibland ”hjälpsamhet” på grund av närvaron av olika kvalitetsattribut som bärbarhet och stabilitet.
Typer av icke-funktionella krav
Icke-funktionella krav består av nedanstående undertyper (icke-uttömmande):
# 1) Prestanda:
En prestandaattribut av icke-funktionella krav mäter systemets prestanda. Exempel: I ADAS surround-visningssystem ska ”bakre kameravy visas inom två sekunder efter att biltändningen startat”.
Annan exempel prestanda kan komma från ett infotainment-system. Navigationssystem. “När en användare går till navigeringsskärmen och går in i destinationen ska rutten beräknas inom“ X ”sekunder. En till exempel från inloggningssidan för webbapplikationen. 'Det tar tid för användarprofilsidan att laddas efter inloggning.'
Kom ihåg att mätningen av systemets prestanda skiljer sig från belastningsmätningen. Under belastningstester laddar vi systemets CPU och RAM och kontrollerar systemets genomströmning. Vid prestanda testar vi systemgenomströmningen under normala belastnings- / påkänningsförhållanden.
# 2) Användbarhet :
Användbarhet mäter användbarheten för det programvarusystem som utvecklas.
Till exempel , utvecklas en mobil webbapplikation som ger dig information om rörmokare och elektrikerens tillgänglighet i ditt område.
Ingången till den här appen är postnummer och radie (i kilometer) från din nuvarande plats. Men för att ange dessa data, om användaren måste bläddra igenom flera skärmar och datainmatningsalternativet visas i små textrutor som inte är lätt synliga för en användare, är den här appen inte användarvänlig och följaktligen kommer appens användbarhet att vara väldigt låg.
# 3) Underhållbarhet :
Att underhålla ett mjukvarusystem är hur enkelt systemet kan underhållas. Om medelvärdet mellan fel (MTBF) är lågt eller medelvärde för reparation (MTTR) är högt för systemet som utvecklas, anses systemets underhållsförmåga vara lågt.
Hållbarhet mäts ofta på kodnivå med cyklomatisk komplexitet. Cyklomatisk komplexitet säger att ju mindre komplex koden är, desto lättare är det att underhålla programvaran.
Exempel: Ett mjukvarusystem utvecklas som har det stora antalet döda koder (koder som inte används av andra funktioner eller moduler), mycket komplicerat på grund av överdriven användning av om / annat-tillstånd, kapslade slingor etc. eller om systemet är enormt med koder som körs i många miljoner rader med koder och inga ordentliga kommentarer. Ett sådant system har låg hållbarhet.
Annan exempel kan vara på webbsidan för online shopping. Om det finns många externa länkar på webbplatsen så att användaren kan få en överblick över produkten (detta för att spara i minnet), är den här webbplatsens underhållsförmåga låg. Detta beror på att om den externa webbsidans länk ändras måste den också uppdateras på online-shoppingwebbplatsen och det för ofta.
# 4) Pålitlighet :
Tillförlitlighet är en annan aspekt av tillgänglighet. Detta kvalitetsattribut betonar tillgängligheten av ett system under vissa förhållanden. Det mäts som MTBF precis som underhåll.
Exempel: Ömsesidigt exklusiva funktioner som bakre kamera och Trailer i ADAS surround-kamerasystem bör fungera tillförlitligt i systemet utan att störa varandra. När en användare ringer upp Trailer-funktionen bör inte baksidan störa och tvärtom eftersom båda funktionerna går in i bilens bakre kamera.
Annan exempel från onlineförsäkringsanspråkssystemet. När en användare börjar rapportera anspråk och sedan laddar upp relevanta utgiftsräkningar bör systemet ge tillräckligt med tid för att uppladdningen ska kunna slutföras och bör inte avbryta uppladdningsprocessen snabbt.
# 5) Bärbarhet:
Portabilitet betyder ett programvarusystems förmåga att arbeta i en annan miljö om det underliggande beroende ramverket förblir detsamma.
Exempel: Mjukvarusystem / komponent i ett infotainment-system som utvecklats (nämligen Bluetooth-tjänst eller multimedietjänst) för en biltillverkare bör tillåta användning i ett annat infotainmentsystem med liten eller ingen förändring av kod, även om de två infotainmentsystemen är helt olika .
Låt oss ta en annan exempel från WhatsApp. Det är möjligt att installera och använda meddelandetjänsten på IOS, Android, Windows, surfplatta, bärbar dator och telefon.
# 6) Stödbarhet:
Servicevänlighet för ett mjukvarusystem är förmågan hos en service / teknisk expert att installera mjukvarusystemet i en realtidsmiljö, övervaka systemet medan det körs, identifiera eventuella tekniska problem i systemet och tillhandahålla en lösning för att lösa problemet.
Servicevänlighet är möjlig om systemet är utvecklat för att underlätta service.
Exempel: Tillhandahålla periodisk påminnelse popup till användaren för en mjukvaruuppdatering, tillhandahålla loggning / spårningsmekanism för att felsöka problem, automatisk återställning från fel via återställningsmekanism (rulla tillbaka mjukvarusystemet till tidigare arbetsläge).
hur skulle du testa en penna
Annan exempel från Rediffmail. När det gjordes en uppdatering i versionen av den webbaserade e-posttjänsten, tillät systemet användaren att byta till en nyare version av e-postsystemet och hålla den äldre intakt i några månader. Detta förbättrar också användarupplevelsen.
# 7) Anpassningsförmåga:
Anpassningsförmågan hos ett system definieras som ett mjukvarusystems förmåga att anpassa sig till förändringar i en miljö utan någon förändring i dess beteende.
Exempel: Låsningsfria bromssystem i bilen ska fungera enligt standard under alla väderförhållanden (varmt eller kallt). Annan exempel kan vara det för ett Android-operativsystem. Den används i olika typer av enheter, dvs. Smartphones, surfplattor och infotainment-system och är mycket anpassningsbara.
Förutom de sju icke-funktionella kraven som listas ovan har vi många andra som:
Tillgänglighet, säkerhetskopiering, kapacitet, efterlevnad, dataintegritet, datalagring, beroende, distribution, dokumentation, hållbarhet, effektivitet, utnyttjbarhet, utbyggbarhet, felhantering, feltolerans, interoperabilitet, modifierbarhet, driftbarhet, integritet, läsbarhet, rapportering, motståndskraft, återanvändbarhet, Robusthet, skalbarhet, stabilitet, testbarhet, genomströmning, transparens, integrerbarhet.
Att täcka alla dessa icke-funktionella krav omfattas inte av denna artikel. Du kan dock läsa mer om dessa icke-funktionella kravtyper i Wikipedia.
Hämta icke-funktionella krav från funktionella krav
Icke-funktionella krav kan härledas på många sätt, men det bästa och mest industrin beprövade sättet är från funktionella krav.
Låt oss ta exemplet från våra infotainmentsystem som vi redan har tagit på några få ställen i den här artikeln. Användaren kan utföra många åtgärder på Infotainment-systemet, dvs. ändra låt, ändra låtkälla från USB till FM- eller Bluetooth-ljud, ställa in navigeringsdestination, uppdatera infotainment-programvara via en programuppdatering etc.
# 1) Insamling av icke-funktionella krav:
Vi listar de uppgifter som utförs av en användare, vilket är en del av funktionskraven. När användaråtgärderna har noterats i UML-användningsfallsdiagrammet (varje oval) startar vi relevanta frågor (varje rektangel) om varje användares åtgärder. Svaren på dessa frågor kommer att ge våra icke-funktionella krav.
# 2) Kategorisering av icke-funktionella krav:
Nästa steg är kategoriseringen av icke-funktionella krav som vi har identifierat via frågor. I det här skedet kan vi kontrollera det möjliga svaret och kategorisera svaren på möjliga icke-funktionella kategorier eller olika kvaliteter.
På bilden nedan kan du se de möjliga kvalitetsattribut som identifierats från svaren.
Funktionella mot icke-funktionella krav
Vi har redan sett vad funktionella och icke-funktionella krav är och hur de härleds. Låt oss titta på de stora skillnaderna mellan funktionella och icke-funktionella krav.
| Sl. Nej | Funktionskrav (FR) | Icke-funktionella krav (NFR) |
|---|---|---|
| 7 | Funktionskrav utgör skelettet för implementering av programvarusystem | Icke-funktionella krav kompletterar SW-systemet genom att hjälpa funktionskraven att hålla ihop, som en muskel. |
| ett | De säger, vad ett system ska göra. | De säger, vad ett system borde vara. |
| två | De beskrivs i dokumentet Systemdesign. | De beskrivs i systemarkitekturdokumentet. |
| 3 | De pratar om beteendet hos en funktion eller funktion. | De pratar om arbetsbeteendet hos ett helt system eller en komponent i systemet och inte en viss funktion. |
| 4 | Användaren kommer att skicka in och kontrollera om utmatningen visas korrekt. | När användaren skickar en inmatning kan följande frågor besvaras av NFR: er: i) Hur lång tid tar det att visa utdata? ii) Är produktionen överensstämmande med tiden? iii) Finns det andra sätt att skicka inmatningsparametern? iv) Hur lätt är det att skicka inmatningsparametern? |
| 5 | I en webbapplikation ska användaren kunna logga in via autentisering är FR | I en webbapplikation är hur lång tid det tar att logga in på webbplatsen, utseendet på inloggningssidan, användarvänligheten på en webbsida etc. en del av NFR |
| 6 | Funktionella krav härleds först från programvarukraven. | Icke-funktionella krav härrör från funktionella krav. |
| 8 | Funktionella krav kan existera utan ett icke-funktionellt krav. | Icke-funktionella krav kan inte existera utan funktionella krav. |
| 9 | Ett funktionellt krav ger konkret information om en funktion, Exempel , Profilfoto på Facebook ska vara synligt vid inloggning. | Ett funktionellt krav kan ha många icke-funktionella kravattribut. Exempel, tid att logga in (prestanda), utseende och känsla på profilsidan (användbarhet), antal användare som kan logga in åt gången (kapacitet, prestanda) |
| 10 | Att härleda funktionskrav från SW-krav är möjligt för nästan alla affärsbehov | NFR: er saknas ofta för att dokumenteras, eftersom relevanta frågor inte ställs om FR. |
| elva | Implementering av ett funktionellt krav görs normalt i en programvarubyggning. | NFR: er implementeras under hela projektets livscykel tills önskat beteende uppnås. |
| 12 | Dessa är mest synliga för kunden. | Dessa är oftast inte synliga för kunden men kan upplevas på lång sikt. Exempel, Användbarhet, prestanda etc. kan endast upplevas på lång sikt men kan inte synas alls. |
Slutsats
Krav utgör den grundläggande byggstenen för att utveckla ett programvarusystem. Det är möjligt att bygga ett system med funktionella krav men dess förmågor kan inte bestämmas eller mätas. Med detta sagt är det mycket viktigt att ha funktionskrav av god kvalitet som härrör från ett affärsbehov för att ha ett fungerande mjukvarusystem av hög kvalitet.
Följaktligen ger funktionella krav riktningen för implementeringen av ett mjukvarusystem men icke-funktionella krav bestämmer kvaliteten på implementeringen som slutanvändarna kommer att uppleva.
Rekommenderad läsning
- Hur testar jag specifikationer för mjukvarukrav (SRS)?
- Funktionell testning mot icke-funktionell testning
- Hur testar jag en ansökan utan krav?
- Vad är kravanalys och insamling i SDLC?
- 5 Dödliga misstag i kravhantering och hur man övervinner dem
- Funktioner av funktionella krav och icke-funktionella krav
- Hur man skapar krav Spårbarhetsmatris (RTM): Exempel och exempelmall
- Topp 20+ bästa verktyg för hantering av krav (hela listan)