features functional requirements
Tento výukový program vysvětluje typy, funkce, srovnání funkčních a nefunkčních požadavků a obchodní a funkční požadavky s příklady:
Funkční požadavky definují, co by měl softwarový systém dělat. Definuje funkci softwarového systému nebo jeho modulu. Funkčnost se měří jako sada vstupů do testovaného systému na výstup ze systému.
Implementace funkčních požadavků v systému je plánována ve fázi návrhu systému, zatímco v případě nefunkčních požadavků je plánována v dokumentu System Architecture. Funkční požadavek podporuje generování nefunkčních požadavků.
Co se naučíte:
Funkční požadavky a nefunkční požadavky
Funkční požadavky
Pojďme pochopit, jaké jsou funkční požadavky pomocí příkladů -
Příklad: V projektu Automotive ADAS může být funkčním požadavkem systému prostorového zobrazení „Zadní kamera by měla detekovat hrozbu nebo objekt“. Nefunkčními požadavky zde mohou být „jak rychle by se výstraha uživateli měla zobrazit, když je detekována hrozba kamerovými senzory“.
Vezměte si další příklad projektu Infotainment systems. Uživatel zde aktivuje Bluetooth z HMI a zkontroluje, zda je Bluetooth povolen či nikoli. Poznámka , ostatní služby Bluetooth se povolí (od šedé po tučné), když uživatel povolí Bluetooth.
což je nejlepší poskytovatel e-mailu
Takže funkční požadavky hovoří o konkrétním výsledku systému, když na nich uživatel provede úkol. Na druhou stranu nefunkční požadavek udává celkové chování systému nebo jeho součásti, nikoli funkce.
Druhy funkčních požadavků
Funkční požadavky mohou zahrnovat následující komponenty, které lze měřit jako součást funkčního testování:
# 1) Interoperabilita: Požadavek popisuje, zda je softwarový systém interoperabilní mezi různými systémy.
Příklad: Pokud jde o funkční požadavek Bluetooth v informačním systému automobilu, když uživatel spáruje chytrý telefon se systémem Android s technologií Bluetooth a informačním systémem založeným na QNX, měli bychom být schopni přenést telefonní seznam do informačního systému nebo streamovat hudbu z našeho telefonního zařízení do informačního systému.
Interoperabilita tedy kontroluje, zda je komunikace mezi dvěma různými zařízeními možná nebo ne.
Další příklad pochází ze systémů e-mailových služeb, jako je Gmail. Gmail umožňuje import e-mailů z jiného serveru pro výměnu pošty, jako je Yahoo.com nebo Rediffmail.com. To je možné z důvodu interoperability mezi e-mailovými servery.
# 2) Zabezpečení: Funkční požadavek popisuje bezpečnostní aspekt softwarových požadavků.
Příklad: Služby založené na kybernetické bezpečnosti v kamerovém systému ADAS pro prostorový pohled, který využívá síť CAN (Controller Area Network), která chrání systém před bezpečnostní hrozbou.
Další příklad pochází ze sociální sítě Facebook . Data uživatele by měla být zabezpečená a nesmí být předávána cizím osobám. Doufáme, že tento příklad Facebooku poskytne čtenářům širší pohled na bezpečnost kvůli nedávnému výskytu narušení dat na Facebooku a důsledkům, kterým Facebook čelí.
# 3) Přesnost: Přesnost definuje, že data zadaná do systému jsou správně vypočítána a použita systémem a že výstup je správný.
Příklad: V síti Controller Area Network, když je hodnota signálu CAN přenášena po sběrnici CAN ECU (viz. Jednotka ABS, jednotka HVAC, jednotka sdruženého přístroje atd.), Bude jiná ECU schopna identifikovat, zda jsou odeslaná data správná nebo ne prostřednictvím kontroly CRC.
Další příklad může pocházet z řešení online bankovnictví. Když uživatel obdrží fond, přijatá částka by měla být přesně připsána na účet a nepřijímá se žádná změna v přesnosti.
# 4) Soulad: Funkční požadavky na shodu potvrzují, že vyvinutý systém vyhovuje průmyslovým standardům.
Příklad: Zda jsou funkce profilů Bluetooth (viz. Streamování zvuku přes A2DP, telefonní hovor přes HFP) kompatibilní s verzemi profilů vydání Bluetooth SIG.
Další příklad může to být hra Apple Car v systému infotainmentu automobilu. Aplikace v infotainmentu získá certifikát od Jablko pokud jsou všechny předpoklady uvedené na webu Apple splněny zařízeními Car Play třetích stran (v tomto případě infotainment).
Další příklad může být z webové aplikace pro systém prodeje jízdenek. Web by měl dodržovat pokyny pro kybernetickou bezpečnost a být v souladu s World Wide Web z hlediska přístupnosti.
Příklad formuláře požadavku:
Na několika příkladech jsme již viděli, jaký je funkční požadavek. Podívejme se nyní, jak by vypadal funkční požadavek, kdyby byl integrován do nástrojů pro správu požadavků, jako je IBM DOORS. Při dokumentaci funkčního požadavku v nástroji pro správu požadavků je třeba vzít v úvahu několik atributů.
Níže je třeba vzít v úvahu několik atributů:
- Typ objektu: Tento atribut vysvětluje, která část dokumentu s požadavky je součástí tohoto atributu. Mohly by to být nadpis, vysvětlení, požadavek atd. Většinou se pro implementaci a testování považuje část „Požadavek“, zatímco nadpisy a vysvětlivky se používají jako podpůrné popisy požadavků pro lepší pochopení.
- Odpovědná osoba: Autor, který dokumentoval požadavek v nástroji pro správu požadavků.
- Název projektu / systému: Projekt, na který se požadavek vztahuje, například, „Infotainment Systems for XYZ OEM (Original Equipment Manufacturer) a automobile company or Web application for ABC banking limited company“.
- Číslo verze požadavku: Toto pole / atribut upozorňuje na číslo verze požadavku, pokud požadavek prošel několika úpravami kvůli aktualizacím zákazníka nebo změnám v designu systému.
- ID požadavku: Tento atribut uvádí jedinečné ID požadavku. ID požadavku se používá při snadném sledování požadavků v databázi a také při efektivním mapování požadavků v kódu. Lze jej také použít k poskytnutí odkazu na požadavky při protokolování závad v nástrojích pro sledování chyb.
- Popis požadavku: Tento atribut je jedním z nejdůležitějších atributů, které vysvětlují požadavek. Přečtením tohoto atributu by inženýr mohl pochopit požadavek.
- Stav požadavku: Atribut stavu požadavku říká o stavu požadavku v nástroji pro správu požadavků, tj. Zda je projekt přijat, pozastaven, odmítnut nebo odstraněn.
- Komentáře: Tento atribut poskytuje odpovědné osobě nebo správci požadavků možnost zdokumentovat jakýkoli komentář k požadavku. Příklad: možným komentářem k funkčnímu požadavku by mohla být „závislost na softwarovém balíčku třetí strany, který by požadavek implementoval“.
Snímek z DVEŘÍ
Odvození funkčních požadavků z obchodních požadavků
To je již zahrnuto v části „ Odvození funkčních požadavků z obchodních požadavků ' pod Analýza požadavků článek.
Obchodní požadavky vs. funkční požadavky
Tento rozdíl je volně zahrnut v Analýza požadavků článek. Pokusíme se však o to zde v následující tabulce zvýrazněte několik dalších bodů:
| Sl. Ne. | Obchodní požadavky | Funkční požadavky |
|---|---|---|
| 7 | Například, v systému online bankovnictví by obchodní požadavek mohl být „Jako uživatel bych měl být schopen získat výpis z hotovostní transakce“. | Funkčním požadavkem v tomto systému online bankovnictví může být: „Když uživatel zadá časové období v dotazu na transakci, použije tento vstup Server a webová stránka získá potřebné údaje o hotovostních transakcích.“ |
| 1 | Obchodní požadavky říkají „jaký“ aspekt požadavku zákazníka. Příklad, Co by mělo být viditelné pro uživatele po přihlášení uživatele. | Funkční požadavky říkají „jak“ aspekt obchodních požadavků. Příklad, Jak by měla webová stránka zobrazovat přihlašovací stránku uživatele, když se uživatel autentizuje. |
| dva | Obchodní požadavky identifikují obchodní analytici. | Funkční požadavky vytváří / odvozuje vývojář / softwarový architekt |
| 3 | Zdůrazňují přínos pro organizaci a souvisí s obchodními cíli. | Jejich cílem je plnění požadavků zákazníka. |
| 4 | Obchodní požadavky jsou od zákazníka. | Funkční požadavky jsou odvozeny od softwarových požadavků, což je zase odvozeno od obchodních požadavků. |
| 5 | Obchodní požadavky nejsou testovány přímo Software Test Engineers. Většinou jsou testovány zákazníkem. | Funkční požadavky jsou testovány inženýry Software Test a obecně nejsou testovány zákazníky. |
| 6 | Obchodní požadavek je dokument požadavku na vysoké úrovni. | Funkčním požadavkem je podrobný dokument technických požadavků. |
Nefunkční požadavek
Nefunkční požadavek říká spíše o „co by měl být systém“ než o „co by měl systém dělat“ (funkční požadavek). Většinou jsou odvozeny z funkčních požadavků na základě vstupů od zákazníka a dalších zúčastněných stran. Podrobnosti o implementaci nefunkčních požadavků jsou dokumentovány v dokumentu System Architecture.
Nefunkční požadavky vysvětlují kvalitativní aspekty systému, který má být konstruován, viz. výkon, přenositelnost, použitelnost atd. Nefunkční požadavky, na rozdíl od funkčních požadavků, jsou implementovány postupně v každém systému.
URPS (Použitelnost, spolehlivost, výkon a podpora) z FURPS (Funkčnost, použitelnost, spolehlivost, výkon a podpora) atributy kvality, které se v IT průmyslu široce používají k měření kvality vývojáře softwaru, jsou pokryty nefunkčními požadavky. Kromě toho existují i další atributy kvality (podrobnosti v další části).
Wikipedia nazývá nefunkční požadavek někdy jako „ility“, kvůli přítomnosti různých atributů kvality, jako je přenositelnost a stabilita.
Druhy nefunkčních požadavků
Nefunkční požadavky se skládají z níže uvedených podtypů (neúplné):
# 1) Výkon:
Typ atributu výkonu nefunkčního požadavku měří výkon systému. Příklad: V systému prostorového zobrazení ADAS by se „pohled zadní kamery měl zobrazit do 2 sekund po spuštění zapalování vozu“.
Další příklad výkonu může být z informačního a navigačního systému. 'Když uživatel přejde na obrazovku Navigace a zadá cíl, měla by se trasa vypočítat během' X 'sekund.' Ještě jeden příklad z přihlašovací stránky webové aplikace. 'Čas potřebný k načtení stránky profilu uživatele po přihlášení.'
Pamatujte, že měření výkonu systému se liší od měření zátěže. Během testování načítání načítáme procesor a RAM systému a kontrolujeme propustnost systému. V případě výkonu testujeme propustnost systému za podmínek normálního zatížení / stresu.
# 2) Použitelnost :
Použitelnost měří použitelnost vyvíjeného softwarového systému.
Například , byla vyvinuta mobilní webová aplikace, která vám poskytne informace o instalatérech a dostupnosti elektrikáře ve vaší oblasti.
Vstup do této aplikace je PSČ a rádius (v kilometrech) od vaší aktuální polohy. Chcete-li však zadat tato data, pokud uživatel musí procházet více obrazovkami a možnost zadávání dat se zobrazuje v malých textových polích, která nejsou uživateli snadno viditelná, pak tato aplikace není uživatelsky přívětivá, a proto bude použitelnost aplikace velmi nízký.
# 3) Udržovatelnost :
Udržovatelnost softwarového systému je snadnost údržby systému. Pokud je střední doba mezi poruchami (MTBF) nízká nebo střední doba opravy (MTTR) je vysoká pro vyvíjený systém, pak je udržovatelnost systému považována za nízkou.
Udržovatelnost se často měří na úrovni kódu pomocí cyklomatické složitosti. Cyklomatická složitost říká, že čím je kód méně složitý, tím snazší je údržbu softwaru.
Příklad: Byl vyvinut softwarový systém, který má vysoký počet mrtvých kódů (kódy nepoužívané jinými funkcemi nebo moduly), velmi složitý kvůli nadměrnému používání podmínky if / else, vnořených smyček atd., Nebo pokud je systém obrovský se spuštěnými kódy do mnoha milionů řádků kódů a bez řádných komentářů. Takový systém má nízkou údržbu.
Další příklad může být online nakupování. Pokud je na webu mnoho externích odkazů, aby měl uživatel přehled o produktu (ušetří se tak paměť), pak je udržovatelnost tohoto webu nízká. Je to proto, že pokud se změní odkaz na externí webovou stránku, musí být také aktualizován na webových stránkách pro online nakupování a to příliš často.
# 4) Spolehlivost :
Spolehlivost je dalším aspektem dostupnosti. Tento atribut kvality zdůrazňuje dostupnost systému za určitých podmínek. Měří se jako MTBF stejně jako udržovatelnost.
Příklad: Vzájemně se vylučující funkce, jako je zadní kamera a přívěs v kamerovém systému ADAS pro prostorový výhled, by měly v systému spolehlivě fungovat bez vzájemného rušení. Když uživatel vyvolá funkci přívěsu, zadní pohled by neměl zasahovat a naopak, protože obě funkce přistupují k zadní kameře automobilu.
otázky týkající se rozhovoru unix pro podporu produkce
Další příklad z online systému pojistných událostí. Když uživatel zahájí hlášení reklamací a poté nahraje příslušné účty výdajů, měl by systém dát dostatek času na dokončení nahrávání a neměl by proces nahrávání rychle zrušit.
# 5) Přenositelnost:
Přenositelností se rozumí schopnost softwarového systému pracovat v jiném prostředí, pokud základní závislý rámec zůstane stejný.
Příklad: Softwarový systém / komponenta v informačním a zábavním systému vyvinutém (viz služba Bluetooth nebo multimediální služba) pro výrobce automobilů by měl umožňovat použití v jiném informačním a zábavním systému s malou nebo žádnou změnou kódu, i když tyto dva informační a zábavní systémy jsou zcela odlišné .
Vezměme si další příklad z WhatsApp. Službu zasílání zpráv je možné nainstalovat a používat na IOS, Android, Windows, Tablet, Laptop a Telefon.
# 6) Podpora:
Provozovatelnost softwarového systému je schopnost servisního / technického odborníka instalovat softwarový systém v prostředí v reálném čase, monitorovat systém za chodu, identifikovat jakékoli technické problémy v systému a poskytnout řešení k jeho vyřešení.
Provozuschopnost je možná, pokud je systém vyvinut pro usnadnění provozuschopnosti.
Příklad: Poskytování pravidelných vyskakovacích oken s upozorněním na aktualizaci softwaru, poskytování mechanismu protokolování / trasování k ladění problémů, automatické zotavení po selhání pomocí mechanismu vrácení zpět (vrácení softwarového systému do předchozího stavu provozních podmínek).
Další příklad z Rediffmail. Když došlo k aktualizaci ve verzi webové poštovní služby, systém umožnil uživateli přepnout na novější verzi poštovního systému a zachovat starší po několik měsíců. To také zvyšuje uživatelský komfort.
# 7) Adaptabilita:
Adaptabilita systému je definována jako schopnost softwarového systému přizpůsobit se změnám v prostředí bez jakékoli změny jeho chování.
Příklad: Protiblokovací brzdový systém v automobilu by měl fungovat standardně za všech povětrnostních podmínek (za tepla nebo za studena). Další příklad může to být operační systém Android. Používá se v různých typech zařízení, viz. Smartphony, tablety a informační a zábavní systémy a jsou vysoce adaptabilní.
Kromě výše uvedených 7 nefunkčních požadavků máme mnoho dalších, jako například:
Přístupnost, zálohování, kapacita, shoda, integrita dat, uchovávání dat, závislost, nasazení, dokumentace, trvanlivost, efektivita, vykořisťovatelnost, rozšiřitelnost, správa poruch, tolerance chyb, interoperabilita, upravitelnost, provozuschopnost, soukromí, čitelnost, hlášení, odolnost, opakovaná použitelnost, Robustnost, škálovatelnost, stabilita, testovatelnost, propustnost, transparentnost, integrovatelnost.
Pokrytí všech těchto nefunkčních požadavků je mimo rozsah tohoto článku. Můžete si však přečíst více o těchto typech nefunkčních požadavků v Wikipedia.
Odvození nefunkčních požadavků z funkčních požadavků
Nefunkční požadavky lze odvodit mnoha způsoby, ale nejlepší a většina průmyslově vyzkoušených a ověřených způsobů je z funkčních požadavků.
Vezměme si příklad z našich informačních a zábavních systémů, který jsme již v tomto článku vzali na několika místech. Uživatel může na informačním systému provádět mnoho akcí, viz. změnit skladbu, změnit zdroj skladby z USB na FM nebo Bluetooth audio, nastavit cíl navigace, aktualizovat software infotainmentu prostřednictvím aktualizace softwaru atd.
# 1) Shromažďování nefunkčních požadavků:
Uvedeme seznam úkolů prováděných uživatelem, což je součást funkčních požadavků. Jakmile jsou akce uživatele zaznamenány v diagramu případů použití UML (každý ovál), začneme relevantní otázky (každý obdélník) o akcích každého uživatele. Odpovědi na tyto otázky poskytnou naše nefunkční požadavky.
# 2) Kategorizace nefunkčních požadavků:
Dalším krokem je kategorizace nefunkčních požadavků, které jsme identifikovali pomocí otázek. V této fázi můžeme zkontrolovat možnou odpověď a kategorizovat odpovědi na možné nefunkční kategorie nebo různé kvality.
Na obrázku níže vidíte možné atributy kvality identifikované z odpovědí.
Funkční vs. nefunkční požadavky
Už jsme viděli, jaké jsou funkční a nefunkční požadavky a jak jsou odvozeny. Podívejme se na hlavní rozdíly mezi funkčními a nefunkčními požadavky.
| Sl. Ne | Funkční požadavky (FR) | Nefunkční požadavky (NFR) |
|---|---|---|
| 7 | Funkční požadavky tvoří kostru implementace softwarového systému | Nefunkční požadavky doplňují SW systém tím, že pomáhají funkčním požadavkům držet pohromadě, jako sval. |
| 1 | Říkají, co by měl systém dělat. | Říkají, jaký by měl být systém. |
| dva | Jsou podrobně popsány v dokumentu Návrh systému. | Jsou podrobně popsány v dokumentu architektury systému. |
| 3 | Mluví o chování funkce nebo funkce. | Mluví o pracovním chování celého systému nebo jeho součásti, nikoli o konkrétní funkci. |
| 4 | Uživatel předá vstup a zkontroluje, zda je výstup správně zobrazen. | Když uživatel předá vstup, mohou NFR odpovědět na následující otázky: i) Kolik času trvá zobrazení výstupu? ii) Je výstup konzistentní s časem? iii) Existují další způsoby předání vstupního parametru? iv) Jak snadné je předat vstupní parametr? |
| 5 | Ve webové aplikaci by měl mít uživatel možnost přihlásit se pomocí ověřování na FR | Kolik času ve webové aplikaci trvá přihlášení do webu, vzhled a chování přihlašovací stránky, snadné použití webové stránky atd. Jsou součástí NFR |
| 6 | Funkční požadavky jsou odvozeny nejprve od softwarových požadavků. | Nefunkční požadavky jsou odvozeny z funkčních požadavků. |
| 8 | Funkční požadavky mohou existovat bez nefunkčního požadavku. | Nefunkční požadavky nemohou existovat bez funkčních požadavků. |
| 9 | Funkční požadavek poskytuje konkrétní informace o prvku, Příklad „Profilová fotka na Facebooku by měla být viditelná při přihlášení. | Funkční požadavek může mít mnoho atributů nefunkčních požadavků. Příklad, čas přihlášení (výkon), vzhled a chování stránky profilu (použitelnost), počet uživatelů, kteří se mohou současně přihlásit (kapacita, výkon) |
| 10 | Odvození funkčních požadavků z požadavků SW je možné téměř pro všechny obchodní požadavky | NFR se často nepodaří zdokumentovat, protože na FR se nekladou relevantní otázky. |
| jedenáct | Implementace funkčního požadavku se obvykle provádí v jednom sestavení softwaru. | NFR jsou implementovány během celého životního cyklu projektu, dokud není dosaženo požadovaného chování. |
| 12 | Ty jsou pro zákazníka většinou viditelné. | Ty většinou nejsou pro zákazníka viditelné, ale mohly by být dlouhodobě zkušené. Příklad, Použitelnost, výkon atd. Lze zaznamenat pouze z dlouhodobého hlediska, ale vůbec jej nelze vidět. |
Závěr
Požadavky tvoří základní stavební kámen pro vývoj jakéhokoli softwarového systému. Je možné vybudovat systém s funkčními požadavky, ale jeho schopnosti nelze určit ani měřit. Přesto je velmi důležité mít kvalitní funkční požadavky odvozené z obchodního požadavku na vysoce kvalitní funkční softwarový systém.
Funkční požadavky tedy udávají směr implementace softwarového systému, ale nefunkční požadavky určují kvalitu implementace, se kterou se budou koncoví uživatelé setkat.
Doporučené čtení
- Jak otestovat specifikaci softwarových požadavků (SRS)?
- Funkční testování vs. nefunkční testování
- Jak otestovat aplikaci bez požadavků?
- Co je analýza požadavků a shromažďování v SDLC?
- 5 smrtelných chyb ve správě požadavků a jak je překonat
- Vlastnosti funkčních požadavků a nefunkčních požadavků
- Jak vytvořit matici sledovatelnosti požadavků (RTM): Příklad a vzorová šablona
- Top 20+ nejlepších nástrojů pro správu požadavků (kompletní seznam)