Što je nefunkcionalni zahtjev u softverskom inženjerstvu?

By: Charles Moore Charles Moore
Hours Ažurirano

⚡ Pametni sažetak

Nefunkcionalni zahtjevi specificiraju atribute kvalitete kao što su performanse, sigurnost, upotrebljivost, pouzdanost, skalabilnost i prenosivost, definirajući koliko dobro se softverski sustav mora ponašati i pretvarajući nejasna očekivanja u mjerljive, testirane i provedive inženjerske ciljeve tijekom životnog ciklusa isporuke.

  • 📘 Definicija: Nefunkcionalni zahtjev ili NFR opisuje koliko dobro sustav funkcionira u pogledu performansi, sigurnosti, upotrebljivosti, pouzdanosti i prenosivosti.
  • 🗂️ Uobičajene vrste: Upotrebljivost, sigurnost, pouzdanost, skalabilnost, kapacitet, dostupnost, održavanje i usklađenost s propisima su kategorije timova track najčešće.
  • 📊 FURPS+ Model: FURPS+ grupira NFR-ove u funkcionalnost, upotrebljivost, pouzdanost, performanse, mogućnost podrške i ograničenja dizajna ili sučelja.
  • 🎯 Testibilne izjave: Zamijenite „brzo“ ili „sigurno“ numeričkim pragovima i metodama provjere kako bi se NFR mogao testirati i prihvatiti.
  • 🆚 Funkcionalni kontrast: Funkcionalni zahtjevi navode što sustav radi; nefunkcionalni zahtjevi navode koliko dobro to radi u stvarnim uvjetima.
  • ✅ Poslovni utjecaj: Nedostatak NFR-ova vodeći je uzrok incidenata u proizvodnji, regulatornih nalaza i skupih preinaka arhitekture u kasnoj fazi.
Pročitaj više

Nefunkcionalni zahtjevi u softverskom inženjerstvu

Što je nefunkcionalni zahtjev?

A Nefunkcionalni zahtjev (NFR) specificira atribut kvalitete softverskog sustava. NFR-ovi ocjenjuju sustav na temelju responzivnosti, upotrebljivosti, sigurnosti, prenosivosti i drugih atributa kvalitete koji su ključni za uspjeh. Uobičajeni primjer nefunkcionalnog zahtjeva je, "koliko se brzo učitava web stranica?" Neispunjavanje nefunkcionalnih zahtjeva stvara sustave koji korisnike ostavljaju frustriranima.

Nefunkcionalni zahtjevi u softverskom inženjerstvu nameću ograničenja na dizajn sustava u cijelom agilnom zaostatku. Na primjer, stranica bi se trebala učitati za tri sekunde kada broj istovremenih korisnika premaši 10 000. Opisivanje nefunkcionalnih zahtjeva jednako je važno kao i opisivanje funkcionalnih zahtjeva.

Vrste nefunkcionalnih zahtjeva

Glavne kategorije nefunkcionalnih zahtjeva su:

Vrste nefunkcionalnih zahtjeva

Vrste nefunkcionalnih zahtjeva

  • Upotrebljivost
  • servisiranja
  • upravljivost
  • Nadoknadivost
  • Sigurnost
  • Datum Integrity
  • Kapacitet
  • Dostupnost
  • skalabilnost
  • Interoperabilnost
  • Pouzdanost
  • sposobnost snabdijevanja
  • Usklađenost s propisima
  • Ograničenja okoline

Primjeri nefunkcionalnih zahtjeva

Evo praktičnih primjera nefunkcionalnih zahtjeva:

  1. Korisnici moraju promijeniti početnu lozinku nakon prve uspješne prijave, a početna lozinka se nikada ne smije ponovno koristiti.
  2. Zaposlenicima nije dopušteno ažuriranje vlastitih podataka o plaći, a svaki takav pokušaj mora se prijaviti administratoru sigurnosti.
  3. Svaki neuspješan pokušaj korisnika pristupa podatku mora se zabilježiti u revizijskom tragu.
  4. Web stranica će podržavati 20 milijuna istovremenih korisnika bez smanjenja vremena odziva.
  5. Softver mora biti prenosiv tako da prelazak s jednog operativnog sustava na drugi ne stvara probleme.
  6. Privatnost informacija, izvoz ograničenih tehnologija i prava intelektualnog vlasništva podložni su reviziji.

