Nefunkcionalni zahtjevi sustava: pojmovi i primjeri

U razvoju bilo kojeg novog informacijskog sustava (ili uvođenja postojećih), stručnjaci će se u svom radu nužno susresti s potrebom određivanja ove vrste zahtjeva. Ima smisla razmotriti ih detaljno. Koji su nefunkcionalni zahtjevi koji su oni, kako to određuju profesionalci.

Dvije kategorije zahtjeva

Zahtjevi za svojstva, kvalitetu softverskih proizvoda, informacijski sustavi su veliki. Međutim, one se mogu podijeliti u dvije široke kategorije - funkcionalne i nefunkcionalne zahtjeve. Na početku članka važno je razlikovati ih. Dakle:
  • Funkcionalni zahtjevi. Opišite što točno treba primijeniti u određenom sustavu ili proizvodu, koje radnje trebaju poduzeti korisnici u vezi s tim razvojem.
  • Nefunkcionalni zahtjevi. Opišite kako funkcionira stvoreni sustav ili softverski proizvod, koja svojstva i karakteristike imaju specifičan razvoj.
  • Točka 1. Koncept funkcionalnih i nefunkcionalnih zahtjeva koje smo stvorili. Sada, prijeđimo na drugu točku - razmotrimo što se točno može pripisati potonjem.


    Koja je kategorija? U biti, funkcionalni zahtjevi prvenstveno uključuju različite atribute kvalitete proizvoda. Naime - zahtjevi koji određuju kvalitativne karakteristike razvoja (softver, informacijski sustav). To je, naravno, pouzdanost, skalabilnost, performanse proizvoda. Međutim, sljedeće su od velike važnostinefunkcionalni zahtjevi:
  • Ograničenja. To jest, uvjeti koji ograničavaju izbor bilo koje odluke o provedbi određenih zahtjeva (ili skupa zahtjeva). Oni sužavaju raznolikost izbora alata, strategija, alata u razvoju strukture (arhitekture) i izgledu informacijskog proizvoda softverskog proizvoda.
  • Poslovna pravila. To uključuje smjernice, politike, načela, propise koji ograničavaju određene aspekte poslovanja. Na primjer, mogu odrediti sastav i pravila za izvršenje bilo kojih poslovnih projekata. Što se može pripisati ovoj kategoriji? Korporativna politika, sve vrste vladinih odluka i uredbi, industrijski standardi, računski algoritmi. Sva pravila koja utječu na razvoj sustava, proizvoda, koriste se pri radu na projektu.
  • Prijedlozi za provedbu. Skupina uključuje konkretne prijedloge kojima se procjenjuje izvedivost primjene određenih arhitektonskih i tehnoloških rješenja.
  • Vanjska sučelja. Opis ključnih aspekata interakcije proizvoda s drugim sustavima i radnim okruženjem. Prije svega, to su zahtjevi za API sustav ili proizvod, kao i zahtjevi API-ja drugih sustava koji se planira integrirati u proizvod koji se razvija.
  • Prijedlozi za testiranje, testiranje softvera razvijeni. Riječ je o nizu dodataka zahtjevima, koji pokazuju kako se jedan ili drugi zahtjev mora provjeriti u praksi.
  • Zakonski zahtjevi. Za licenciranje proizvoda, dostupnost patenta itd.
  • Važno je napomenuti da su nefunkcionalni zahtjevi sustavaunaprijed i fiksno. Tek tada stručnjak može započeti s razvojem proizvoda.


    Primjeri zahtjeva

    Kako bi se dobila jasnija predodžba o nefunkcionalnim zahtjevima informacijskog sustava, razmotrite nekoliko primjera:
  • Ograničenja. "Ovaj razvoj se provodi samo na platformi dobavljača X". "Prilikom provjere autentičnosti korisnika u informacijskom sustavu trebaju se koristiti samo tehnike biometrijske identifikacije."
  • Poslovna pravila. "Prilikom isporuke proizvoda, upravitelj je dužan zatražiti od računovođe fakture poduzeća i dostavnice i dostavnice." "Narudžba će biti otkazana ako dobavljač ne primi uplatu na račun u roku od 14 dana."
  • Vanjska sučelja. "Osigurajte zapisivanje operacijskog sustava takvih događaja: poruku o pokretanju i zaustavljanju X usluge." "Provjerite je li zapisnik programa zapisan u parametre podataka programa: kernel, skener, antivirusna baza podataka, a informacije bi trebalo unijeti u zapisnik i prilikom pokretanja i obnavljanja njegovih modula."

    Kako odrediti ove zahtjeve?

    Analizirali smo konkretne primjere funkcionalnih zahtjeva. A sada je još jedno važno pitanje: "Kako ih identificirati s obzirom na određeni proizvod?"
    Prije svega, stručnjaci izrađuju predložak koji navodi glavne vrste nefunkcionalnih zahtjeva za proizvod. Prije svega, potrebno je da ne propustite nijednu poziciju s ovog popisa. Programeri obično odabiru izvore za crtanje sličnih predložakasljedeći:
  • GOST (državni standard Ruske Federacije) 34. serija.
  • Knjiga "Razvoj softverskih zahtjeva" (K. Wigers). Konkretno, morate obratiti pozornost na odjeljak "Dodatak G". Sadrži konkretne primjere zahtjeva za dokumentaciju.
  • Pogledajmo sada tko se konkretno bavi ovim poslom.

    Definiranje zahtjeva proizvoda

    Posebne radne skupine uključene su u razvoj funkcionalnih i nefunkcionalnih zahtjeva za sustav. Njihovi članovi ne određuju samo, nego i provjeravaju, odobravaju ove recepte.
    Što se tiče nefunkcionalne kategorije, važno je uključiti ne samo korisnike i analitičare, već i ključne programere proizvoda, arhitekte sustava, kao i skupinu ispitivača za njegovu definiciju. Zašto je to važno? Arhitekt, na primjer, uočit će nefunkcionalne zahtjeve kao ulazne podatke za odabir i projektiranje arhitekture programa. Tim za testiranje će za to isplanirati odgovarajuće scenarije testiranja utovara. Kroz potonje će se provjeriti zahtjevi izvedbe. To se uglavnom odnosi na atribute kvalitete.

    Uloge sudionika radne skupine

    Razmotrimo sada koje uloge dijele članovi tima koji definiraju i odobravaju nefunkcionalne zahtjeve proizvoda:
  • Korisnici. Ti sudionici procjenjuju vrijednosti parametara koji određuju nefunkcionalne zahtjeve.
  • Analitičar sustava. Ovaj sudionik prikuplja, analizira,sistematizira i dokumentira nefunkcionalne zahtjeve.
  • Ključni graditelji i arhitekti sustava. Kakvu ulogu igra ova grupa? Sudjelujte u definiranju, analizi nefunkcionalnih zahtjeva i provjerite stupanj implementacije u životu.
  • Ispitna skupina. Također sudjeluje u definiranju, analizi popisa nefunkcionalnih zahtjeva za program. Dodatno razvija testne scenarije za ove recepte.

    Skripta za definiranje zahtjeva

    Ovdje dajemo konkretan primjer scenarija koji se koristi za određivanje funkcionalnih zahtjeva za produktivnost modula, dizajniranih za slanje poruka korisnicima online resursa putem e-maila:

  • Sustav prima signal o događaju, započinjući slanje elektroničkih poruka.
  • Sustav šalje poruke korisnicima na popisu A pomoću predloška B. Za slanje poruka koristi se usluga.
  • U slučaju da se postupak ne može dovršiti, sustav će ponovno pokušati ponovno poslati poruke.
  • Formiranje zahtjeva proizvoda prema scenariju

    I sada ćemo postaviti zahtjeve za scenarij koji je formiran u prethodnom podnaslovu:
  • Zahtjevi za vrijeme objave događaja koji pokreće distribuciju poruka: sustav treba primiti obavijest o događaju, pokrećući popis , najkasnije X minuta nakon nastanka.
  • Zahtjevi za slanje poruka: sustav mora biti poslan od strane sustava najkasnije X sekundi nakon primitka signala događaja.
  • Zahtjevi za ponovno slanje poruka u slučaju neuspjelog pokušaja: broj ponovnih pokušaja treba biti X. Interval - X minuta od svakog slučaja neuspješnog slanja poruka.
  • Važni kriteriji za zahtjeve

    Najnefunkcionalniji zahtjevi moraju se strogo pridržavati niza kvalitativnih kriterija u odnosu na njihov sadržaj:
  • Potpunost (kao poseban zahtjev i njihov potpuni popis). Što to znači? Zahtjev mora sadržavati sve potrebne podatke za njegovu realizaciju.
  • Nedvojbeno. Zahtjev ne smije biti u suprotnosti sa samim sobom ili bilo kojim drugim stavkama na popisu. Svi profesionalci koji rade s njim trebaju to razumjeti na isti način.
  • Ispravnost posebnog zahtjeva koji osigurava sustavnu dosljednost.
  • Nužnost. Ostvarivanje ovog zahtjeva je stvarno potrebno za korisnike.
  • Izvedivost. Ostvarite ovaj zahtjev života.
  • Provjera. Potrebno je osigurati nedvosmislenu provjeru njegove provedbe.
  • Upoznali smo se s takvim konceptom kao nefunkcionalnim zahtjevima za softverski proizvod, informacijski sustav. Također su razdvojili svoje specifične primjere, za razliku od funkcionalne kategorije, kriterije kvalitete kategorije. Znate koje skupine stručnjaka kreiraju i odobravaju ove recepte.

    Povezane publikacije