Co je nefunkční požadavek v softwarovém inženýrství?

Od: Charles Moore Charles Moore
Hours aktualizováno

⚡ Chytré shrnutí

Nefunkční požadavky specifikují atributy kvality, jako je výkon, bezpečnost, použitelnost, spolehlivost, škálovatelnost a přenositelnost, definují, jak dobře se musí softwarový systém chovat, a mění vágní očekávání na měřitelné, testovatelné a vymahatelné inženýrské cíle v průběhu celého životního cyklu dodávky.

  • 📘 Definice: Nefunkční požadavek neboli NFR popisuje, jak dobře si systém vede z hlediska výkonu, zabezpečení, použitelnosti, spolehlivosti a přenositelnosti.
  • 🗂️ Běžné typy: Použitelnost, bezpečnost, spolehlivost, škálovatelnost, kapacita, dostupnost, udržovatelnost a shoda s předpisy jsou kategorie týmů. track nejčastěji.
  • 📊 Model FURPS+: FURPS+ seskupuje NFR podle funkčnosti, použitelnosti, spolehlivosti, výkonu, podporovatelnosti a konstrukčních nebo rozhraní.
  • 🎯 Testovatelné příkazy: Nahraďte slova „rychlý“ nebo „bezpečný“ číselnými prahovými hodnotami a ověřovacími metodami, aby bylo možné NFR otestovat a přijmout.
  • 🆚 Funkční kontrast: Funkční požadavky uvádějí, co systém dělá; nefunkční požadavky uvádějí, jak dobře to systém dělá v reálných podmínkách.
  • (Tj. Obchodní dopad: Chybějící NFR jsou hlavní příčinou produkčních incidentů, regulačních zjištění a nákladných pozdějších fází přepracování architektury.
Přečíst více

Nefunkční požadavky v softwarovém inženýrství

Co je to nefunkční požadavek?

A Nefunkční požadavek (NFR) specifikuje atribut kvality softwarového systému. NFR posuzují systém na základě responzivity, použitelnosti, zabezpečení, přenositelnosti a dalších atributů kvality, které jsou klíčové pro úspěch. Běžným příkladem nefunkčního požadavku je, "Jak rychle se web načítá?" Nesplnění nefunkčních požadavků vytváří systémy, které uživatele frustrují.

Nefunkční požadavky v softwarovém inženýrství kladou omezení na návrh systému v rámci agilního backlogu. Například web by se měl načíst do tří sekund, když počet souběžných uživatelů překročí 10 000. Popis nefunkčních požadavků je stejně důležitý jako zachycení funkčních požadavků.

Typy nefunkčních požadavků

Hlavní kategorie nefunkčních požadavků jsou:

Typy nefunkčních požadavků

Typy nefunkčních požadavků

  • Použitelnost
  • Spolehlivost
  • Ovladatelnost
  • Obnovitelnost
  • Bezpečnost
  • Data Integrity
  • Kapacita
  • dostupnost
  • Škálovatelnost
  • Interoperabilita
  • Spolehlivost
  • Udržitelnost
  • Soulad s předpisy
  • Environmentální omezení

Příklady nefunkčních požadavků

Zde jsou praktické příklady nefunkčních požadavků:

  1. Uživatelé musí po prvním úspěšném přihlášení změnit původní heslo a původní heslo nesmí být nikdy znovu použito.
  2. Zaměstnanci nesmí aktualizovat informace o svém vlastním platu a jakýkoli takový pokus musí být nahlášen správci bezpečnosti.
  3. Každý neúspěšný pokus uživatele o přístup k datové položce se zaznamená do auditní stopy.
  4. Webové stránky by měly podporovat 20 milionů souběžných uživatelů bez zhoršení doby odezvy.
  5. Software by měl být přenositelný, aby přechod z jednoho operačního systému na druhý nezpůsoboval žádné problémy.
  6. Ochrana informací, vývoz omezených technologií a práva duševního vlastnictví musí být auditovatelné.

Funkční vs. nefunkční požadavky

Hlavní rozdíly mezi funkčními a nefunkčními požadavky jsou:

parametry Funkční požadavek Nefunkční požadavek
Co je to? Sloveso Atributy
Požadavek Je to povinné Není to povinné
Typ snímání Je zachycen v případě použití. Je zachycen jako atribut kvality.
Konečný výsledek Funkce produktu Vlastnosti produktu
Zachycení Snadno zachytitelné Těžko zachytitelné
Objektivní Pomáhá vám ověřit funkčnost softwaru. Pomáhá vám ověřit výkon softwaru.
Oblast zaměření Zaměřte se na požadavky uživatele Soustředí se na očekávání uživatele.
Dokumentace Popište, co produkt dělá Popisuje, jak produkt funguje
Typ testování Funkční testování jako je systémové, integrační, komplexní testování, testování API atd. Nefunkční testování, jako je výkon, stres, použitelnost, testování zabezpečení atd.
Provedení testu Test Provedení se provádí před nefunkčním testováním. Po funkční zkoušce
Informace o výrobku Vlastnosti produktu Vlastnosti produktu

SOUVISEJÍCÍ ČLÁNKY

Výhody nefunkčních požadavků

Hlavní výhody Nefunkční testování jsou:

  • Nefunkční požadavky zajišťují, aby systém dodržoval právní předpisy a předpisy.
  • Chrání spolehlivost, dostupnost a výkon systému.
  • Nabízejí dobrý uživatelský zážitek a snadnou obsluhu.
  • Formují bezpečnostní politiku softwaru.

Nevýhody nefunkčních požadavků

Mezi běžné nevýhody nefunkčních požadavků patří:

  • Nefunkční požadavky mohou ovlivnit několik softwarových subsystémů vysoké úrovně.
  • Vyžadují zvláštní pozornost během architektury a návrhu na vysoké úrovni, což zvyšuje náklady.
  • Implementace se zřídka mapuje na jediný softwarový subsystém.
  • Jakmile je fáze architektury dokončena, je těžké je modifikovat.

Model FURPS+ pro klasifikaci nefunkčních požadavků

FURPS+ je nejpoužívanější taxonomie pro nefunkční požadavky. Původně byla vyvinuta ve společnosti Hewlett-Packard a seskupuje atributy kvality do pěti hlavních kategorií a dále doplňuje omezení označená znaménkem „+“. Model pomáhá obchodním analytikům vyhnout se přehlédnutí celé třídy požadavků.

  • Funkce: Možnosti, zabezpečení a opakovaná použitelnost, které jdou nad rámec základního seznamu funkcí.
  • Použitelnost: Lidské faktory, estetika, konzistence, dokumentace a responzivita uživatelského prostředí.
  • Spolehlivost: Dostupnost, průměrná doba mezi poruchami, obnovitelnost, předvídatelnost a přesnost.
  • Výkon: Rychlost, propustnost, kapacita, škálovatelnost a spotřeba zdrojů při zátěži.
  • Podporovatelnost: Testovatelnost, flexibilita, instalovatelnost, lokalizovatelnost a udržovatelnost dodaného systému.
  • Plus (+): Návrh, implementace, rozhraní a fyzická omezení, jako jsou požadované platformy, standardy nebo hardware.

Týmy, které mapují každý nefunkční požadavek do kategorie FURPS+, s menší pravděpodobností dodají systém, který sice splňuje funkce, ale selhává ve výkonu, zabezpečení nebo udržovatelnosti.

Jak psát testovatelné nefunkční požadavky

Dobře napsaný nefunkční požadavek je měřitelný, ověřitelný a časově omezený. Vágní tvrzení jako „systém musí být rychlý“ nebo „aplikace by měla být bezpečná“ jsou aspirace, nikoli požadavky. Postupujte podle níže uvedených kroků a převeďte záměr do testovatelné NFR.

  1. Identifikujte atribut kvality. Zařaďte problém do kategorie FURPS+, aby tým věděl, zda se jedná o požadavek na výkon, použitelnost, bezpečnost nebo spolehlivost.
  2. Vyberte metriku. Každý NFR potřebuje jednotku – milisekundy, požadavky za sekundu, souběžné uživatele, procentuální dostupnost nebo standard shody, jako je ISO 27001.
  3. Nastavte číselnou prahovou hodnotu. Nahraďte „rychlý“ za „méně než 400 milisekund na 95. percentilu“. Nahraďte „vysoce dostupný“ za „99.9% měsíční dostupnost“.
  4. Popište stav. Uveďte zátěž, prostředí nebo segment uživatelů, na který se prahová hodnota vztahuje, například „během špičky prodeje s 10 000 souběžnými uživateli“.
  5. Definujte metodu ověřování. Všimněte si typu testu – zátěžový test, penetrační test, experiment chaosu, audit přístupnosti – a nástroje, který prahovou hodnotu potvrdí.
  6. Použijte kontrolu SMART. Před zařazením do nevyřízených záležitostí ověřte, zda je požadavek specifický, měřitelný, dosažitelný, relevantní a časově ohraničený.

Příklad přepsání: „Systém musí být rychlý“ se změní na „Stránka pokladny musí reagovat za méně než 500 milisekund na 95. percentilu s 5 000 souběžnými uživateli, ověřenými JMeter „zátěžové testování každé verze.“ Revidované prohlášení umožňuje vývojářům navrhovat pro danou verzi, testerům ji ověřit a vlastníkům produktů ji přijmout bez námitek.

Nejčastější dotazy

Nástroje pro měření zátěže a výkonu poháněné umělou inteligencí generují realistický provoz, detekují anomálie v rozložení doby odezvy a předpovídají limity škálování před spuštěním. Umělá inteligence také kontroluje protokoly a vzory přístupu, aby označila bezpečnostní události, které tradiční nástroje založené na pravidlech přehlížejí.

Copilot a GPT převádějí vágní prohlášení o kvalitě na měřitelné NFR s metrikami, prahovými hodnotami, podmínkami a ověřovacími metodami. Obchodní analytici před přijetím do backlogu kontrolují každý návrh podle kategorií FURPS+ a rámce SMART.

Funkční testování kontroluje, zda se funkce, jako je přihlášení nebo vyhledávání, chovají správně. Nefunkční testování měří, jak dobře systém funguje při zátěži, stresu a používání, a zahrnuje výkon, bezpečnost, použitelnost, kompatibilitu a spolehlivost.

Cloudovým NFR dominují škálovatelnost, dostupnost, latence, elasticita a nákladová efektivita. Týmy také... tracpozorovatelnost k, cíle pro zotavení z havárie, jako jsou RPO a RTO, a dodržování předpisů pro více regionů, protože ty ovlivňují většinu rozhodnutí o cloudové architektuře.

Vyberte metriku s jednotkou, nastavte číselnou prahovou hodnotu, popište podmínku, za které se použije, a pojmenujte metodu ověření. Například doba odezvy pod 400 milisekund na 95. percentilu s 5 000 uživateli, ověřeno JMeter.

Šifrování dat v klidovém stavu i při přenosu, síla ověřování, autorizace na základě rolí, protokolování auditu, časový limit relace a dodržování standardů, jako jsou ISO 27001, PCI DSS a GDPR, jsou bezpečnostní NFR, které většina týmů dokumentuje.

Používání vágních přídavných jmen, vynechávání metriky nebo podmínky, uvádění NFR až na konci projektu a kopírování a vkládání standardního textu, který žádný test nedokáže ověřit, jsou nejčastějšími chybami, které vedou k přepracování architektury v pozdní fázi.

NFR se nacházejí ve specifikaci softwarových požadavků, záznamech o rozhodnutích o architektuře, dohodách o úrovni služeb a kontrolních seznamech definic hotových úkolů. Agilní týmy často připojují měřitelné NFR k epickým úkolům a k definici připravenosti pro každý uživatelský příběh.

Shrňte tento příspěvek takto: