Komix » Co je nového » Co je nového a média » NFR: Nefunkční požadavky

NFR: Nefunkční požadavky

NFR: Nefunkční požadavky

Už jste se setkali někdy s pojmem NFR (non-functional requirements)?  Jsou to požadavky na systém, které se netýkají přímo jeho byznysové funkcionality.

O co jde, si můžeme ukázat na následujícím případu. Zákazník chce, abyste mu udělali aplikaci, která umožní uživateli vyplnit formulář. Většinou přijde s tím, že formulář by měl mít určitý název a měl by obsahovat tu a tu položku, která by se měla vybrat z číselníku. Po zadání a odeslání formuláře by se mělo spočítat toto a tamto, a nakonec by se měl poslat email. Tak přesně to, co vám nadiktoval, jsou funkční požadavky. Vy ale musíte zajistit, že software bude splňovat i další věci, které nevyslovil. A to jsou právě ty NFR. V dalším textu budu používat raději zkratku. Překlad “Nefunkcionální požadavky” mi přijde poněkud krkolomný a pojem „nefunkční požadavky“ pro změnu evokuje mírně jiný význam.

Držme se ale našeho případu. NFR budou požadavky na systém typu, že formulář může vyplnit jen oprávněný uživatel, kterého jste poučili o tom, jaké údaje se o něm uchovávají. Že se k zadaným datům nedostane nikdo neoprávněný. Že zadání formuláře bude dostatečně uživatelsky přívětivé, aby s ním vůbec chtěl někdo pracovat. Že načtení formuláře nebude trvat neskutečně dlouhou dobu, během které to uživatel vzdá a odejde.  A takových „že“ existuje mnohem více. Někdy už vás na ně zákazník upozorní sám. Jindy si je musíte vydedukovat na základě vašich zkušeností a čtením mezi řádky v dodaných požadavcích.

Typy NFR

Některé NFR se navzájem prolínají a určitě budete váhat, do které kategorie je zařadit. To ale není cílem. Berte proto následující seznam jako návod, jak na něco nezapomenout, spíše než jako téma k filozofickým diskuzím, co kam patří. Pokud se podíváte na heslo “Non-functional requirement” na Wikipedii, vypadne jich na vás více než šedesát.

NFR se dají rozdělit do oblastí podle účelu:

Accessibility

Přístupnost, ovladatelnost – v tomto kontextu se jedná o možnost ovládat systém nebo jeho prvky i pro tělesně nebo mentálně hendikepované uživatele.

Příklad: Písmo si bude moci uživatel zvětšit na požadovanou velikost.

Availability

Dostupnost – jak zajistit, aby byl systém pro uživatele dostupný v požadovaném rozsahu. Udává se v procentech z určeného času.

Příklad: 99,95% času za měsíc.

Capacity

Kapacita – udává množství, které je schopný určitý zdroj obhospodařit.

Příklad: Příchozí data za den zaberou 1GB prostoru na HD.

Compatibility

Vzájemná slučitelnost

Příklad: Nová služba umožní připojení i aplikacím, které používají současnou verzi rozhraní, bez toho, aby tyto aplikace musely být změněny.

Cost

Cena/náklady – k tomuto NFR asi není příliš co dodávat. Budete ho řešit se zákazníkem na každé zakázce a určitě ho ani jedna strana neopomene alespoň rámcově probrat předtím, než se začne projekt pořádně vyvíjet.

Příklad: Cena projektu, modulu, aplikace, hodiny času člověka, …

Data Integrity

Integrita dat – jak zajistit, že data budou správná, konzistentní a nebude docházet k jejich nechtěným změnám.

Příklady:

• Aktuální data budou dostupná uživatelům do patnácti minut.

• Každá změna záznamu v databázi bude logovaná.

• Přijímaná data se budou kontrolovat pomocí kontrolního součtu.

Deployment

Nasazování aplikace – proces, jak aplikaci nasadit pro použití na jednotlivých prostředích. Do tohoto bodu patří i témata jako odinstalace, verzování, případná aktivace a deaktivace software, updatování nainstalované verze a podobně.

Příklady:

• Každý pátek v 18:00 bude probíhat pravidelný release pomocí continuous integration definované v TFS.

• Po každém commitu kódu do větve development se automaticky z této větve nasadí aplikace na testovací prostředí.

Environmental

Přírodní vlivy, vlivy okolí – jak reagovat na vlivy okolního prostředí.

Příklady:

• Komunikace v rámci systému bude řešena bezdrátově na dlouhé vzdálenosti. Kvalitu komunikace může ovlivnit počasí.

• Čidla systému budou po několik let vystaveny vysokým teplotám a vlhkosti.

• Musí být systém v provozu 24/7 nebo to není například v noci vůbec potřeba.

Extensibility

Rozšiřitelnost – Jak navrhnout systém, aby byl do budoucna snadno rozšiřitelný o novou funkcionalitu.

Příklady:

• Systém bude umožňovat instalaci pluginů třetích stran.

• Aplikace se bude skládat z jednotlivých modulů, které spolu budou komunikovat pomocí daných rozhraní.

Fault tolerance

Odolnost vůči chybám – vlastnost systému fungovat nadále správně i v případě výskytu chyby nebo nefunkčnosti některé jeho části.

Příklady:

• Operace bude probíhat v rámci transakce, aby se v případě chyby byla aplikace schopná vrátit zpět do konzistentního stavu.

• V případě výpadku internetového spojení umožní aplikace uživateli pracovat nadále. Jím zadaná data bude ukládat a na server je odešle při nejbližší přílež

Interoperability

Spolupráce – schopnost různých systémů vzájemně spolupracovat poskytovat si služby nebo dosáhnout vzájemné součinnosti.

Příklad: Vystavené rozhraní bude realizováno pomocí protokolu SOAP

Maintainability

Udržovatelnost – snadnost s jakou je možné v software najít chybu a opravit ji.

Příklad: Chyba včetně svého podrobného popisu bude zalogována.

Manageability

Spravovatelnost – jednoduchost s jakou je možné monitorovat systé Jak je aplikace schopná poskytovat klíčové informace pro analýzu a porozumění příčinám problémů. Je to schopnost udržovat systém efektivní a plně provozuschopný.

Příklad: Pomocí vhodného nástroje bude monitorováno průběžné využití paměti nasazenou aplikací.

Performance

Výkon – jak rychle systém reaguje na uživatelské akce za určitých podmínek.

Příklad: Odezva zobrazení úvodní webové stránky při současném přístupu tisíc uživatelů do systému bude maximálně 0,5 sekundy.

Recoverability

Obnovitelnost – jak co nejrychleji uvést systém do požadovaného stavu.

Příklady:

• Možnost obnovení databáze ze zálohy.

• Umožnit návrat k předchozím hodnotám.

• Postup rozběhnutí systému při jeho havárii.

Regulatory/Compliance

Právní požadavky – jedná se o zákony, vyhlášky, normy, ale i v širším smyslu třeba běžně používané a očekávané standardy, které mají na systém vliv i když neurčují konkrétní funkcionality.

Příklady:

• GDPR

• Požadavky vyplývající z lokalizace

Reliability

Spolehlivost – jak často se v systému objevují chyby a jaké opatření zvolit, aby se jejich výskyt zamezil nebo alespoň minimalizoval.

Příklad: Každou noc bude probíhat diagnostika systému, aby byly v čas odhaleny hrozící chyby. Například vadný harddisk.

Reusability

Znovupoužitelnost – možnost znovu používat již hotové části.

Příklad: Pro kontrolu uživatelských oprávnění bude vyvinuta obecná komponenta, kterou budou ve svých aplikacích následně používat všichni dodavatelé.

Scalability

