Vad är icke-funktionella krav inom mjukvaruteknik?

By: Charles Moore Charles Moore
Hours Uppdaterad

⚡ Smart sammanfattning

Icke-funktionella krav specificerar kvalitetsattribut som prestanda, säkerhet, användbarhet, tillförlitlighet, skalbarhet och portabilitet, och definierar hur väl ett programvarusystem måste bete sig och omvandlar vaga förväntningar till mätbara, testbara och genomförbara tekniska mål under hela leveranscykeln.

  • 📘 Definition: Ett icke-funktionellt krav, eller NFR, beskriver hur väl ett system presterar vad gäller prestanda, säkerhet, användbarhet, tillförlitlighet och portabilitet.
  • 🗂️ Vanliga typer: Användbarhet, säkerhet, tillförlitlighet, skalbarhet, kapacitet, tillgänglighet, underhållbarhet och regelefterlevnad är kategorierna för teamen. track oftast.
  • 📊 FURPS+ Modell: FURPS+ grupperar NFR:er i funktionalitet, användbarhet, tillförlitlighet, prestanda, supportbarhet och design- eller gränssnittsbegränsningar.
  • 🎯 Testbara påståenden: Ersätt ”snabb” eller ”säker” med numeriska tröskelvärden och verifieringsmetoder så att NFR kan testas och accepteras.
  • ???? Funktionell kontrast: Funktionella krav anger vad systemet gör, medan icke-funktionella krav anger hur väl det gör det under verkliga förhållanden.
  • ✅ Affärspåverkan: Saknade NFR:er är den främsta orsaken till produktionsincidenter, myndighetsresultat och kostsamma omarbetningar av arkitekturen i sent skede.
Läs mer

Icke-funktionella krav inom programvaruteknik

Vad är ett icke-funktionellt krav?

A Icke-funktionella krav (NFR) specificerar ett kvalitetsattribut för ett programvarusystem. NFR:er bedömer systemet utifrån responsivitet, användbarhet, säkerhet, portabilitet och andra kvalitetsattribut som är avgörande för framgång. Ett vanligt exempel på icke-funktionella krav är, "hur snabbt laddas webbplatsen?" Att inte uppfylla icke-funktionella krav skapar system som frustrerar användarna.

Icke-funktionella krav inom mjukvaruutveckling innebär begränsningar för systemets design över hela den agila eftersläpningen. Till exempel bör webbplatsen laddas på tre sekunder när antalet samtidiga användare överstiger 10 000. Att beskriva icke-funktionella krav är lika viktigt som att fånga funktionella krav.

Typer av icke-funktionella krav

De viktigaste kategorierna av icke-funktionella krav är:

Typer av icke-funktionella krav

Typer av icke-funktionella krav

  • användbarhet
  • Användbarhet
  • hanterbarhet
  • Återvinningsbarhet
  • Säkerhet
  • Data Integrity
  • Kapacitet
  • Tillgänglighet
  • Skalbarhet
  • Interoperabilitet
  • Pålitlighet
  • underhåll
  • Regelefterlevnad
  • Miljöbegränsningar

Exempel på icke-funktionella krav

Här är praktiska exempel på icke-funktionella krav:

  1. Användare måste ändra det ursprungliga lösenordet efter den första lyckade inloggningen, och det ursprungliga lösenordet får aldrig återanvändas.
  2. Anställda ska inte tillåtas att uppdatera sina egna löneuppgifter, och alla sådana försök ska rapporteras till säkerhetsadministratören.
  3. Varje misslyckat försök av en användare att få åtkomst till ett dataobjekt ska registreras i en revisionslogg.
  4. Webbplatsen ska stödja 20 miljoner samtidiga användare utan att försämra svarstiderna.
  5. Programvaran ska vara portabel så att det inte skapar några problem att byta från ett operativsystem till ett annat.
  6. Informationsskydd, export av begränsad teknik och immateriella rättigheter ska vara granskningsbara.

