features functional requirements
Tento výukový program vysvetľuje príklady typov, funkcií, porovnania funkčných a nefunkčných požiadaviek a obchodných a funkčných požiadaviek.
Funkčné požiadavky definujú, čo má softvérový systém robiť. Definuje funkciu softvérového systému alebo jeho modulu. Funkčnosť sa meria ako sada vstupov do testovaného systému s výstupom zo systému.
Implementácia funkčných požiadaviek v systéme sa plánuje vo fáze návrhu systému, zatiaľ čo v prípade nefunkčných požiadaviek sa plánuje v dokumente Systémová architektúra. Funkčná požiadavka podporuje generovanie nefunkčných požiadaviek.
Čo sa dozviete:
Funkčné požiadavky a nefunkčné požiadavky
Funkčné požiadavky
Poďme pochopiť, čo sú funkčné požiadavky, pomocou príkladov -
Príklad: V projekte Automotive ADAS môže byť požiadavkou na funkčnosť systému priestorového zobrazenia „Zadná kamera by mala detekovať hrozbu alebo objekt“. Nefunkčnými požiadavkami by tu mohli byť „ako rýchlo by sa malo zobraziť upozornenie pre používateľa, keď je senzorom kamery detekovaná hrozba“.
Vezmite si ďalší príklad projektu Informačno-zábavné systémy. Používateľ tu povolí Bluetooth z HMI a skontroluje, či je Bluetooth povolené alebo nie. Poznámka , ostatné služby Bluetooth sa aktivujú (od sivej po tučné), keď používateľ povolí Bluetooth.
funkcia time () c ++
Takže funkčné požiadavky hovoria o konkrétnom výsledku systému, keď na nich používateľ vykoná úlohu. Na druhej strane nefunkčná požiadavka udáva celkové chovanie systému alebo jeho súčasti, a nie funkciu.
Typy funkčných požiadaviek
Funkčné požiadavky môžu zahŕňať nasledujúce komponenty, ktoré je možné merať ako súčasť funkčného testovania:
# 1) Interoperabilita: Požiadavka popisuje, či je softvérový systém interoperabilný v rôznych systémoch.
Príklad: Pokiaľ ide o funkčnú požiadavku Bluetooth v informačnom systéme automobilu, keď používateľ spáruje inteligentný telefón s Androidom podporujúcim technológiu Bluetooth s informačným systémom založeným na QNX, mali by sme byť schopní prenášať telefónny zoznam do informačno-zábavného systému alebo streamovať hudbu z nášho telefónneho zariadenia do informačno-zábavného systému.
Interoperabilita teda kontroluje, či je alebo nie je možná komunikácia medzi týmito dvoma rôznymi zariadeniami.
Ďalší príklad pochádza zo systémov e-mailových služieb, ako je Gmail. Gmail umožňuje import e-mailov z iného servera na výmenu pošty, ako je Yahoo.com alebo Rediffmail.com. To je možné z dôvodu interoperability medzi e-mailovými servermi.
# 2) Zabezpečenie: Funkčné požiadavka popisuje bezpečnostný aspekt softvérových požiadaviek.
Príklad: Služby založené na kybernetickej bezpečnosti v kamerovom systéme ADAS s priestorovým zobrazením, ktorý využíva sieť CAN (Controller Area Network) chrániacu systém pred bezpečnostnou hrozbou.
Ďalší príklad pochádza zo stránky sociálnych sietí Facebook . Údaje používateľa by mali byť zabezpečené a nemali by sa dostať k cudzím osobám. Dúfame, že tento príklad Facebooku poskytuje čitateľom širšiu oblasť bezpečnosti kvôli nedávnemu výskytu porušenia údajov na Facebooku a následkom, ktorým Facebook čelí.
# 3) Presnosť: Presnosť definuje, že údaje zadané do systému sú správne vypočítané a použité systémom a že výstup je správny.
Príklad: V sieti riadiacej oblasti, keď sa hodnota signálu CAN prenáša cez zbernicu CAN ECU (napr. Jednotka ABS, jednotka HVAC, jednotka združeného prístroja atď.), Iná ECU bude schopná zistiť, či sú odoslané údaje správne alebo nie prostredníctvom kontroly CRC.
Ďalší príklad môže pochádzať z riešenia online bankovníctva. Keď používateľ dostane fond, mala by sa mu pripísaná suma pripísať presne na účet a neprijímajú sa žiadne zmeny v presnosti.
# 4) Súlad: Funkčné požiadavky na zhodu potvrdzujú, že vyvinutý systém je v súlade s priemyselnými normami.
Príklad: Či sú funkcie profilov Bluetooth (napr. Streamovanie zvuku cez A2DP, telefónny hovor cez HFP) kompatibilné s verziami profilov verzie Bluetooth SIG.
Ďalší príklad môže to byť hra Apple Car v informačnom systéme automobilu. Aplikácia v infotainmente dostane certifikát od Apple ak všetky predpoklady uvedené na webe Apple spĺňajú zariadenia Car Play od tretích strán (v tomto prípade infotainment).
Ďalší príklad môže byť z webovej aplikácie pre systém predaja cestovných lístkov na železnici. Webová stránka by mala dodržiavať pokyny pre kybernetickú bezpečnosť a z hľadiska prístupnosti by mala byť v súlade s World Wide Web.
Príklad formulára požiadavky:
Na niektorých príkladoch sme už videli, aká je funkčná požiadavka. Pozrime sa teraz, ako by vyzerala funkčná požiadavka, ak by bola integrovaná do nástrojov na správu požiadaviek, ako je IBM DOORS. Pri dokumentovaní funkčných požiadaviek v nástroji na správu požiadaviek je potrebné brať do úvahy niekoľko atribútov.
Ďalej uvádzame niekoľko atribútov, ktoré je potrebné vziať do úvahy:
- Typ objektu: Tento atribút vysvetľuje, ktorá časť dokumentu s požiadavkami je súčasťou tohto atribútu. Môžu to byť nadpis, vysvetlenie, požiadavka atď. Väčšinou sa časť „Požiadavka“ považuje za implementáciu a testovanie, zatiaľ čo sekcie nadpisu a vysvetlenia sa používajú ako podporné popisy požiadaviek na lepšie pochopenie.
- Zodpovedná osoba: Autor, ktorý zdokumentoval požiadavku v nástroji na správu požiadaviek.
- Názov projektu / systému: Projekt, na ktorý sa požiadavka vzťahuje, napríklad, „Infotainment Systems for XYZ OEM (Original Equipment Manufacturer) automobilová spoločnosť alebo webová aplikácia pre spoločnosť ABC banking s ručením obmedzeným“.
- Číslo verzie požiadavky: Toto pole / atribút informuje číslo verzie požiadavky, ak požiadavka prešla viacerými úpravami v dôsledku aktualizácií zákazníka alebo zmien v dizajne systému.
- ID požiadavky: Tento atribút uvádza jedinečné ID požiadavky. Identifikátor požiadavky sa používa na ľahké sledovanie požiadaviek v databáze a tiež na efektívne mapovanie požiadaviek v kóde. Môže sa tiež použiť na poskytnutie odkazu na požiadavky pri zaznamenávaní chýb v nástrojoch na sledovanie chýb.
- Popis požiadavky: Tento atribút je jedným z najdôležitejších atribútov, ktoré vysvetľujú požiadavku. Po prečítaní tohto atribútu by inžinier dokázal porozumieť požiadavke.
- Stav požiadavky: Atribút Status požiadavky hovorí o stave požiadavky v nástroji na správu požiadaviek, t. J. Či je projekt prijatý, pozastavený, odmietnutý alebo vymazaný.
- Komentáre: Tento atribút poskytuje zodpovednej osobe alebo správcovi požiadaviek možnosť zdokumentovať akýkoľvek komentár k požiadavke. Príklad: možnou poznámkou k funkčnej požiadavke by mohla byť „závislosť od implementácie požiadavky od softvérového balíka tretej strany“.
Momentka z DVERÍ
Odvodenie funkčných požiadaviek od obchodných požiadaviek
Toto je už obsiahnuté v časti „ Odvodenie funkčných požiadaviek od obchodných požiadaviek ' pod Analýza požiadaviek článok.
Obchodné požiadavky vs Funkčné požiadavky
Tento rozdiel je voľne obsiahnutý v Analýza požiadaviek článok. Pokúsime sa však o to tu v nasledujúcej tabuľke zvýraznite ešte niekoľko bodov:
| Sl. Č. | Obchodné požiadavky | Funkčné požiadavky |
|---|---|---|
| 7 | Napríklad, v systéme online bankovníctva môže byť obchodná požiadavka „Ako používateľ by som mal byť schopný získať výpis z hotovostných transakcií“. | Funkčnou požiadavkou v tomto systéme online bankovníctva môže byť: „Keď používateľ zadá rozsah dátumov v dotaze na transakciu, tento vstup použije server a webovej stránke sa poskytnú potrebné údaje o hotovostných transakciách“. |
| jeden | Obchodné požiadavky hovoria „aký“ aspekt požiadavky zákazníka. Príklad, Čo by malo byť viditeľné pre používateľa po prihlásení používateľa. | Funkčné požiadavky hovoria o „ako“ obchodných požiadavkách. Príklad, Ako by mala webová stránka zobrazovať prihlasovaciu stránku používateľa, keď sa používateľ autentizuje. |
| dva | Obchodné požiadavky identifikujú obchodní analytici. | Funkčné požiadavky vytvára / odvodzuje vývojár / softvérový architekt |
| 3 | Zdôrazňujú prínos pre organizáciu a súvisia s obchodnými cieľmi. | Ich cieľom je plnenie požiadaviek zákazníka. |
| 4 | Obchodné požiadavky sú od zákazníka. | Funkčné požiadavky sú odvodené od softvérových požiadaviek, ktoré sú zase odvodené od obchodných požiadaviek. |
| 5 | Obchodné požiadavky nie sú testované priamo softvérovými testovacími inžiniermi. Väčšinou sú testované zákazníkom. | Funkčné požiadavky sú testované technikmi Software Test a spravidla nie sú testované zákazníkmi. |
| 6 | Obchodná požiadavka je dokument s požiadavkou na vysokej úrovni. | Funkčnou požiadavkou je podrobný dokument technických požiadaviek. |
Nefunkčná požiadavka
Nefunkčná požiadavka hovorí skôr o tom, „čo by mal byť systém“, ako „o tom, čo by mal systém robiť“ (funkčná požiadavka). Väčšinou sú odvodené z funkčných požiadaviek na základe vstupov od zákazníka a iných zainteresovaných strán. Podrobnosti o implementácii nefunkčných požiadaviek sú zdokumentované v dokumente System Architecture.
Nefunkčné požiadavky vysvetľujú kvalitatívne aspekty systému, ktorý sa má vybudovať, pozri. výkon, prenosnosť, použiteľnosť atď. Nefunkčné požiadavky sú na rozdiel od funkčných požiadaviek implementované postupne v každom systéme.
URPS (Použiteľnosť, spoľahlivosť, výkon a podpora) z FURPS (Funkčnosť, použiteľnosť, spoľahlivosť, výkon a podpora) atribúty kvality, ktoré sa v IT priemysle často používajú na meranie kvality softvérového vývojára, sú pokryté nefunkčnými požiadavkami. Okrem toho existujú aj ďalšie atribúty kvality (podrobnosti v nasledujúcej časti).
Wikipedia nazýva nefunkčnú požiadavku niekedy ako „ility“ kvôli rôznym atribútom kvality, ako je prenosnosť a stabilita.
Typy nefunkčných požiadaviek
Nefunkčné požiadavky pozostávajú z podtypov (nevyčerpávajúcich):
# 1) Výkon:
Typ funkčného atribútu nefunkčnej požiadavky meria výkon systému. Príklad: V systéme priestorového zobrazenia ADAS by sa „mal zobraziť pohľad zadnej kamery do 2 sekúnd od spustenia zapaľovania vozidla“.
Ďalší príklad výkonu môže byť z informačno-zábavného systému Navigačný systém. „Keď používateľ prejde na obrazovku Navigácia a zadá cieľ, trasa by sa mala vypočítať do„ X “sekúnd.“ Ešte jeden príklad z prihlasovacej stránky webovej aplikácie. 'Čas potrebný na načítanie stránky profilu používateľa po prihlásení.'
Pamätajte, že meranie výkonu systému sa líši od merania zaťaženia. Počas testovania zaťaženia načítame procesor a RAM systému a kontrolujeme priechodnosť systému. V prípade výkonu testujeme priepustnosť systému za normálnych podmienok zaťaženia / stresu.
# 2) Použiteľnosť :
Použiteľnosť meria použiteľnosť vyvíjaného softvérového systému.
Napríklad , je vyvinutá mobilná webová aplikácia, ktorá vám poskytne informácie o inštalatéroch a dostupnosti elektrikára vo vašej oblasti.
Vstup do tejto aplikácie je PSČ a polomer (v kilometroch) od vašej aktuálnej polohy. Ak však chcete tieto údaje zadať, ak musí používateľ prechádzať cez viac obrazoviek a možnosť zadávania údajov sa zobrazuje v malých textových poliach, ktoré pre neho nie sú ľahko viditeľné, potom táto aplikácia nie je pre používateľa prívetivá, a preto bude použiteľnosť aplikácie veľmi nízky.
nástroje, ktoré potrebujete na vývoj webových aplikácií
# 3) Udržateľnosť :
Udržateľnosť softvérového systému je ľahkosť, s akou je možné tento systém udržiavať. Ak je stredná doba medzi poruchami (MTBF) nízka alebo je stredná doba opravy (MTTR) vysoká pre vyvíjaný systém, potom je udržiavateľnosť systému považovaná za nízku.
Udržateľnosť sa často meria na úrovni kódu pomocou cyklomatickej zložitosti. Cyklomatická zložitosť hovorí, že čím je kód menej zložitý, tým ľahšia je údržba softvéru.
Príklad: Je vyvinutý softvérový systém, ktorý má vysoký počet mŕtvych kódov (kódy, ktoré nepoužívajú iné funkcie alebo moduly), veľmi zložitý z dôvodu nadmerného používania podmienky if / else, vnorených slučiek atď. Alebo ak je systém obrovský so spustenými kódmi do mnohých miliónov riadkov kódov a bez náležitých komentárov. Takýto systém je nenáročný na údržbu.
Ďalší príklad môže to byť webová stránka nakupovania online. Ak je na webe veľa externých odkazov, aby mal používateľ prehľad o produkte (šetrí to pamäť), potom je udržiavateľnosť tohto webu nízka. Je to preto, že ak sa zmení odkaz na externú webovú stránku, musí sa aktualizovať aj na webových stránkach online nakupovania, a to príliš často.
# 4) Spoľahlivosť :
Spoľahlivosť je ďalším aspektom dostupnosti. Tento atribút kvality zdôrazňuje dostupnosť systému za určitých podmienok. Meria sa ako MTBF rovnako ako udržiavateľnosť.
Príklad: Vzájomne sa vylučujúce funkcie ako spätná kamera a príves v kamerovom systéme priestorového zobrazenia ADAS by mali v systéme spoľahlivo fungovať bez vzájomného rušenia. Keď používateľ vyvolá funkciu Príves, spätná väzba by nemala prekážať a naopak, pretože obidve funkcie majú prístup k zadnej kamere vozidla.
Ďalší príklad z online systému poistných udalostí. Keď používateľ začne hlásiť reklamácie a potom nahrá príslušné faktúry s výdavkami, systém by mal dať dostatok času na dokončenie nahrávania a nemal by proces nahrávania rýchlo zrušiť.
# 5) Prenosnosť:
Prenosnosť znamená schopnosť softvérového systému pracovať v inom prostredí, ak základný závislý rámec zostáva rovnaký.
Príklad: Softvérový systém / komponent v informačno-zábavnom systéme vyvinutý (napr. Služba Bluetooth alebo multimediálna služba) pre výrobcu automobilov by mal umožniť použitie v inom informačno-zábavnom systéme s malou alebo žiadnou zmenou kódu, aj keď sú tieto dva informačné systémy úplne odlišné .
Vezmime si ďalší príklad z WhatsApp. Službu správ je možné nainštalovať a používať v systémoch IOS, Android, Windows, Tablet, Laptop a Phone.
# 6) Podpora:
Prevádzkovateľnosť softvérového systému je schopnosť servisného / technického odborníka inštalovať softvérový systém v prostredí v reálnom čase, monitorovať systém, keď je v chode, identifikovať technické problémy v systéme a poskytovať riešenie problému.
Prevádzkovateľnosť je možná, ak je systém vyvinutý na uľahčenie prevádzkyschopnosti.
Príklad: Poskytovanie pravidelných kontextových upozornení na aktualizáciu softvéru používateľovi, poskytnutie mechanizmu prihlásenia / sledovania na ladenie problémov, automatické zotavenie po zlyhaní pomocou mechanizmu vrátenia (vrátenie softvérového systému do predchádzajúceho stavu pracovných podmienok).
Ďalší príklad od Rediffmail. Keď došlo k aktualizácii verzie webovej poštovej služby, systém umožnil používateľovi prejsť na novšiu verziu poštového systému, pričom starú ponechal niekoľko mesiacov nedotknutú. To zvyšuje aj užívateľskú skúsenosť.
# 7) Adaptabilita:
Adaptabilita systému je definovaná ako schopnosť softvérového systému prispôsobiť sa zmenám v prostredí bez akejkoľvek zmeny jeho správania.
Príklad: Protiblokovací brzdový systém v automobile by mal fungovať štandardne za každých poveternostných podmienok (horúce alebo studené). Ďalší príklad môže to byť operačný systém Android. Používa sa v rôznych typoch zariadení, napr. Smartphony, tablety a informačno-zábavné systémy a sú veľmi prispôsobivé.
Okrem 7 nefunkčných požiadaviek uvedených vyššie máme ešte veľa ďalších, ako napríklad:
Prístupnosť, zálohovanie, kapacita, dodržiavanie súladu, integrita údajov, uchovávanie údajov, závislosť, nasadenie, dokumentácia, trvanlivosť, efektívnosť, využiteľnosť, rozšíriteľnosť, správa porúch, tolerancia chýb, interoperabilita, modifikovateľnosť, operatívnosť, ochrana osobných údajov, čitateľnosť, vykazovanie, odolnosť, opätovná použiteľnosť, Robustnosť, škálovateľnosť, stabilita, testovateľnosť, priepustnosť, transparentnosť, integrovateľnosť.
Pokrytie všetkých týchto nefunkčných požiadaviek je mimo rozsahu tohto článku. Viac informácií o týchto typoch nefunkčných požiadaviek si však môžete prečítať v Wikipedia.
Odvodenie nefunkčných požiadaviek od funkčných požiadaviek
Nefunkčné požiadavky je možné odvodiť mnohými spôsobmi, ale najlepší a väčšina priemyselne osvedčených spôsobov je z funkčných požiadaviek.
Zoberme si príklad z našich informačno-zábavných systémov, ktorý sme si v tomto článku už zobrali na niekoľkých miestach. Používateľ môže v informačnom systéme vykonať mnoho akcií, napr. zmeniť skladbu, zmeniť zdroj skladby z USB na FM alebo Bluetooth zvuk, nastaviť cieľ navigácie, aktualizovať softvér infotainmentu prostredníctvom aktualizácie softvéru atď.
# 1) Zhromažďovanie nefunkčných požiadaviek:
Uvedieme zoznam úloh vykonávaných používateľom, ktoré sú súčasťou funkčných požiadaviek. Keď sú akcie používateľa zaznamenané v diagrame prípadov použitia UML (každý oválny), začneme príslušné otázky (každý obdĺžnik) týkajúce sa akcií každého používateľa. Odpovede na tieto otázky poskytnú naše nefunkčné požiadavky.
# 2) Kategorizácia nefunkčných požiadaviek:
Ďalším krokom je kategorizácia nefunkčných požiadaviek, ktoré sme identifikovali pomocou otázok. V tejto fáze môžeme skontrolovať možnú odpoveď a kategorizovať odpovede na možné nefunkčné kategórie alebo rôzne kvality.
Na obrázku nižšie vidíte možné atribúty kvality identifikované v odpovediach.
Funkčné vs. nefunkčné požiadavky
Už sme videli, čo sú funkčné a nefunkčné požiadavky a ako sú odvodené. Pozrime sa na hlavné rozdiely medzi funkčnými a nefunkčnými požiadavkami.
| Sl. č | Funkčné požiadavky (FR) | Nefunkčné požiadavky (NFR) |
|---|---|---|
| 7 | Funkčné požiadavky tvoria kostru implementácie softvérového systému | Nefunkčné požiadavky dopĺňajú systém SW tým, že pomáhajú funkčným požiadavkám držať spolu, ako sval. |
| jeden | Hovoria, čo by mal robiť systém. | Hovoria, čo by mal byť systém. |
| dva | Podrobne sú uvedené v dokumente Návrh systému. | Podrobne sú uvedené v dokumente Systémová architektúra. |
| 3 | Hovoria o správaní sa funkcie alebo funkcie. | Hovoria o pracovnom správaní celého systému alebo jeho súčasti, a nie o konkrétnej funkcii. |
| 4 | Používateľ odovzdá vstup a skontroluje, či je výstup správne zobrazený. | Keď používateľ zadá vstup, môžu NFR odpovedať na nasledujúce otázky: i) Koľko času trvá zobrazenie výstupu? ii) Je výstup konzistentný s časom? iii) Existujú ďalšie spôsoby, ako zadať vstupný parameter? iv) Aké ľahké je zadať vstupný parameter? |
| 5 | Vo webovej aplikácii by mal byť používateľ schopný prihlásiť sa pomocou overenia totožnosti FR | Koľko času vo webovej aplikácii trvá prihlásenie na webovú stránku, vzhľad a dojem z prihlasovacej stránky, jednoduché používanie webovej stránky atď., Sú súčasťou NFR. |
| 6 | Funkčné požiadavky sú odvodené najskôr od softvérových požiadaviek. | Nefunkčné požiadavky sú odvodené od funkčných požiadaviek. |
| 8 | Funkčné požiadavky môžu existovať bez nefunkčných požiadaviek. | Nefunkčné požiadavky nemôžu existovať bez funkčných požiadaviek. |
| 9 | Funkčná požiadavka poskytuje konkrétne informácie o prvku, Príklad , Profilová fotografia na Facebooku by mala byť viditeľná pri prihlásení. | Funkčná požiadavka môže mať veľa atribútov nefunkčných požiadaviek. Príklad, čas prihlásenia (výkon), vzhľad a vzhľad stránky profilu (použiteľnosť), počet používateľov, ktorí sa môžu súčasne prihlásiť (kapacita, výkon) |
| 10 | Odvodenie funkčných požiadaviek od SW je možné pre takmer všetky obchodné požiadavky | NFR sa často nestihnú zdokumentovať, pretože na FR sa nekladú príslušné otázky. |
| jedenásť | Implementácia funkčných požiadaviek sa zvyčajne vykonáva v jednom zostavení softvéru. | NFR sa implementujú počas celého životného cyklu projektu, kým sa nedosiahne požadované správanie. |
| 12 | Tie sú väčšinou viditeľné pre zákazníka. | Väčšinou ich zákazník nevidí, ale mohli by byť z dlhodobého hľadiska skúsení. Príklad, Použiteľnosť, výkon atď. Je možné vyskúšať iba z dlhodobého hľadiska, ale vôbec ich nie je viditeľné. |
Záver
Požiadavky tvoria základný stavebný kameň pre vývoj ľubovoľného softvérového systému. Je možné zostaviť systém s funkčnými požiadavkami, ale jeho schopnosti nie je možné určiť ani zmerať. Napriek tomu je veľmi dôležité mať kvalitné funkčné požiadavky odvodené z obchodnej požiadavky na vysoko kvalitný fungujúci softvérový systém.
Preto funkčné požiadavky určujú smer implementácie softvérového systému, ale nefunkčné požiadavky určujú kvalitu implementácie, s ktorou sa budú koncoví používatelia stretávať.
Odporúčané čítanie
- Ako otestovať špecifikáciu softvérových požiadaviek (SRS)?
- Funkčné testovanie vs. Nefunkčné testovanie
- Ako otestovať aplikáciu bez požiadaviek?
- Čo je analýza požiadaviek a zhromažďovanie v SDLC?
- 5 smrteľných chýb v riadení požiadaviek a ako ich prekonať
- Vlastnosti funkčných požiadaviek a nefunkčných požiadaviek
- Ako vytvoriť maticu sledovateľnosti požiadaviek (RTM): Príklad a vzorová šablóna
- Top 20+ najlepších nástrojov na správu požiadaviek (kompletný zoznam)