Funkcionalni i nefunkcionalni zahtjevi

Glavne razlike između funkcionalnih i nefunkcionalnih zahtjeva su:

Parametri Funkcionalni zahtjev Nefunkcionalni zahtjev
Što je to? Glagol Značajke
Zahtjev To je obavezno Nije obavezan
Tip hvatanja Hvata se u slučaju upotrebe. Uhvaćen je kao atribut kvalitete.
Krajnji rezultat Značajka proizvoda Svojstva proizvoda
snimanje Lako za snimanje Teško za uhvatiti
Cilj Pomaže vam provjeriti funkcionalnost softvera. Pomaže vam da provjerite učinkovitost softvera.
Područje fokusa Usredotočite se na zahtjeve korisnika Koncentrira se na očekivanja korisnika.
Dokumentacija Opišite čemu proizvod služi Opisuje kako proizvod radi
Vrsta testiranja Funkcionalno ispitivanje kao što su testiranje sustava, integracije, end-to-end, API testiranja itd. Nefunkcionalna testiranja poput testiranja performansi, stresa, upotrebljivosti, sigurnosti itd.
Izvršenje testa Izvršenje testa provodi se prije nefunkcionalnog testiranja. Nakon funkcionalnog ispitivanja
Informacije o proizvodu Značajke proizvoda Svojstva proizvoda

POVEZANI ČLANCI

Prednosti nefunkcionalnih zahtjeva

Glavne prednosti od Nefunkcionalno testiranje je:

  • Nefunkcionalni zahtjevi osiguravaju da sustav slijedi zakonska pravila i pravila usklađenosti.
  • Oni štite pouzdanost, dostupnost i performanse sustava.
  • Pružaju dobro korisničko iskustvo i jednostavnost korištenja.
  • Oni oblikuju sigurnosnu politiku softvera.

Nedostaci nefunkcionalnih zahtjeva

Uobičajeni nedostaci nefunkcionalnih zahtjeva su:

  • Nefunkcionalni zahtjevi mogu utjecati na nekoliko visokorazinskih softverskih podsustava.
  • Zahtijevaju posebnu pažnju tijekom arhitekture i dizajna na visokoj razini, što povećava troškove.
  • Implementacija se rijetko preslikava na jedan softverski podsustav.
  • Teško ih je modificirati nakon što je faza arhitekture završena.

FURPS+ model za klasifikaciju nefunkcionalnih zahtjeva

FURPS+ je najčešće korištena taksonomija za nefunkcionalne zahtjeve. Izvorno razvijena u Hewlett-Packardu, grupira atribute kvalitete u pet glavnih kategorija plus dodatna ograničenja označena znakom "+". Model pomaže poslovnim analitičarima da izbjegnu propuštanje cijele klase zahtjeva.

  • funkcionalnost: Mogućnosti, sigurnost i ponovna upotrebljivost koje nadilaze osnovni popis značajki.
  • Upotrebljivost: Ljudski faktori, estetika, dosljednost, dokumentacija i responzivnost korisničkog iskustva.
  • Pouzdanost: Raspoloživost, srednje vrijeme između kvarova, mogućnost oporavka, predvidljivost i točnost.
  • Performance: Brzina, propusnost, kapacitet, skalabilnost i potrošnja resursa pod opterećenjem.
  • Podrživost: Testabilnost, fleksibilnost, instalacija, lokalizacija i održavanje isporučenog sustava.
  • Plus (+): Dizajn, implementacija, sučelje i fizička ograničenja kao što su potrebne platforme, standardi ili hardver.

Timovi koji mapiraju svaki nefunkcionalni zahtjev u FURPS+ kategoriju imaju manje šanse isporučiti sustav koji zadovoljava značajke, ali ne zadovoljava performanse, sigurnost ili održavanje.

Kako napisati testirane nefunkcionalne zahtjeve