Funktionella kontra icke-funktionella krav

De viktigaste skillnaderna mellan funktionella och icke-funktionella krav är:

Driftparametrar Funktionskrav Icke-funktionella krav
Vad är det? Verb attribut
Krav Det är obligatoriskt Det är icke-obligatoriskt
Typ av fångst Det fångas i användningsfall. Det fångas som ett kvalitetsattribut.
Slutresultat Produktegenskap Produktegenskaper
Fångande Lätt att fånga Svårt att fånga
Mål Hjälper dig att verifiera programvarans funktionalitet. Hjälper dig att verifiera programvarans prestanda.
Fokusområde Fokusera på användarens krav Koncentrerar sig på användarens förväntningar.
Dokumentation Beskriv vad produkten gör Beskriver hur produkten fungerar
Typ av testning funktions~~POS=TRUNC som system-, integrations-, end-to-end-testning, API-testning etc. Icke-funktionella tester som prestanda, stress, användbarhet, säkerhetstestning, etc.
Testutförande Testexekvering görs före icke-funktionell testning. Efter funktionstestet
produkt~~POS=TRUNC Produktegenskaper Produktegenskaper

RELATERADE ARTIKLAR

Fördelar med icke-funktionella krav

De största fördelarna med Icke-funktionell testning är:

  • Icke-funktionella krav säkerställer att systemet följer lagar och regler för efterlevnad.
  • De skyddar systemets tillförlitlighet, tillgänglighet och prestanda.
  • De levererar en bra användarupplevelse och enkel användning.
  • De formar programvarans säkerhetspolicy.

Nackdelar med icke-funktionella krav

Vanliga nackdelar med icke-funktionella krav är:

  • Icke-funktionella krav kan påverka flera programvaruundersystem på hög nivå.
  • De kräver särskild hänsyn under arkitektur och övergripande design, vilket ökar kostnaden.
  • Implementeringen mappas sällan till ett enda programvarusystem.
  • De är svåra att modifiera när arkitekturfasen är klar.

FURPS+ modell för klassificering av icke-funktionella krav

FURPS+ är den mest använda taxonomin för icke-funktionella krav. Ursprungligen utvecklad av Hewlett-Packard, grupperar den kvalitetsattribut i fem huvudkategorier plus ytterligare begränsningar markerade med "+". Modellen hjälper affärsanalytiker att undvika att missa en hel klass av krav.

  • Funktionalitet: Funktioner, säkerhet och återanvändbarhet som går utöver den grundläggande funktionslistan.
  • användbarhet: Mänskliga faktorer, estetik, konsekvens, dokumentation och responsivitet i användarupplevelsen.
  • Pålitlighet: Tillgänglighet, medeltid mellan fel, återställningsbarhet, förutsägbarhet och noggrannhet.
  • Prestanda: Hastighet, dataflöde, kapacitet, skalbarhet och resursförbrukning under belastning.
  • Stödbarhet: Testbarhet, flexibilitet, installationsbarhet, lokaliserbarhet och underhållbarhet hos det levererade systemet.
  • Plus (+): Design, implementering, gränssnitt och fysiska begränsningar såsom nödvändiga plattformar, standarder eller hårdvara.

Team som mappar alla icke-funktionella krav till en FURPS+-kategori är mindre benägna att leverera ett system som uppfyller funktioner men brister i prestanda, säkerhet eller underhållbarhet.

Hur man skriver testbara icke-funktionella krav

