NFR: Nefunkční požadavky

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.