Škálovatelnost, rozšiřitelnost – jak systém nastavit, aby zvládl zvyšování zátěže.

Příklady:

• Systém bude umožňovat provoz na serverové farmě, do které bude možné přidat další servery pro zrychlení vyřizování uživatelských požadavků.

• O víkendech a svátcích, kdy nejsou stránky aplikace navštěvovány, bude provoz systému utlumen, aby nebyly zbytečně spotřebovávány nevyužité

Security

Bezpečnost – jak je systém chráněn proti případným útokům nebo jiným ohrožením.

Příklad: Bude navrženo monitorování běhu systému a jeho pravidelné vyhodnocování, aby se s předstihem odhalily nestandardní události a mohlo se na ně včas reagovat.

Serviceability

Servisovatelnost – jak snadno je možné v systému provést servis.

Příklad: Jak často a jestli vůbec je možné provádět plánované odstávky.

Jak bude zajištěn upgrade na novou verzi systému nebo oprava chyb v aplikaci. Pocítí to nějak uživatelé?

Testability

Testovatelnost – míra s jakou systém umožňuje být testován.

Příklady:

• Uživatelské rozhraní bude napsané tak, aby bylo možné ho otestovat pomocí automatických testů.

• Ke každé komponentě bude napsán popis definující jasně její chování a funkcionalitu.

• Byznys logika aplikace bude umístěna do odděleného modulu s definovaným rozhraním, aby bylo možné přes toto rozhraní otestovat správnou funkčnost jednotlivých metod.

Usability

Použitelnost – důraz je kladený na ovladatelnost aplikace uživatelem a snadnost pochopení práce se systémem.

Příklad: Možnost procházení polí formuláře pomocí tabulátoru

Přínosy NFR

• Nefunkční požadavky zajišťují, aby softwarový systém dodržoval zákonná pravidla a shodu se standardy, specifikací ale i třeba s firemní politikou.

• Zajišťují spolehlivost, dostupnost a výkonnost softwarového systému.

• Zajišťují dobrý uživatelský komfort a snadné ovládání softwaru.

• Pomáhají při formulování bezpečnostní politiky softwarového systému.

Omezení plynoucí z NFR

• NFR ovlivňují systém již na vyšší úrovni pohledu na něj a implementace není většinou spojena s konkrétní částí vyvíjeného systé Pro vás z toho plyne, že například budete řešit dostupnost, zabezpečení, uživatelskou přívětivost… apod. v rámci celého systému a ne jen jedné obrazovky.

• Z hlediska architektury se musí NFR zohlednit už na začátku návrhu systému, protože většinou prostupují celou aplikací a netýkají se jen její omezené části. To samozřejmě zvyšuje nároky na návrh a tím i náklady. Opravdu si proto vše na začátku pořádně promyslete. Jakmile projdete fází architektury, je už obtížné návrh NFR upravovat.

Ověření splnění NFR

Stejně jako požadavky na funkcionalitu, tak i NFR se dají testovat. Jde jen o správnou volbu kritérií, která chcete ověřit. Obor testování k tomu má i své kategorie testů. Asi nejznámějšími jsou výkonové a zátěžové testy, stress testy a testy bezpečnosti aplikace, z nichž nejčastější jsou testy penetrační.

Závěrem: Chodí to dobře,  ale neseje to

Dovolil jsem si vypůjčit hlášku z filmu. Prakticky stejného výsledku ale docílíte, když splníte funkční požadavky a opominete NFR.  V obou případech budete mít systém, který je nepoužitelný. Jen to v druhém případě bude kvůli pomalosti, nedostupnosti, zabezpečení, složitému vyplňování údajů, anebo kdovíčemu jinému.

Autorem článku je Miroslav Kopecký, Head of .NET Department

Sdílet
Analýza výhledu cash flow

Analýza výhledu cash flow

Maximalizace objemu vymožených pohledávek

Maximalizace objemu vymožených pohledávek