features functional requirements
Ta vadnica s primeri pojasnjuje vrste, značilnosti, primerjavo funkcionalnih in nefunkcionalnih zahtev in poslovnih vs funkcionalnih zahtev:
Funkcionalne zahteve določajo, kaj naj naredi sistem programske opreme. Določa funkcijo programskega sistema ali njegovega modula. Funkcionalnost se meri kot niz vhodov v preskušani sistem na izhode iz sistema.
Izvajanje funkcionalnih zahtev v sistemu je načrtovano v fazi načrtovanja sistema, v primeru nefunkcionalnih zahtev pa v dokumentu o sistemski arhitekturi. Funkcionalna zahteva podpira generiranje nefunkcionalnih zahtev.
Kaj se boste naučili:
Funkcionalne zahteve in nefunkcionalne zahteve
Funkcionalne zahteve
Dovolite nam, da razumemo, kaj so funkcionalne zahteve s pomočjo primerov -
Primer: V avtomobilskem projektu ADAS bi lahko bila funkcionalna zahteva sistema prostorskega pogleda »zadnja kamera zazna grožnjo ali predmet«. Nefunkcionalne zahteve tukaj bi lahko bile »kako hitro naj se prikaže opozorilo uporabniku, ko senzorji kamere zaznajo grožnjo«.
Vzemi še eno primer projekta Infotainment sistemi. Uporabnik tukaj omogoči Bluetooth iz HMI in preveri, ali je Bluetooth omogočen ali ne. Opomba , druge storitve Bluetooth se omogočijo (od sive do krepke), ko uporabnik omogoči Bluetooth.
kaj je najboljši čistilec registra
Funkcionalne zahteve torej govorijo o določenem izidu sistema, ko jih uporabnik opravi. Po drugi strani pa nefunkcionalna zahteva daje splošno vedenje sistema ali njegove komponente, ne pa funkcije.
Vrste funkcionalnih zahtev
Funkcionalne zahteve bi lahko vključevale naslednje komponente, ki jih je mogoče izmeriti kot del funkcionalnega preskušanja:
# 1) Interoperabilnost: Zahteva opisuje, ali je programski sistem interoperabilen v različnih sistemih.
Primer: Za funkcionalne zahteve Bluetootha v avtomobilskem informacijsko-razvedrilnem sistemu, ko uporabnik seznani pametni telefon s sistemom Android, ki podpira Bluetooth, z informacijsko-razvedrilnim sistemom, ki temelji na QNX, bi morali imeti možnost prenosa telefonskega imenika v informacijsko-zabavni sistem ali pretakanje glasbe iz naše telefonske naprave v informacijsko-zabavni sistem.
Interoperabilnost torej preveri, ali je komunikacija med obema napravama možna ali ne.
Še eno primer je iz sistemov e-poštnih storitev, kot je Gmail. Gmail omogoča uvoz e-poštnih sporočil z drugega strežnika za izmenjavo pošte, kot sta Yahoo.com ali Rediffmail.com. To je mogoče zaradi interoperabilnosti med e-poštnimi strežniki.
# 2) Varnost: Funkcionalno zahteva opisuje varnostni vidik zahtev programske opreme.
Primer: Storitve, ki temeljijo na kibernetski varnosti v sistemu s kamero za prostorski pogled ADAS, ki uporablja omrežje Controller Area Network (CAN), ki ščiti sistem pred varnostno grožnjo.
Še eno primer je s spletnega mesta za socialno mreženje Facebook . Uporabniški podatki bi morali biti varni in ne smejo priti v tujino. Upamo, da ta primer Facebooka daje širši obseg varnosti bralcem zaradi nedavne pogostosti kršitev podatkov na Facebooku in posledic, s katerimi se sooča Facebook.
# 3) Natančnost: Natančnost določa, da se podatki, vneseni v sistem, pravilno izračunajo in uporabljajo v sistemu ter da je izhod pravilen.
Primer: Ko v omrežju krmilnika ECU prenese vrednost signala CAN prek vodila CAN (tj. Enota ABS, enota HVAC, enota instrumentne plošče itd.), Bo lahko drugi ECU ugotovil, ali so poslani podatki pravilni ali ne. prek CRC preverjanja.
Še eno primer lahko iz rešitve spletnega bančništva. Ko uporabnik prejme sredstva, mora biti prejeti znesek natančno knjižen na račun in ni mogoče sprejeti sprememb v natančnosti.
# 4) Skladnost: Funkcionalne zahteve glede skladnosti potrjujejo, da je razviti sistem skladen z industrijskimi standardi.
Primer: Ali so funkcije profilov Bluetooth (npr. Pretakanje zvoka prek A2DP, telefonski klic prek HFP) skladne z različicami profila za izdajo Bluetooth SIG.
Še eno primer je lahko igra Apple Car-a v informacijsko-razvedrilnem sistemu Car. Aplikacija v informacijsko-razvedrilnem programu prejme potrdilo Apple če vse predpogoje, omenjene na spletnem mestu Apple, izpolnjujejo neodvisne naprave Car Play (v tem primeru infotainment).
Še eno primer lahko iz spletne aplikacije za železniški sistem vozovnic. Spletno mesto mora slediti smernicam kibernetske varnosti in biti dostopno v skladu s svetovnim spletom.
Primer obrazca zahteve:
Kakšne so funkcionalne zahteve, smo že videli z nekaj primeri. Poglejmo zdaj, kako bi izgledala funkcionalna zahteva, ki bi bila vključena v orodja za upravljanje zahtev, kot je IBM DOORS. Pri dokumentiranju funkcionalnih zahtev v orodju za upravljanje zahtev je treba upoštevati več atributov.
Spodaj je nekaj atributov, ki jih je treba upoštevati:
- Vrsta predmeta: Ta atribut pojasnjuje, kateri del dokumenta o zahtevah je del tega atributa. Lahko bi bili naslov, razlaga, zahteva itd. V glavnem se za izvajanje in preizkušanje upošteva poglavje „Zahteva“, oddelki z naslovi in razlagami pa se uporabljajo kot podporni opisi zahtev za boljše razumevanje.
- Odgovorna oseba: Avtor, ki je dokumentiral zahtevo v orodju za upravljanje zahtev.
- Ime projekta / sistema: Projekt, za katerega velja zahteva, na primer, 'Infotainment sistemi za avtomobilsko podjetje XYZ OEM (Original Equipment Manufacturer) ali spletno aplikacijo za ABC bančno delniško družbo'.
- Številka različice zahteve: To polje / atribut sporoči številko različice zahteve, če je bila zahteva večkrat spremenjena zaradi posodobitev strank ali sprememb v zasnovi sistema.
- ID zahteve: Ta atribut omenja edinstveni ID zahteve. ID zahteve se uporablja za enostavno sledenje zahtevam v zbirki podatkov in tudi za učinkovito preslikavo zahtev v kodo. Uporablja se lahko tudi za sklicevanje na zahteve med beleženjem napak v orodjih za sledenje napakam.
- Opis zahteve: Ta atribut je eden najpomembnejših atributov, ki pojasnjujejo zahtevo. Z branjem tega atributa bi inženir lahko razumel zahtevo.
- Stanje zahteve: Atribut zahteve zahteve govori o stanju zahteve v orodju za upravljanje zahtev, tj. Ali je projekt sprejet, zadržan, zavrnjen ali izbrisan.
- Komentarji: Ta atribut omogoča odgovorni osebi ali upravitelju zahtev možnost dokumentiranja kakršnega koli komentarja o zahtevi. Primer: možen komentar funkcionalne zahteve bi lahko bil 'odvisnost od programskega paketa tretje osebe za izvajanje zahteve'.
Posnetek vrat DOORS
Izpeljava funkcionalnih zahtev iz poslovnih zahtev
To je že zajeto v delu „ Izpeljava funkcionalnih zahtev iz poslovnih zahtev ' pod Analiza zahtev Članek.
Poslovne zahteve vs funkcionalne zahteve
Ta razlika je ohlapno zajeta v Analiza zahtev Članek. Bomo pa poskusili v spodnji tabeli poudarite še nekaj točk:
| Sl. Ne | Poslovne zahteve | Funkcionalne zahteve |
|---|---|---|
| 7. | Na primer, v sistemu spletnega bančništva bi bila poslovna zahteva lahko »Kot uporabnik bi moral imeti možnost dobiti izpisek gotovinske transakcije«. | Funkcionalna zahteva v tem sistemu spletnega bančništva bi lahko bila: 'Ko uporabnik v poizvedbi o transakcijah navede časovno obdobje, ta vhod uporabi strežnik in spletna stran dobi potrebne podatke o gotovinskih transakcijah'. |
| eno | Poslovne zahteve navajajo 'kakšen' vidik zahtev kupcev. Primer, Kaj mora biti uporabniku vidno po prijavi. | Funkcionalne zahteve pravijo, kako 'vidik poslovnih zahtev. Primer, Kako mora spletna stran prikazati uporabniško stran za prijavo, ko se uporabnik avtentificira. |
| dva | Poslovne zahteve opredelijo poslovni analitiki. | Funkcionalne zahteve ustvarijo / izpeljejo razvijalci / arhitekt programske opreme |
| 3. | Poudarjajo na koristi za organizacijo in so povezani s poslovnimi cilji. | Njihov cilj je izpolnjevanje zahtev kupca. |
| 4. | Poslovne zahteve so od kupca. | Funkcionalne zahteve izhajajo iz zahtev za programsko opremo, ta pa iz poslovnih zahtev. |
| 5. | Inženirji za testiranje programske opreme neposredno ne preizkušajo poslovnih zahtev. Kupec jih pretežno testira. | Funkcionalne zahteve preizkusijo inženirji za preizkušanje programske opreme, stranke pa jih na splošno ne preizkusijo. |
| 6. | Poslovna zahteva je dokument z zahtevami na visoki ravni. | Funkcionalna zahteva je podroben dokument s tehničnimi zahtevami. |
Nefunkcionalna zahteva
Nefunkcionalna zahteva govori o tem, »kakšen sistem bi moral biti«, ne pa o tem, »kaj naj sistem počne« (funkcionalna zahteva). Večinoma izhajajo iz funkcionalnih zahtev, ki temeljijo na prispevkih stranke in drugih zainteresiranih strani. Podrobnosti o izvajanju nefunkcionalnih zahtev so dokumentirane v dokumentu System Architecture.
Nefunkcionalne zahteve pojasnjujejo vidike kakovosti sistema, ki ga je treba zgraditi, tj. zmogljivost, prenosljivost, uporabnost itd. Nefunkcionalne zahteve se za razliko od funkcionalnih zahtev postopoma izvajajo v katerem koli sistemu.
URPS (Uporabnost, zanesljivost, zmogljivost in podpornost) iz FURPS Atributi kakovosti (funkcionalnost, uporabnost, zanesljivost, zmogljivost in podpornost), ki se v IT industriji pogosto uporabljajo za merjenje kakovosti razvijalca programske opreme, so zajeti v nefunkcionalnih zahtevah. Poleg tega obstajajo tudi drugi atributi kakovosti (podrobnosti v naslednjem razdelku).
Wikipedija nefunkcionalno zahtevo včasih imenuje 'nepravilnosti' zaradi prisotnosti različnih lastnosti kakovosti, kot sta prenosljivost in stabilnost.
Vrste nefunkcionalnih zahtev
Nefunkcionalne zahteve so sestavljene iz spodnjih podtipov (neizčrpnih):
# 1) Uspešnost:
Vrsta atributa uspešnosti nefunkcionalne zahteve meri zmogljivost sistema. Primer: V sistemu prostorskega pogleda ADAS mora biti 'pogled zadnje kamere prikazan v 2 sekundah po zagonu avtomobilskega vžiga'.
Še eno primer zmogljivosti lahko izvirajo iz informacijsko-zabavnega sistema Navigacijski sistem. 'Ko uporabnik odpre zaslon za navigacijo in vnese cilj, mora biti pot izračunana v sekundah' X '. Še en primer s strani za prijavo v spletno aplikacijo. 'Čas, potreben za nalaganje strani uporabniškega profila po prijavi.'
Ne pozabite, da se merjenje učinkovitosti sistema razlikuje od merjenja obremenitve. Med testiranjem obremenitve naložimo sistemski CPU in RAM ter preverimo prepustnost sistema. V primeru zmogljivosti preizkusimo prepustnost sistema v normalnih pogojih obremenitve / obremenitve.
# 2) Uporabnost :
Uporabnost meri uporabnost programskega sistema, ki se razvija.
Na primer , je razvita mobilna spletna aplikacija, ki vam daje informacije o vodovodarjih in razpoložljivosti električarjev na vašem območju.
Vnos v to aplikacijo je poštna številka in polmer (v kilometrih) od vaše trenutne lokacije. Če pa uporabnik vnaša te podatke, če mora uporabnik brskati po več zaslonih in je možnost vnosa podatkov prikazana v majhnih besedilnih poljih, ki jih uporabnik ne vidi takoj, potem ta aplikacija ni uporabniku prijazna in bo zato uporabnost aplikacije zelo nizko.
# 3) Vzdrževanje :
Vzdrževanje programskega sistema je enostavnost vzdrževanja sistema. Če je srednji čas med napakami (MTBF) nizek ali je srednji čas do popravila (MTTR) visok za sistem, ki se razvija, potem se vzdržnost sistema šteje za nizko.
Vzdrževalnost se pogosto meri na ravni kode z uporabo ciklomatične zapletenosti. Ciklomatična zapletenost pravi, da manj kot je koda kompleksnejša, lažje je vzdrževati programsko opremo.
Primer: Razvit je programski sistem, ki ima veliko število mrtvih kod (kod, ki jih ne uporabljajo druge funkcije ali moduli), zelo zapleten zaradi pretirane uporabe pogojev if / else, ugnezdenih zank itd. Ali če je sistem velik, ko se izvajajo kode v več milijonov vrstic kod in brez ustreznih komentarjev. Tak sistem ima majhno vzdrževalnost.
Še eno primer lahko spletno stran za spletno nakupovanje. Če je na spletnem mestu veliko zunanjih povezav, tako da ima uporabnik pregled izdelka (ta zaradi prihranka na pomnilniku), je vzdrževalnost tega spletnega mesta nizka. V primeru, da se spremeni povezava do zunanje spletne strani, jo je treba posodobiti tudi na spletnem mestu za nakupovanje in to prepogosto.
# 4) Zanesljivost :
Zanesljivost je še en vidik razpoložljivosti. Ta atribut kakovosti poudarja razpoložljivost sistema pod določenimi pogoji. Izmeri se kot MTBF tako kot vzdrževanje.
Primer: Vzajemno izključne funkcije, kot so kamera za vzvratno vožnjo in prikolica v sistemu prostorskih kamer ADAS, bi morale zanesljivo delovati v sistemu brez kakršnih koli motenj med seboj. Ko uporabnik prikliče funkcijo priklopnika, vzvratna vožnja ne sme ovirati in obratno, saj obe funkciji dostopata do zadnje kamere avtomobila.
Še eno primer iz spletnega sistema zavarovanja škod. Ko uporabnik začne poročanje o zahtevkih in nato naloži ustrezne račune za stroške, mora sistem dati dovolj časa, da se nalaganje zaključi, in ne sme hitro preklicati postopka nalaganja.
# 5) Prenosljivost:
Prenosljivost pomeni sposobnost programskega sistema, da deluje v drugačnem okolju, če osnovni odvisni okvir ostane enak.
Primer: Programski sistem / komponenta v informacijsko-razvedrilnem sistemu (tj. Storitev Bluetooth ali večpredstavnostna storitev) za proizvajalca avtomobilov bi morala omogočati uporabo v drugem informacijsko-razvedrilnem sistemu z malo ali nič sprememb kode, čeprav sta oba infozabavna sistema povsem različna .
Vzemimo drugega primer iz WhatsApp. Storitev sporočanja je mogoče namestiti in uporabljati v sistemih IOS, Android, Windows, Tablet, Laptop in Phone.
# 6) Podpornost:
najboljša vohunska aplikacija za android
Uporabnost programskega sistema je zmožnost servisnega / tehničnega strokovnjaka, da namesti programski sistem v realnem času, spremlja sistem, medtem ko deluje, prepozna morebitne tehnične težave v sistemu in ponudi rešitev za rešitev težave.
Uporabnost je mogoča, če je sistem razvit za lažjo uporabnost.
Primer: Zagotavljanje periodičnega pojavnega opomnika uporabniku za posodobitev programske opreme, zagotavljanje mehanizma beleženja / sledenja za odpravljanje napak, samodejno okrevanje po okvari prek mehanizma za povrat (programski sistem vrne v prejšnje stanje delovnega stanja).
Še eno primer iz Rediffmail. Ko je prišlo do posodobitve različice spletne poštne storitve, je sistem dovolil uporabniku, da je prešel na novejšo različico poštnega sistema, pri čemer je starejša nekaj mesecev ostala nedotaknjena. To izboljšuje tudi uporabniško izkušnjo.
# 7) Prilagodljivost:
Prilagodljivost sistema je opredeljena kot sposobnost programskega sistema, da se prilagodi spremembam v okolju brez kakršnih koli sprememb v njegovem vedenju.
Primer: Protiblokirni zavorni sistem v avtomobilu bi moral delovati po standardu v vseh vremenskih razmerah (vroče ali hladno). Še eno primer lahko operacijski sistem Android. Uporablja se v različnih vrstah naprav, tj. Pametni telefoni, tablični računalniki in informacijsko-zabavni sistemi so zelo prilagodljivi.
Poleg zgoraj naštetih 7 nefunkcionalnih zahtev imamo še veliko drugih, kot so:
Dostopnost, varnostno kopiranje, zmogljivost, skladnost, celovitost podatkov, hramba podatkov, odvisnost, uvajanje, dokumentacija, trajnost, učinkovitost, uporabnost, razširljivost, upravljanje napak, toleranca napak, interoperabilnost, spremenljivost, operativnost, zasebnost, berljivost, poročanje, odpornost, ponovna uporabnost, Robustnost, razširljivost, stabilnost, preizkušljivost, pretočnost, preglednost, integriranost.
Pokrivanje vseh teh nefunkcionalnih zahtev je zunaj področja uporabe tega članka. Več o teh nefunkcionalnih vrstah zahtev pa lahko preberete v Wikipedija.
Izpeljava nefunkcionalnih zahtev iz funkcionalnih zahtev
Nefunkcionalne zahteve lahko izpeljemo na več načinov, toda najboljši in najbolj preizkušen in preizkušen način je iz funkcionalnih zahtev.
Vzemimo primer iz naših sistemov Infotainment, ki smo jih v tem članku že navedli na nekaj mestih. Uporabnik lahko izvede veliko dejanj v sistemu Infotainment, tj. spremenite pesem, spremenite vir pesmi z USB na FM ali zvok Bluetooth, nastavite cilj navigacije, posodobite programsko opremo za informacijsko in zabavno vsebino s posodobitvijo programske opreme itd.
# 1) Zbiranje nefunkcionalnih zahtev:
Našteli bomo naloge, ki jih izvaja uporabnik, kar je del funkcionalnih zahtev. Ko so uporabniška dejanja zabeležena v diagramu primerov uporabe UML (vsak oval), bomo začeli z ustreznimi vprašanji (vsak pravokotnik) o dejanjih vsakega uporabnika. Odgovori na ta vprašanja bodo podali naše nefunkcionalne zahteve.
# 2) Kategorizacija nefunkcionalnih zahtev:
Naslednji korak je kategorizacija nefunkcionalnih zahtev, ki smo jih ugotovili z vprašanji. Na tej stopnji lahko preverimo možen odgovor in razvrstimo odgovore na možne nefunkcionalne kategorije ali različne lastnosti.
Na spodnji sliki si lahko ogledate možne lastnosti kakovosti, opredeljene v odgovorih.
Funkcionalne Vs Nefunkcionalne zahteve
Že smo videli, kaj so funkcionalne in nefunkcionalne zahteve in kako iz njih izhajajo. Oglejmo si glavne razlike med funkcionalnimi in nefunkcionalnimi zahtevami.
| Sl. št | Funkcionalne zahteve (FR) | Nefunkcionalne zahteve (NFR) |
|---|---|---|
| 7. | Funkcionalne zahteve tvorijo okostje implementacije programske opreme | Nefunkcionalne zahteve dopolnjujejo sistem SW s pomočjo, da se funkcionalne zahteve držijo skupaj, kot mišica. |
| eno | Pravijo, kaj naj sistem naredi. | Pravijo, kakšen sistem bi moral biti. |
| dva | Podrobno so opisani v dokumentu System Design. | Podrobno so opisani v dokumentu o sistemski arhitekturi. |
| 3. | Govorijo o vedenju funkcije ali funkcije. | Govorijo o delovnem vedenju celotnega sistema ali njegove komponente in ne o določeni funkciji. |
| 4. | Uporabnik bo posredoval vnos in preveril, ali je izhod pravilno prikazan. | Ko uporabnik poda vnos, lahko NFR odgovori na naslednja vprašanja: i) Koliko časa traja za prikaz rezultatov? ii) Ali je rezultat skladen s časom? iii) Ali obstajajo drugi načini za prenos vhodnega parametra? iv) Kako enostavno je prenesti vhodni parameter? |
| 5. | V spletni aplikaciji mora imeti uporabnik možnost prijave prek preverjanja pristnosti | Koliko časa v spletni aplikaciji potrebuje za prijavo na spletno mesto, videz in občutek prijavne strani, enostavnost uporabe spletne strani itd. So del NFR |
| 6. | Funkcionalne zahteve izhajajo najprej iz zahtev za programsko opremo. | Nefunkcionalne zahteve izhajajo iz funkcionalnih zahtev. |
| 8. | Funkcionalne zahteve lahko obstajajo brez nefunkcionalne zahteve. | Nefunkcionalne zahteve ne morejo obstajati brez funkcionalnih zahtev. |
| 9. | Funkcionalna zahteva daje konkretne informacije o lastnosti, Primer , Fotografija profila na Facebooku mora biti vidna ob prijavi. | Funkcionalna zahteva ima lahko veliko atributov nefunkcionalnih zahtev. Primer, čas za prijavo (zmogljivost), izgled in občutek strani profila (uporabnost), število uporabnikov, ki se lahko hkrati prijavijo (zmogljivost, zmogljivost) |
| 10. | Izhajanje iz funkcionalnih zahtev iz zahtev SW je mogoče za skoraj vse poslovne zahteve | NFR pogosto zamujamo dokumentirati, saj se o FR ne postavljajo ustrezna vprašanja. |
| enajst | Izvajanje funkcionalnih zahtev se običajno izvede v eni zgradbi programske opreme. | NFR se izvajajo v celotnem življenjskem ciklu projekta, dokler ni doseženo želeno vedenje. |
| 12. | Te so večinoma vidne kupcu. | Te stranke večinoma niso vidne, vendar bi jih lahko dolgoročno doživeli. Primer, Uporabnost, zmogljivost itd. Je mogoče izkusiti le dolgoročno, vendar sploh ne more biti vidna. |
Zaključek
Zahteve predstavljajo osnovni gradnik za razvoj katerega koli programskega sistema. Možno je zgraditi sistem s funkcionalnimi zahtevami, vendar njegovih sposobnosti ni mogoče določiti ali izmeriti. Ob tem je zelo pomembno, da imamo kakovostne funkcionalne zahteve, ki izhajajo iz poslovne zahteve, da imamo visokokakovosten delujoč sistem programske opreme.
Funkcionalne zahteve torej usmerjajo izvajanje programskega sistema, nefunkcionalne zahteve pa določajo kakovost izvedbe, ki jo bodo imeli končni uporabniki.
Priporočeno branje
- Kako preizkusiti specifikacijo zahtev za programsko opremo (SRS)?
- Funkcionalno testiranje vs nefunkcionalno testiranje
- Kako preizkusiti prijavo brez zahtev?
- Kaj je analiza zahtev in zbiranje v SDLC?
- 5 smrtonosnih napak pri upravljanju z zahtevami in kako jih premagati
- Značilnosti funkcionalnih zahtev in nefunkcionalnih zahtev
- Kako ustvariti matriko sledljivosti zahtev (RTM): primer in vzorčna predloga
- Top 20+ najboljših orodij za upravljanje zahtev (popoln seznam)