Pri razvoju vsakega novega informacijskega sistema (ali uvedbe obstoječih) se bodo strokovnjaki pri svojem delu nujno morali srečati s potrebo po določitvi te vrste zahtev. Smiselno jih je obravnavati podrobno. Kakšne so nefunkcionalne zahteve, ki jih določajo strokovnjaki.

Dve kategoriji zahtev

Zahteve glede značilnosti, kakovosti izdelkov programske opreme, informacijskih sistemov so velike. Lahko pa jih razdelimo v dve široki kategoriji - funkcionalne in nefunkcionalne zahteve. Na začetku članka je pomembno razlikovati med njimi. Torej:

Funkcionalne zahteve. Opišite, kaj natančno je treba izvajati v določenem sistemu ali izdelku, katere ukrepe bi morali storiti uporabniki v zvezi s tem razvojem.

Nefunkcionalne zahteve. Opišite, kako je ustvarjen sistem ali izdelek programske opreme, katere lastnosti in značilnosti imajo specifičen razvoj.

Točka 1. Koncept funkcionalnih in nefunkcionalnih zahtev smo oblikovali. Zdaj pa preidimo na drugo točko - razmislimo, kaj je mogoče pripisati slednjemu.

Kaj je kategorija?

V bistvu funkcionalne zahteve vključujejo predvsem različne lastnosti kakovosti proizvodov. Namreč - zahteve, ki določajo kvalitativne značilnosti razvoja (programska oprema, informacijski sistem). To je seveda zanesljivost, razširljivost, zmogljivost izdelka. Vendar pa so naslednje zelo pomembnenefunkcionalne zahteve:

Omejitve. To so pogoji, ki omejujejo izbiro kakršnih koli odločitev glede izvajanja določenih zahtev (ali sklopov zahtev). Zmanjšujejo raznolikost izbir orodij, strategij, orodij za razvoj strukture (arhitekture) in videza informacijskega produkta programske opreme.

Poslovna pravila. Te vključujejo smernice, politike, načela, predpise, ki omejujejo nekatere vidike poslovanja. Na primer, lahko določijo sestavo in pravila za izvajanje vseh poslovnih projektov. Kaj je mogoče pripisati tej kategoriji? Poslovna politika, vse vrste vladnih odlokov in odlokov, industrijski standardi, računalniški algoritmi. Pri delu na projektu se uporabljajo vsa pravila, ki vplivajo na razvoj sistema, produkta.

Predlogi za izvajanje. Skupina vključuje posebne predloge, ki ocenjujejo izvedljivost uporabe določenih arhitekturnih in tehnoloških rešitev.

Zunanji vmesniki. Opis ključnih vidikov interakcije z drugimi sistemi in delovnim okoljem. Prvič, to so zahteve za API sistem ali izdelek, pa tudi zahteve API drugih sistemov, ki je načrtovana za vključitev izdelka, ki se razvija.

Predlogi za testiranje, testiranje programske opreme so bili razviti. Gre za vrsto dodatkov k zahtevam, ki kažejo, kako je treba v praksi preveriti eno ali drugo zahtevo.

Zakonske zahteve. Za licenciranje izdelka, dostopnost patenta itd.

Pomembno je opozoriti na nefunkcionalne sistemske zahtevevnaprej določena in fiksna. Šele takrat lahko specialist začne razvijati izdelek.

Primeri zahtev

Da bi imeli jasnejšo predstavo o nefunkcionalnih zahtevah informacijskega sistema, upoštevajte številne primere:

Omejitve. "Ta razvoj se izvaja samo na platformi prodajalca X". "Pri preverjanju pristnosti uporabnika v informacijskem sistemu je treba uporabiti samo tehnike biometrične identifikacije."

Poslovna pravila. "Pri pošiljanju izdelka je upravitelj dolžan zaprositi računovodjo računa podjetja ter račune za odpremo in pošiljanje." "Naročilo bo preklicano, če dobavitelj ne bo prejel plačila v roku 14 dni."

Zunanji vmesniki. "Zagotovite beleženje operacijskega sistema takih dogodkov: sporočilo o začetku in zaustavitvi storitve X." "Zagotovite, da je dnevnik programa napisan v podatkovnih parametrih svojega programa: jedro, optični bralnik, protivirusna baza podatkov in informacije je treba vnesti v dnevnik med zagonom in obnavljanjem njegovih modulov."

Kako določiti te zahteve?

Analizirali smo konkretne primere funkcionalnih zahtev. In zdaj je še eno pomembno vprašanje: "Kako jih prepoznati glede na določen izdelek?"
Najprej strokovnjaki pripravijo predlogo, v kateri so navedene glavne vrste nefunkcionalnih zahtev za proizvod. Najprej je potrebno, da ne zamudimo nobenega položaja s tega seznama. Razvijalci običajno izberejo vire za risanje podobnih predlog

