Při vývoji jakéhokoli nového informačního systému (nebo zavedení stávajícího) se odborníci nutně ve své práci potýkají s potřebou stanovit tento typ požadavků. Je rozumné je podrobněji zvážit. Jaké jsou nefunkční požadavky, jaké jsou podle odborníků.

Dvě kategorie požadavků

Požadavky na vlastnosti, kvalitu softwarových produktů, informační systémy jsou velké. Mohou se však rozdělit na dvě široké kategorie - funkční a nefunkční. Na začátku článku je důležité rozlišovat mezi nimi. Takže:

Funkční požadavky. Popište, co přesně je třeba implementovat v konkrétním systému nebo produktu, které by měly být prováděny uživateli v souvislosti s tímto vývojem.

Nefunkční požadavky. Popište, jak vytvořený systém nebo softwarový produkt funguje, jaké vlastnosti a vlastnosti mají konkrétní vývoj.

Bod 1. Koncepce funkčních a nefunkčních požadavků, které jsme vytvořili. Nyní přejděme k druhému bodu - pojďme zvážit, co přesně může být přičítáno druhému.

Jaká je kategorie?

Požadavky na funkce v podstatě zahrnují především různé atributy kvality výrobku. Konkrétně - požadavky, které určují kvalitativní charakteristiky vývoje (software, informační systém). To je samozřejmě spolehlivost, škálovatelnost, výkon produktu. Nicméně následující jsou velmi důležitéNefunkční požadavky:

Omezení. To znamená podmínky, které omezují výběr jakýchkoli rozhodnutí o implementaci určitých požadavků (nebo souborů požadavků). Omezují různé možnosti nástrojů, strategií, nástrojů při vývoji struktury (architektury) a vzhledu informačního produktu softwarového produktu.

Obchodní pravidla. Patří sem směrnice, zásady, zásady, předpisy, které nějak omezují určité aspekty podnikání. Mohou například stanovit složení a pravidla pro provádění jakýchkoli obchodních projektů. Co lze přiřadit této kategorii? Podniková politika, všechny druhy vládních vyhlášek a vyhlášek, průmyslové standardy, výpočetní algoritmy. Veškerá pravidla, která ovlivňují vývoj systému, produktu, se používají při práci na projektu.

Návrhy na provedení. Skupina obsahuje konkrétní návrhy, které hodnotí proveditelnost použití určitých architektonických a technologických řešení.

Externí rozhraní. Popis klíčových aspektů interakce produktu s jinými systémy a provozním prostředím. Především se jedná o požadavky na systém nebo produkt API, stejně jako požadavky rozhraní API jiných systémů, o kterých se předpokládá, že budou integrovat vývojový produkt.

Návrhy na testování, testování vyvinutého softwaru. Jedná se o řadu dodatků k požadavkům, které uvádějí, jak lze v praxi ověřit jeden či jiný požadavek.

Právní požadavky. Licencování produktů, dostupnost patentu apod.

Je důležité poznamenat, že nefunkční systémové požadavkypředdefinované a pevné. Pouze tehdy může odborník začít vyvíjet produkt.

Požadavky Příklady

Pro jasnější představu nefunkčních požadavků na informační systém, se na některé příklady:

omezení. "Tento vývoj se provádí pouze na platformě dodavatele X". "Při autentizaci uživatele v informačním systému by se měly používat pouze biometrické identifikační techniky."

Obchodní pravidla. "Při předání produktu je manažer povinen požádat účetního o fakturu podnikové faktury a zaslání a zaslání faktur." "Objednávka bude zrušena, pokud dodavatel neobdrží platbu na účet do 14 dnů."

Externí rozhraní. "Zajistěte protokolování operačního systému takových událostí: zpráva o službě start a stop X." „Pro zajištění vstupu protokolu datových parametrů programových modulů:. Jádrem, skener, antivirové databáze Informace musí být zapsána do protokolu při spuštění a obnovení jeho moduly.“

Jak stanovit tyto požadavky?

Analyzovali jsme konkrétní příklady funkčních požadavků. A teď je další důležitá otázka: "Jak je identifikovat s ohledem na konkrétní produkt?"
V první řadě odborníci vypracují šablonu, v níž jsou uvedeny hlavní typy nefunkčních požadavků na výrobek. Především je nutné, abychom neztratili žádnou pozici z tohoto seznamu. Vývojáři obvykle vybírají zdroje pro kreslení podobných šablon

GOST (státní norma Ruské federace) 34. série.

Kniha "Vývoj softwarových požadavků" (K. Wigers). Zvláště je třeba věnovat pozornost části "Příloha G". Obsahuje konkrétní příklady požadavků na dokumentaci.

Podívejme se nyní na to, kdo se touto prací konkrétně zabývá.

Definice požadavků na produkt

Zvláštní pracovní skupiny se podílejí na vývoji funkčních a nefunkčních požadavků na systém. Jejich členové určují nejen tyto předpisy, ale také kontrolují a schvalují.
Pokud jde o nefunkční kategorii, je důležité zapojit nejen uživatele a analytiky, ale také vývojáři klíčových produktů, systémových architektů a také skupinu testerů pro jeho definici. Proč je to důležité? Architekt, řekněme, vnímá nefunkční požadavky jako vstupy pro výběr a návrh architektury programu. Testovací tým plánuje pro ně vhodné scénáře zatěžovacích testů. Prostřednictvím tohoto systému se kontrolují požadavky na výkonnost. Celkově se to týká atributů kvality.

Úloha účastníků pracovní skupiny

Zvažme, jaké role jsou sdíleny mezi členy týmu, kteří definují a schvalují nefunkční požadavky na produkt:

Uživatelé. Tito účastníci hodnotí parametry, které určují nefunkční požadavky.

Systémový analytik. Tento účastník shromažďuje, analyzuje,systematizuje a dokumentuje nefunkční požadavky.

Klíčové vývojáři a systémový architekt. Jakou roli hraje tato skupina? Podílet se na identifikaci, analýze non-funkční požadavky a testovat je na stupni plnění.

Zkušební skupina. Rovněž se podílí na definici a analýze seznamu nefunkčních požadavků programu. Navíc vyvíjí zkušební scénáře pro tyto předpisy.

script pro určení požadavků

Zde máme dát konkrétní příklad skriptu, který se používá ke stanovení funkční požadavky na výkon modulu, který je určen pro odesílání zpráv pro uživatele on-line e-maily prostředků:

Systém obdrží signál o události a iniciuje zasílání elektronických zpráv.

umožňuje posílání zpráv do svého seznamu a pomocí této šablony B. Pro zasílání zpráv pomocí služby Art.

Nesplnění operační systém umožňuje dodávky znovu zprávy.

Vytvoření požadavků na výrobky scénáře

Nyní petici bylo zjištěno při předchozím skriptu podtitulem:

Požadavky na čase oznámení o události, která začíná odesílání zpráv, systém musí dostávat upozornění na události zahájení novinek nejpozději X minut po jeho vzniku.

Požadavky na posílání časových zpráv: zpráva musí být zaslány do systému během několika sekund po obdržení událost signálu.

Požadavky na opakované odeslání zpráv v případě neúspěšného pokusu: počet pokusů by měl být X. Interval - X minut od každého neúspěšného odeslání zpráv.

Kritéria důležitých požadavků

Většina nefunkčních požadavků musí přesně splňovat řadu kvalitativních kritérií k jejich obsahu:

Úplnost (jako samostatný požadavek a jejich úplný seznam). Co to znamená? Žádost musí obsahovat všechny potřebné informace pro její realizaci.

Jednoznačné. Požadavek by neměl být v rozporu se samotnými nebo jinými položkami v seznamu. Všichni profesionálové, kteří s ním pracují, by měli rozumět stejným způsobem.

Správnost samostatného požadavku, který zajišťuje systémovou konzistenci.

Nutnost. Realizace tohoto požadavku je pro uživatele skutečně nezbytná.

Uskutečnitelnost. Uvědomte si tento požadavek na život.

Ověřitelnost. Je nutné zajistit jednoznačné ověření jeho provádění.

Zjistili jsme takový koncept jako nefunkční požadavky na softwarový produkt, informační systém. Rovněž rozložili své konkrétní příklady, na rozdíl od funkční kategorie, kritéria kvality kategorie. Víte, které skupiny odborníků vytvářejí a schvalují tyto předpisy.