Značajke funkcionalnih zahtjeva i nefunkcionalnih zahtjeva

features functional requirements

Ovaj vodič objašnjava vrste, značajke, usporedbu funkcionalnih i nefunkcionalnih zahtjeva i poslovnih vs funkcionalnih zahtjeva sa primjerima:

Funkcionalni zahtjevi definiraju što softverski sustav treba raditi. Definira funkciju softverskog sustava ili njegovog modula. Funkcionalnost se mjeri kao skup ulaza u sustav koji se ispituje na izlaz iz sustava.

Implementacija funkcionalnih zahtjeva u sustav planira se u fazi Projektiranja sustava, dok je u slučaju nefunkcionalnih zahtjeva planirana u dokumentu Arhitektura sustava. Funkcionalni zahtjev podržava generiranje nefunkcionalnih zahtjeva.

Što ćete naučiti:

• Funkcionalni zahtjevi i nefunkcionalni zahtjevi
  • Funkcionalni zahtjevi
    • Vrste funkcionalnih zahtjeva
  • Poslovni zahtjevi vs funkcionalni zahtjevi
  • Nefunkcionalni zahtjev
    • Vrste nefunkcionalnih zahtjeva
  • Izvođenje nefunkcionalnih zahtjeva iz funkcionalnih zahtjeva
• Funkcionalni vs nefunkcionalni zahtjevi
• Zaključak
  • Preporučena literatura

Funkcionalni zahtjevi i nefunkcionalni zahtjevi

Funkcionalni zahtjevi

Shvatimo koji su funkcionalni zahtjevi uz pomoć primjera -

Primjer: U automobilskom ADAS projektu, funkcijski sustav surround prikaza mogao bi biti 'Stražnja kamera treba otkriti prijetnju ili objekt'. Ovdje bi mogli raditi nefunkcionalni zahtjevi „koliko brzo upozorenje korisniku treba prikazati kada senzori kamere otkriju prijetnju“.

Uzmi drugu primjer projekta Infotainment sustavi. Korisnik ovdje omogućuje Bluetooth putem HMI-a i provjerava je li Bluetooth omogućen ili ne. Bilješka , ostale Bluetooth usluge postaju omogućene (od sive do podebljane) kada korisnik omogući Bluetooth.

najbolji softver vatrozida za Windows 10

Dakle, funkcionalni zahtjevi govore o određenom ishodu sustava kada korisnik na njima izvrši zadatak. S druge strane, nefunkcionalni zahtjev daje cjelokupno ponašanje sustava ili njegove komponente, a ne na funkciji.

Vrste funkcionalnih zahtjeva

Funkcionalni zahtjevi mogu uključivati ​​sljedeće komponente koje se mogu mjeriti kao dio funkcionalnog ispitivanja:

# 1) Interoperabilnost: Zahtjev opisuje je li softverski sustav interoperabilan u različitim sustavima.

Primjer: Za funkcionalne potrebe Bluetootha u automobilskom informacijsko-zabavnom sustavu, kada korisnik upari pametni telefon zasnovan na Androidu sa sustavom za informiranje i zabavu zasnovan na QNX, trebali bismo biti u mogućnosti prenijeti telefonski imenik u infotainment sustav ili strujati glazbu s našeg telefonskog uređaja na infotainment sustav.

Dakle, interoperabilnost provjerava je li komunikacija između dva različita uređaja moguća ili ne.

Još primjer je iz sustava usluga e-pošte poput Gmaila. Gmail omogućuje uvoz e-pošte s drugog poslužitelja za razmjenu pošte, kao što su Yahoo.com ili Rediffmail.com. To je moguće zbog interoperabilnosti između poslužitelja e-pošte.

# 2) Sigurnost: Funkcionalni Zahtjev opisuje sigurnosni aspekt zahtjeva softvera.

Primjer: Usluge temeljene na cyber sigurnosti u sustavu zasnovanima na ADAS surround-view sustavu koji koristi Controller Area Network (CAN) koja štiti sustav od sigurnosnih prijetnji.

Još primjer je sa stranice za društvene mreže Facebook . Podaci korisnika trebaju biti sigurni i ne smiju se propuštati autsajderu. Nadamo se da ovaj primjer Facebooka daje širu nadležnost sigurnosti čitateljima zbog nedavnih slučajeva kršenja podataka na Facebooku i posljedica s kojima se Facebook suočava.

# 3) Točnost: Točnost definira da se podaci uneseni u sustav pravilno izračunavaju i koriste sustavom te da je ispis točan.

Primjer: U mrežnoj mreži kontrolera, kada se ECU prenosi vrijednost CAN signala preko CAN sabirnice (tj. ABS jedinica, HVAC jedinica, jedinica sklopa instrumenata, itd.), Druga će ECU moći prepoznati jesu li poslani podaci točni ili ne putem CRC provjere.

Još primjer može biti iz rješenja za internetsko bankarstvo. Kad korisnik primi sredstva, primljeni iznos treba točno uplatiti na račun i ne prihvaća se nikakva razlika u točnosti.

# 4) Sukladnost: Funkcionalni zahtjevi za usklađenost potvrđuju da je razvijeni sustav usklađen s industrijskim standardima.

Primjer: Jesu li funkcije Bluetooth profila (odnosno strujanje zvuka putem A2DP-a, Telefonski poziv putem HFP-a) sukladne s verzijama profila izdanja Bluetooth SIG.

Još primjer može biti ono što igra Apple Car u Car infotainment sustavu. Aplikacija u infotainmentu dobiva certifikat od Jabuka ako svi preduvjeti navedeni na web mjestu Apple ispunjavaju uređaji treće strane Car Play (u ovom slučaju infotainment).

Još primjer može biti iz internetske aplikacije za sustav željezničkih karata. Web stranica trebala bi slijediti smjernice za kibernetsku sigurnost i biti u skladu s World Wide Webom u pogledu pristupačnosti.

Primjer obrasca zahtjeva:

Već smo vidjeli koji je funkcionalni zahtjev na nekim primjerima. Pogledajmo sada kako bi funkcionalni zahtjev mogao izgledati integriran u alate za upravljanje zahtjevima kao što su IBM DOORS. Postoji više atributa koje treba uzeti u obzir prilikom dokumentiranja funkcionalnih zahtjeva u alatu za upravljanje zahtjevima.

Slijedi nekoliko atributa koje treba uzeti u obzir:

1. Vrsta objekta: Ovaj atribut objašnjava koji je odjeljak dokumenta sa zahtjevima dio ovog atributa. To bi mogli biti naslov, objašnjenje, zahtjev itd. Uglavnom se odjeljak 'Zahtjev' razmatra za provedbu i testiranje, dok se odjeljci naslova i objašnjenja koriste kao prateći opisi zahtjeva za bolje razumijevanje.
2. Odgovorna osoba: Autor koji je dokumentirao zahtjev u alatu za upravljanje zahtjevima.
3. Naziv projekta / sustava: Projekt za koji se zahtjev primjenjuje, na primjer, „Infotainment sustavi za XYZ OEM (proizvođač originalne opreme) automobilsku tvrtku ili web aplikaciju za ABC bankarsko društvo s ograničenom odgovornošću“.
4. Broj verzije zahtjeva: Ovo polje / atribut obavještava broj verzije zahtjeva ako je zahtjev pretrpio višestruke izmjene zbog ažuriranja kupaca ili promjena u dizajnu sustava.
5. ID zahtjeva: Ovaj atribut spominje jedinstveni ID zahtjeva. Id zahtjeva koristi se za lako praćenje zahtjeva u bazi podataka i za učinkovito mapiranje zahtjeva u kodu. Također se može koristiti za upućivanje na zahtjeve prilikom bilježenja nedostataka u alatima za praćenje bugova.
6. Opis zahtjeva: Ovaj je atribut jedan od najvažnijih atributa koji objašnjavaju zahtjev. Čitajući ovaj atribut, inženjer bi mogao razumjeti zahtjev.
7. Status zahtjeva: Atribut zahtjeva zahtjeva govori o statusu zahtjeva u alatu za upravljanje zahtjevima, tj. Je li projekt prihvaćen, na čekanju, odbijen ili izbrisan.
8. Komentari: Ovaj atribut pruža odgovornoj osobi ili upravitelju zahtjeva mogućnost dokumentiranja bilo kojeg komentara o zahtjevu. Primjer: mogući komentar za funkcionalni zahtjev mogao bi biti 'ovisnost o softverskom paketu treće strane za provedbu zahtjeva'.

Snimka iz VRATA

Izvođenje funkcionalnih zahtjeva iz poslovnih zahtjeva

Ovo je već pokriveno kao dio odjeljka “ Izvođenje funkcionalnih zahtjeva iz poslovnih zahtjeva ' ispod Analiza zahtjeva članak.

Poslovni zahtjevi vs funkcionalni zahtjevi

Ova razlika je slabo pokrivena u Analiza zahtjeva članak. Međutim, pokušat ćemo istaknite još nekoliko točaka ovdje u donjoj tablici:

Nefunkcionalni zahtjev

Nefunkcionalni zahtjev govori o tome 'kakav sustav treba biti', a ne o tome 'što sustav treba raditi' (funkcionalni zahtjev). Oni su uglavnom izvedeni iz funkcionalnih zahtjeva na temelju uloga kupca i drugih dionika. Pojedinosti o nefunkcionalnoj primjeni zahtjeva dokumentirane su u dokumentu Arhitektura sustava.

Nefunkcionalni zahtjevi objašnjavaju aspekte kvalitete sustava koji će se graditi, naime. performanse, prenosivost, upotrebljivost itd. Nefunkcionalni zahtjevi, za razliku od funkcionalnih zahtjeva, implementiraju se postupno u bilo koji sustav.

URPS (Upotrebljivost, pouzdanost, izvedba i podrška) od FURPS Atributi kvalitete (Funkcionalnost, upotrebljivost, pouzdanost, izvedba i podrška) koji se u IT industriji široko koriste za mjerenje kvalitete programera, pokriveni su nefunkcionalnim zahtjevima. Osim toga, postoje i drugi atributi kvalitete (detalji u sljedećem odjeljku).

Wikipediju nefunkcionalni zahtjev ponekad naziva 'nepravilnostima' zbog prisutnosti različitih atributa kvalitete poput prenosivosti i stabilnosti.

Vrste nefunkcionalnih zahtjeva

Nefunkcionalni se zahtjevi sastoje od sljedećih podvrsta (neiscrpnih):

# 1) Izvedba:

Tip atributa izvedbe nefunkcionalni zahtjev mjeri performanse sustava. Primjer: U ADAS sustavu surround prikaza, 'prikaz stražnje kamere trebao bi biti prikazan u roku od 2 sekunde od pokretanja paljenja automobila'.

Još primjer performanse mogu biti iz informacijsko-zabavnog sustava Navigacijski sustav. „Kada korisnik prijeđe na zaslon za navigaciju i unese odredište, rutu treba izračunati u roku od„ X “sekundi“. Još jedan primjer sa stranice za prijavu web aplikacije. 'Vrijeme potrebno za učitavanje stranice korisničkog profila nakon prijave.'

Imajte na umu da se mjerenje performansi sustava razlikuje od mjerenja opterećenja. Tijekom testiranja opterećenja učitavamo CPU i RAM sustava i provjeravamo propusnost sustava. U slučaju performansi, testiramo propusnost sustava u normalnim uvjetima opterećenja / naprezanja.

# 2) Upotrebljivost :

Upotrebljivost mjeri iskoristivost softverskog sustava koji se razvija.

Na primjer , razvijena je mobilna web aplikacija koja vam daje informacije o vodoinstalaterima i dostupnosti električara u vašem području.

Ulaz u ovu aplikaciju je poštanski broj i radijus (u kilometrima) od vašeg trenutnog mjesta. Ali za unos tih podataka, ako korisnik mora pregledavati više zaslona, ​​a opcija unosa podataka prikazuje se u malim tekstualnim okvirima koji nisu lako vidljivi korisniku, tada ova aplikacija nije user-friendly i stoga će biti upotrebljiva aplikacija vrlo nisko.

# 3) Održavanje :

Održavanje softverskog sustava lakoća je kojom se sustav može održavati. Ako je srednje vrijeme između kvarova (MTBF) malo ili je srednje vrijeme popravka (MTTR) visoko za sustav koji se razvija, tada se održivost sustava smatra niskom.

Održavanje se često mjeri na razini koda pomoću ciklomatične složenosti. Ciklomatična složenost kaže da je što je kod manje kompleksan, to je lakše održavati softver.

Primjer: Razvijen je softverski sustav koji ima velik broj mrtvih kodova (kodovi koje ne koriste druge funkcije ili moduli), vrlo složen zbog pretjerane upotrebe uvjeta if / else, ugniježđenih petlji itd. Ili ako je sustav velik s pokrenutim kodovima u mnoge milijune redaka kodova i bez ispravnih komentara. Takav je sustav slabo održavan.

Još primjer može biti internetska stranica za internetsku kupnju. Ako na web mjestu postoji mnogo vanjskih poveznica, tako da korisnik može imati pregled proizvoda (ovo radi uštede u memoriji), tada je održivost ovog web mjesta niska. To je zato što se, ako se veza na vanjsku web stranicu promijeni, mora ažurirati i na web mjestu za internetsku kupnju i to prečesto.

# 4) Pouzdanost :

Pouzdanost je još jedan aspekt dostupnosti. Ovaj atribut kvalitete naglašava dostupnost sustava pod određenim uvjetima. Mjeri se kao MTBF, baš kao i održivost.

Primjer: Međusobno ekskluzivne značajke poput kamere za stražnji pogled i prikolice u sustavu ADAS surround-pogleda kamere trebale bi pouzdano raditi u sustavu bez ikakvih interferencija. Kad korisnik pozove značajku prikolice, stražnji prikaz se ne bi smio ometati i obrnuto jer obje značajke pristupaju stražnjoj kameri automobila.

Još primjer iz internetskog sustava potraživanja osiguranja. Kad korisnik započne izvještavanje o potraživanjima, a zatim prenese relevantne račune troškova, sustav bi trebao dati dovoljno vremena da se prijenos završi i ne bi trebao brzo otkazati postupak prijenosa.

# 5) Prijenosnost:

Prenosivost znači sposobnost softverskog sustava da radi u drugom okruženju ako temeljni ovisni okvir ostane isti.

Primjer: Razvijeni softverski sustav / komponenta u informacijsko-zabavnom sustavu (naime, Bluetooth usluga ili multimedijska usluga) za automobilskog proizvođača automobila trebao bi omogućiti upotrebu u drugom informacijsko-zabavnom sustavu s malo ili nimalo promjena u kodu, iako su dva infotainment sustava potpuno različita .

Uzmimo drugu primjer iz WhatsAppa. Uslugu razmjene poruka moguće je instalirati i koristiti na IOS-u, Androidu, Windowsima, tabletima, prijenosnicima i telefonima.

# 6) Mogućnost podrške:

Ispravljivost softverskog sustava sposobnost je servisnog / tehničkog stručnjaka da instalira softverski sustav u okruženju u stvarnom vremenu, nadgleda sustav dok je pokrenut, prepoznaje sve tehničke probleme u sustavu i nudi rješenje za rješavanje problema.

Mogućnost servisiranja moguća je ako je sustav razvijen da olakša servisiranje.

Primjer: Pružanje povremenog skočnog prozora podsjetnika korisniku za ažuriranje softvera, pružanje mehanizma evidentiranja / praćenja za otklanjanje pogrešaka, automatski oporavak od kvara putem mehanizma vraćanja (vraćanje softverskog sustava u prethodno radno stanje).

Još primjer iz Rediffmail. Kada je došlo do ažuriranja verzije web-servisa za slanje pošte, sustav je omogućio korisniku da se prebaci na noviju verziju sustava za slanje pošte, zadržavajući stariju netaknutu nekoliko mjeseci. Ovo poboljšava i korisničko iskustvo.

# 7) Prilagodljivost:

Prilagodljivost sustava definira se kao sposobnost softverskog sustava da se prilagodi promjenama u okruženju bez ikakvih promjena u njegovom ponašanju.

Primjer: Protublokirajući kočioni sustav u automobilu trebao bi raditi prema standardima u svim vremenskim uvjetima (vrućim ili hladnim). Još primjer mogao biti operativni sustav Android. Koristi se u različitim vrstama uređaja, naime. Pametni telefoni, tablet računala i Infotainment sustavi vrlo su prilagodljivi.

Pored gore navedenih 7 nefunkcionalnih zahtjeva, imamo i mnoge druge poput:

Pristupačnost, izrada sigurnosnih kopija, kapacitet, usklađenost, integritet podataka, zadržavanje podataka, ovisnost, primjena, dokumentacija, trajnost, učinkovitost, iskoristivost, proširivost, upravljanje kvarovima, tolerancija kvarova, interoperabilnost, prilagodljivost, operativnost, privatnost, čitljivost, izvještavanje, otpornost, ponovna upotrebljivost, Robusnost, skalabilnost, stabilnost, provjerljivost, protok, transparentnost, integriranost.

Pokrivanje svih ovih nefunkcionalnih zahtjeva izvan je dosega ovog članka. Međutim, o ovim nefunkcionalnim vrstama zahtjeva možete pročitati više u Wikipedija.

Izvođenje nefunkcionalnih zahtjeva iz funkcionalnih zahtjeva

Nefunkcionalni zahtjevi mogu se izvesti na više načina, ali najbolji i većina isprobanih i isprobanih industrija je iz funkcionalnih zahtjeva.

Uzmimo primjer iz naših Infotainment sustava koje smo već uzeli na nekoliko mjesta u ovom članku. Korisnik može izvesti mnoge radnje na Infotainment sustavu, naime. promijenite pjesmu, promijenite izvor pjesme s USB-a na FM ili Bluetooth zvuk, postavite odredište za navigaciju, ažurirajte softver za zabavu putem ažuriranja softvera itd.

# 1) Prikupljanje nefunkcionalnih zahtjeva:

Navest ćemo zadatke koje izvršava korisnik, što je dio funkcionalnih zahtjeva. Jednom kada su korisničke radnje zabilježene u dijagramu slučajeva upotrebe UML-a (svaki ovalni), započet ćemo relevantna pitanja (svaki pravokutnik) o radnjama svakog korisnika. Odgovori na ova pitanja dat će nam nefunkcionalne zahtjeve.

# 2) Kategorizacija nefunkcionalnih zahtjeva:

kako postajete ispitivač proizvoda

Sljedeći je korak kategorizacija nefunkcionalnih zahtjeva koje smo identificirali pitanjima. U ovoj fazi možemo provjeriti mogući odgovor i kategorizirati odgovore na moguće nefunkcionalne kategorije ili različite kvalitete.

Na donjoj slici možete vidjeti moguće atribute kvalitete prepoznate iz odgovora.

Funkcionalni vs nefunkcionalni zahtjevi

Već smo vidjeli što su funkcionalni i nefunkcionalni zahtjevi i kako su izvedeni. Pogledajmo glavne razlike između funkcionalnih i nefunkcionalnih zahtjeva.

Zaključak

Zahtjevi čine osnovni blok za razvoj bilo kojeg softverskog sustava. Moguće je izgraditi sustav s funkcionalnim zahtjevima, ali njegove sposobnosti nije moguće utvrditi niti izmjeriti. Kad smo to već rekli, vrlo je važno imati kvalitetne funkcionalne zahtjeve koji proizlaze iz poslovnog zahtjeva da bismo imali visokokvalitetni radni softverski sustav.

Stoga funkcionalni zahtjevi daju smjer implementacije softverskog sustava, ali nefunkcionalni zahtjevi određuju kvalitetu implementacije koju će krajnji korisnici iskusiti.

Preporučena literatura

• Kako testirati specifikaciju softverskih zahtjeva (SRS)?
• Funkcionalno ispitivanje vs nefunkcionalno testiranje
• Kako testirati prijavu bez zahtjeva?
• Što je analiza zahtjeva i prikupljanje u SDLC-u?
• 5 smrtonosnih grešaka u upravljanju zahtjevima i kako ih prevladati
• Značajke funkcionalnih zahtjeva i nefunkcionalnih zahtjeva
• Kako stvoriti matricu sljedivosti zahtjeva (RTM): Primjer i predložak uzorka
• Top 20+ najboljih alata za upravljanje zahtjevima (cjelovit popis)