Ett välskrivet icke-funktionellt krav är mätbart, verifierbart och tidsbundet. Vaga påståenden som "systemet måste vara snabbt" eller "appen ska vara säker" är ambitioner, inte krav. Följ stegen nedan för att omvandla en intention till en testbar icke-funktionell referens (NFR).

  1. Identifiera kvalitetsattributet. Mappa problemet till en FURPS+-kategori så att teamet vet om det är ett krav på prestanda, användbarhet, säkerhet eller tillförlitlighet.
  2. Välj ett mätvärde. Varje NFR behöver en enhet – millisekunder, förfrågningar per sekund, samtidiga användare, procentuell drifttid eller en efterlevnadsstandard som ISO 27001.
  3. Ställ in ett numeriskt tröskelvärde. Ersätt ”snabb” med ”under 400 millisekunder vid den 95:e percentilen”. Ersätt ”hög tillgänglig” med ”99.9 procents månatlig drifttid”.
  4. Beskriv tillståndet. Ange belastningen, miljön eller användarsegmentet som tröskeln gäller för, till exempel "under försäljningstopp med 10 000 samtidiga användare".
  5. Definiera verifieringsmetoden. Notera testtypen – belastningstest, penetrationstest, kaosexperiment, tillgänglighetsrevision – och verktyget som bekräftar tröskelvärdet.
  6. Tillämpa SMART-kontrollen. Bekräfta att kravet är specifikt, mätbart, uppnåeligt, relevant och tidsbundet innan det hamnar i eftersläpningen.

Exempel på omskrivning: ”Systemet ska vara snabbt” blir ”Kassasidan ska svara på under 500 millisekunder vid den 95:e percentilen med 5 000 samtidiga användare, verifierad av en JMeter ladda testa varje utgåva.” Det reviderade uttalandet låter utvecklare designa för det, testare verifiera det och produktägare acceptera det utan argument.

Vanliga frågor

AI-drivna belastnings- och prestandaverktyg genererar realistisk trafik, upptäcker avvikelser i svarstidsfördelningar och förutspår skalningsgränser före produktion. AI inspekterar även loggar och åtkomstmönster för att flagga säkerhetshändelser som traditionella regelbaserade verktyg missar.

Copilot och GPT omvandlar vaga kvalitetsutlåtanden till mätbara icke-relaterade frekvenser (NFR) med hjälp av mätvärden, tröskelvärden, villkor och verifieringsmetoder. Affärsanalytiker granskar varje utkast mot FURPS+-kategorier och SMART-ramverket innan de accepterar det i eftersläpningen.

Funktionstestning kontrollerar om funktioner, såsom inloggning eller sökning, fungerar korrekt. Icke-funktionstestning mäter hur väl systemet presterar under belastning, stress och användning, och täcker prestanda, säkerhet, användbarhet, kompatibilitet och tillförlitlighetsmål.

Skalbarhet, tillgänglighet, latens, elasticitet och kostnadseffektivitet dominerar molnbaserade NFR:er. Teamen track-observabilitet, mål för katastrofåterställning som RPO och RTO, och efterlevnad i flera regioner eftersom de driver de flesta beslut om molnarkitektur.

Välj ett mätvärde med en enhet, ange ett numeriskt tröskelvärde, beskriv villkoret under vilket det gäller och namnge verifieringsmetoden. Till exempel, svarstid under 400 millisekunder vid den 95:e percentilen med 5 000 användare, verifierad av JMeter.

Kryptering av data i vila och under överföring, autentiseringsstyrka, rollbaserad auktorisering, revisionsloggning, sessionstimeout och efterlevnad av standarder som ISO 27001, PCI DSS och GDPR är de säkerhets-NFR:er som de flesta team dokumenterar.

Att använda vaga adjektiv, utelämna metriken eller villkoret, lista NFR:er endast i slutet av ett projekt och kopiera och klistra in standardbeskrivningar som inget test kan verifiera är de vanligaste misstagen som leder till omarbetning av arkitekturen i sent skede.

NFR finns i programvarukravspecifikationen, arkitekturbeslutsregister, servicenivåavtal och checklistor för definition av färdigt resultat. Agila team kopplar ofta mätbara NFR till epic-rapporter och till definitionen av "redo för varje användarberättelse".

Sammanfatta detta inlägg med: