Nefunkčné systémové požiadavky: koncepty a príklady

Pri vývoji akéhokoľvek nového informačného systému (alebo zavedenia existujúcich) sa odborníci nevyhnutne stretnú pri svojej práci s potrebou určiť tento druh požiadaviek. Je zmysluplné ich detailne zvážiť. Aké sú nefunkčné požiadavky, ktoré sú podľa odborníkov.

Dve kategórie požiadaviek

Požiadavky na vlastnosti, kvalitu softvérových produktov, informačné systémy sú veľké. Môžu sa však rozdeliť do dvoch širokých kategórií - funkčných a nefunkčných požiadaviek. Na začiatku článku je dôležité rozlišovať medzi nimi. Takže:
  • Funkčné požiadavky. Opíšte, čo presne je potrebné implementovať v konkrétnom systéme alebo produkte, aké kroky by mali vykonať používatelia v súvislosti s týmto vývojom.
  • Nefunkčné požiadavky. Opíšte, ako funguje vytvorený systém alebo softvérový produkt, aké vlastnosti a charakteristiky majú špecifický vývoj.
  • Položka 1. Koncept funkčných a nefunkčných požiadaviek, ktoré sme vytvorili. Teraz prejdime k druhému bodu - uvažujme, čo presne môže byť pripisované druhej.


    Aká je kategória?

    Požiadavky na funkčnosť v podstate zahŕňajú najmä rôzne atribúty kvality výrobku. Konkrétne - požiadavky, ktoré určujú kvalitatívne charakteristiky vývoja (softvér, informačný systém). To je samozrejme spoľahlivosť, škálovateľnosť, výkonnosť produktu. Avšak nasledujúce sú veľmi dôležiténefunkčné požiadavky:
  • Obmedzenia. To znamená podmienky, ktoré obmedzujú výber akýchkoľvek rozhodnutí o vykonávaní určitých požiadaviek (alebo súborov požiadaviek). Zúžia rôzne možnosti nástrojov, stratégií, nástrojov pri vývoji štruktúry (architektúry) a vzhľadu informačného produktu softvérového produktu.
  • Obchodné pravidlá. Patria sem smernice, zásady, zásady, predpisy, ktoré nejako obmedzujú určité aspekty podnikania. Napríklad môžu určiť zloženie a pravidlá vykonávania akýchkoľvek obchodných projektov. Čo možno pripísať tejto kategórii? Podniková politika, všetky druhy vládnych dekrétov a dekrétov, priemyselné štandardy, výpočtové algoritmy. Všetky pravidlá, ktoré ovplyvňujú vývoj systému, produktu, sa používajú pri práci na projekte.
  • Návrhy na vykonanie. Skupina obsahuje konkrétne návrhy, ktoré hodnotia realizovateľnosť použitia určitých architektonických a technologických riešení.
  • Externé rozhrania. Opis kľúčových aspektov interakcie výrobku s inými systémami a prevádzkovým prostredím. Po prvé, ide o požiadavky na systém alebo produkt API, ako aj požiadavky API iných systémov, ktoré sa plánujú integrovať vývojový produkt.
  • Návrhy na testovanie, testovanie vyvinutého softvéru. Ide o sériu dodatkov k požiadavkám, v ktorých sa uvádza, ako treba v praxi overiť jednu alebo druhú požiadavku.
  • Právne požiadavky. Licencia produktov, dostupnosť patentu atď.
  • Je dôležité poznamenať, že nefunkčné systémové požiadavkypreddefinované a pevné. Len potom môže špecialista začať s vývojom produktu.


    Príklady požiadaviek

    Aby sme získali jasnejšiu predstavu o nefunkčných požiadavkách informačného systému, zvážte niekoľko príkladov:
  • Obmedzenia. "Tento vývoj sa uskutočňuje iba na platforme dodávateľa X". "Pri overovaní používateľa v informačnom systéme by sa mali používať iba biometrické identifikačné techniky."
  • Obchodné pravidlá. "Pri dodávaní produktu je manažér povinný požiadať účtovníka o faktúru podniku a faktúry za dodanie a zasielanie." "Objednávka bude zrušená, ak dodávateľ nedostane platbu na účet do 14 dní."
  • Externé rozhrania. "Zabezpečte, aby sa zaznamenal operačný systém takýchto udalostí: správa o službe štart a stop X." "Uistite sa, že protokol programu je zapísaný do parametrov údajov programu: jadro, skener, antivírusová databáza a informácie by sa mali zadávať v protokole pri spustení aj pri obnovovaní jeho modulov."
  • Ako stanoviť tieto požiadavky?

    Analyzovali sme konkrétne príklady funkčných požiadaviek. A teraz je ďalšia dôležitá otázka: "Ako ich identifikovať s ohľadom na konkrétny produkt?"
    Predovšetkým experti vytvoria šablónu, v ktorej sú uvedené hlavné typy nefunkčných požiadaviek na výrobok. Najprv je potrebné, aby sa z tohto zoznamu nevyhýbalo žiadnej pozícii. Vývojári zvyčajne vyberajú zdroje na kreslenie podobných šablón
  • GOST (štátna norma Ruskej federácie) 34. séria.
  • Kniha "Vývoj softvérových požiadaviek" (K. Wigers). Najmä je potrebné venovať pozornosť časti "Príloha G". Obsahuje špecifické príklady požiadaviek na dokumentáciu.
  • Pozrime sa teraz na to, kto sa práve zaoberá touto prácou.

    Vymedzenie požiadaviek na výrobky

    Špeciálne pracovné skupiny sa podieľajú na vývoji funkčných a nefunkčných požiadaviek na systém. Ich členovia určujú nielen, ale aj kontrolujú, schvaľujú tieto predpisy.
    Čo sa týka nefunkčnej kategórie, je dôležité zapojiť nielen používateľov a analytikov, ale aj kľúčových vývojárov produktov, systémových architektov, ako aj skupinu testerov na jeho definíciu. Prečo je to dôležité? Architekt, povedzme, vníma nefunkčné požiadavky ako vstupy pre výber a návrh architektúry programu. A testovací tím plánuje pre ňu vhodné scenáre nakladania. Prostredníctvom tohto systému sa kontrolujú výkonové požiadavky. Celkovo sa to týka atribútov kvality.

    Úlohy účastníkov pracovnej skupiny

    Zvážme, aké úlohy sa delia medzi členov tímu, ktorí definujú a schvaľujú nefunkčné požiadavky na produkty:
  • Používatelia. Títo účastníci hodnotia hodnoty parametrov, ktoré určujú nefunkčné požiadavky.
  • Systémový analytik. Tento účastník zhromažďuje, analyzuje,systematizuje a dokumentuje nefunkčné požiadavky.
  • Kľúčoví vývojári a systémoví architekti. Akú úlohu hrá táto skupina? Zúčastnite sa definície, analýzy nefunkčných požiadaviek a skontrolujte ich stupeň realizácie v živote.
  • Skúšobná skupina. Podieľa sa tiež na definícii a analýze zoznamu nefunkčných požiadaviek na program. Ďalej vyvíja testovacie scenáre pre tieto predpisy.
  • script na stanovenie požiadaviek

    Tu máme dať konkrétny príklad skriptu, ktorý sa používa na stanovenie funkčné požiadavky na výkon modulu, ktorý je určený pre odosielanie správ pre užívateľov on-line e-maily prostriedkov:

  • Systém prijme signál o udalosti a iniciuje odosielanie elektronických správ.
  • umožňuje posielanie správ do svojho zoznamu a pomocou tejto šablóny B. Pre zasielanie správ pomocou služby Art.
  • V prípade, že operáciu nemožno dokončiť, systém sa pokúsi opätovne odoslať správy.
  • Vytvorenie požiadaviek na výrobky scenára

    Teraz petíciu sa stanovili v predchádzajúcom skriptu podtitulom:
  • Požiadavky na čase oznámenia o udalosti, ktorá začína odosielanie správ, systém musí dostávať upozornenia na udalosti začatie noviniek , najneskôr do X minút po jeho výskyte.
  • Požiadavky na posielanie časových správ: správa musia byť zaslané do systému v priebehu niekoľkých sekúnd po obdržaní udalosť signálu.
  • Požiadavky na opakované odosielanie správ v prípade neúspešného pokusu: počet pokusov by mal byť X. Interval - X minút od každého neúspešného odosielania správ.
  • Kritériá dôležitých požiadaviek

    Väčšina nefunkčných požiadaviek musí prísne spĺňať množstvo kvalitatívnych kritérií týkajúcich sa ich obsahu:
  • Úplnosť (ako samostatná požiadavka a ich úplný zoznam). Čo to znamená? Žiadosť musí obsahovať všetky potrebné informácie na jej realizáciu.
  • Jednoznačné. Táto požiadavka by nemala byť v rozpore sami ani s inými položkami v zozname. Všetci profesionálni pracovníci s ním by mali rozumieť tomu istým spôsobom.
  • Správnosť samostatnej požiadavky, ktorá zabezpečuje systémovú konzistenciu.
  • Nevyhnutnosť. Realizácia tejto požiadavky je pre používateľov skutočne nevyhnutná.
  • Realizovateľnosť. Realizujte túto požiadavku života.
  • Overiteľnosť. Je potrebné zabezpečiť jednoznačné overenie jeho vykonávania.
  • Zoznámili sme sa s takým konceptom ako nefunkčné požiadavky na softvérový produkt, informačný systém. Tiež rozobrali svoje konkrétne príklady, na rozdiel od funkčnej kategórie, kritériá kvality kategórie. Viete, ktoré skupiny odborníkov vytvárajú a schvaľujú tieto predpisy.

    Súvisiace publikácie