34. serija GOST (državni standard Ruske federacije).

Knjiga "Razvoj programskih zahtev" (K. Wigers). Zlasti morate biti pozorni na razdelek "Dodatek G". Vsebuje posebne primere zahtev za dokumentacijo.

Poglejmo zdaj, kdo se posebej ukvarja s tem delom.

Opredelitev proizvodnih zahtev

Posebne delovne skupine so vključene v razvoj funkcionalnih in nefunkcionalnih zahtev za sistem. Njihovi člani ne določajo le, ampak tudi preverjajo, odobravajo te predpise.
Kar zadeva nefunkcionalno kategorijo, je pomembno vključiti ne le uporabnike in analitike, ampak tudi ključne razvijalce proizvodov, sistemske arhitekte in skupino preizkuševalcev za njeno opredelitev. Zakaj je to pomembno? Arhitekt bo, na primer, nefunkcionalne zahteve zaznal kot vhodne podatke za izbiro in oblikovanje arhitekture programa. Skupina za testiranje bo za to načrtovala ustrezne scenarije testiranja obremenitve. Preko slednjega bodo preverjene zahteve glede zmogljivosti. To na splošno velja za atribute kakovosti.

Vloge udeležencev delovne skupine

Poglejmo zdaj, katere vloge si delijo člani skupine, ki opredeljujejo in odobravajo nefunkcionalne zahteve za proizvode:

Uporabniki. Ti udeleženci ocenijo vrednosti parametrov, ki določajo nefunkcionalne zahteve.

Sistemski analitik. Ta udeleženec zbira, analizira,sistematizira in dokumentira nefunkcionalne zahteve.

Ključni razvijalci in sistemski arhitekt. Kakšno vlogo ima ta skupina? Sodelujte pri definiciji, analizi nefunkcionalnih zahtev in jih preverite glede stopnje izvajanja v življenju.

Skupina za preskušanje. Sodeluje tudi pri opredelitvi, analizi seznama nefunkcionalnih zahtev za program. Poleg tega razvija testne scenarije za te recepte.

Skript za definiranje zahtev

Tu podajamo konkreten primer scenarija, ki se uporablja za določanje funkcionalnih zahtev za produktivnost modula, namenjene pošiljanju sporočil uporabnikom spletnega vira po elektronski pošti:

Sistem prejme signal o dogodku in sproži pošiljanje elektronskih sporočil.

Sistem pošlje sporočila uporabnikom s seznama A z uporabo predloge B. Za pošiljanje sporočil se storitev uporablja.

V primeru, da operacije ni mogoče dokončati, bo sistem poskušal ponovno poslati sporočila.

Oblikovanje zahtev po proizvodih po scenariju

Zdaj bomo postavili zahteve glede scenarija, ki je bil oblikovan v prejšnjem podnaslovu:

Zahteve za čas objave dogodka, ki sproži distribucijo sporočil: sistem mora prejeti obvestilo o dogodku, pri čemer sproži poštni seznam , najpozneje v X minutah po njenem nastanku.

Zahteve za pošiljanje sporočil: sporočila mora poslati sistem najpozneje v X sekundah po prejemu signala dogodka.

Zahteve za ponovno pošiljanje sporočil v primeru neuspešnega poskusa: število ponovnih poskusov mora biti X. Interval - X minut od vsakega primera neuspešnega pošiljanja sporočil.

Pomembna merila za zahteve

Najbolj nefunkcionalne zahteve morajo biti strogo skladne s številnimi kakovostnimi merili glede na njihovo vsebino:

Popolnost (kot ločena zahteva in njihov celoten seznam). Kaj to pomeni? Zahtevek mora vsebovati vse potrebne informacije za njegovo izvedbo.

Nedvoumno. Zahteva ne sme sama sebi nasprotovati ali drugim elementom na seznamu. Vsi strokovnjaki, ki delajo z njim, morajo to razumeti enako.

Pravilnost ločene zahteve, ki zagotavlja sistemsko doslednost.

Nujnost. Realizacija te zahteve je za uporabnike res potrebna.

Izvedljivost. Uresničite to življenjsko zahtevo.

Preverljivost. Zagotoviti je treba nedvoumno preverjanje njegovega izvajanja.

Takšen koncept smo spoznali kot nefunkcionalne zahteve za programski izdelek, informacijski sistem. Razlikovali so tudi svoje specifične primere, v nasprotju s funkcionalno kategorijo, merili kakovosti kategorije. Veste, katere skupine strokovnjakov pripravljajo in potrjujejo te predpise.