Dobro napisan nefunkcionalni zahtjev je mjerljiv, provjerljiv i vremenski ograničen. Nejasne izjave poput „sustav mora biti brz“ ili „aplikacija treba biti sigurna“ su težnje, a ne zahtjevi. Slijedite korake u nastavku kako biste pretvorili namjeru u testirani NFR.

  1. Odredite atribut kvalitete. Mapirajte problem u FURPS+ kategoriju kako bi tim znao radi li se o zahtjevu performansi, upotrebljivosti, sigurnosti ili pouzdanosti.
  2. Odaberite metriku. Svaki NFR treba jedinicu - milisekunde, zahtjeve u sekundi, istovremene korisnike, postotak vremena rada ili standard usklađenosti kao što je ISO 27001.
  3. Postavite numerički prag. Zamijenite „brzo“ s „ispod 400 milisekundi na 95. percentilu“. Zamijenite „vrlo dostupno“ s „99.9 posto mjesečne dostupnosti“.
  4. Opišite stanje. Navedite opterećenje, okruženje ili korisnički segment na koji se prag primjenjuje, na primjer „tijekom vrhunca prodaje s 10 000 istovremenih korisnika“.
  5. Definirajte metodu provjere. Zabilježite vrstu testa - test opterećenja, test penetracije, eksperiment kaosa, revizija pristupačnosti - i alat koji će potvrditi prag.
  6. Primijenite SMART provjeru. Potvrdite da je zahtjev specifičan, mjerljiv, ostvariv, relevantan i vremenski ograničen prije nego što uđe u zaostatak.

Primjer prepisivanja: „Sustav mora biti brz“ postaje „Stranica za naplatu mora odgovoriti za manje od 500 milisekundi na 95. percentilu s 5,000 istovremenih korisnika, što je potvrđeno od strane JMeter "testiraj opterećenje svakog izdanja." Revidirana izjava omogućuje programerima da dizajniraju za nju, testerima da je provjere, a vlasnicima proizvoda da je prihvate bez rasprave.

Pitanja i odgovori

Alati za opterećenje i performanse pokretani umjetnom inteligencijom generiraju realističan promet, otkrivaju anomalije u distribuciji vremena odziva i predviđaju ograničenja skaliranja prije produkcije. Umjetna inteligencija također pregledava zapisnike i obrasce pristupa kako bi označila sigurnosne događaje koje tradicionalni alati temeljeni na pravilima propuštaju.

Copilot i GPT pretvaraju nejasne izjave o kvaliteti u mjerljive NFR-ove s metrikom, pragom, uvjetom i metodom provjere. Poslovni analitičari pregledavaju svaki nacrt u odnosu na FURPS+ kategorije i SMART okvir prije nego što ga prihvate u zaostatak.

Funkcionalno testiranje provjerava ponašaju li se značajke ispravno, poput prijave ili pretraživanja. Nefunkcionalno testiranje mjeri koliko dobro sustav radi pod opterećenjem, stresom i korištenjem, pokrivajući ciljeve performansi, sigurnosti, upotrebljivosti, kompatibilnosti i pouzdanosti.

Skalabilnost, dostupnost, latencija, elastičnost i isplativost dominiraju NFR-ovima u oblaku. Timovi također track uočljivost, ciljevi oporavka od katastrofe kao što su RPO i RTO te usklađenost s više regija jer oni utječu na većinu odluka o arhitekturi oblaka.

Odaberite metriku s jedinicom, postavite numerički prag, opišite uvjet pod kojim se primjenjuje i navedite metodu provjere. Na primjer, vrijeme odziva ispod 400 milisekundi na 95. percentilu s 5,000 korisnika, provjereno od strane JMeter.

Šifriranje podataka u mirovanju i u prijenosu, snaga autentifikacije, autorizacija temeljena na ulogama, zapisivanje revizije, istek vremena sesije i usklađenost sa standardima kao što su ISO 27001, PCI DSS i GDPR su sigurnosni NFR-ovi koje većina timova dokumentira.

Korištenje nejasnih pridjeva, izostavljanje metrike ili uvjeta, navođenje NFR-ova tek na kraju projekta i kopiranje standardnih shema koje nijedan test ne može provjeriti najčešće su pogreške koje dovode do prerade arhitekture u kasnoj fazi.

NFR-ovi se nalaze u Specifikaciji softverskih zahtjeva, zapisima o arhitekturnim odlukama, ugovorima o razini usluge i kontrolnim listama za definiciju dovršenog. Agilni timovi često pridružuju mjerljive NFR-ove epskim ciljevima i definiciji spremnosti za svaku korisničku priču.

Sažmite ovu objavu uz: