Co je to funkční požadavek v softwarovém inženýrství?

⚡ Chytré shrnutí

Funkční požadavky popisují každou službu, kterou musí softwarový systém nabízet, a zachycují vstupy, chování a výstupy, aby vývojáři, testeři a obchodní partneři sdíleli jednu ověřitelnou definici toho, co musí produkt skutečně dělat.

  • 📘 Definice: Funkční požadavek, nazývaný také funkční specifikace, uvádí, co musí systém dělat – vstupy, chování a výstupy, popsané z pohledu uživatele nebo firmy.
  • 📄 Rozsah dokumentu: Dokument s funkčními požadavky zahrnuje operace na obrazovce, logiku zpracování dat, sestavy, pracovní postupy, oprávnění a dodržování předpisů.
  • 🗂️ Běžné typy: Zpracování transakcí, obchodní pravidla, reporting, administrativní funkce, úrovně autorizace, audit trackrál, externí rozhraní a právní požadavky.
  • ???? Příklady: Ověřování přihlášení, zaznamenávání prodejů, sledování tržeb na základě rolí, integrace bankovního API a dodržování předpisů pro přístupnost – to vše je součástí funkčních požadavků.
  • 🆚 Nefunkční kontrast: Funkční požadavky popisují, co systém dělá; nefunkční požadavky popisují, jak dobře to dělá – výkon, bezpečnost a použitelnost.
  • (Tj. Osvědčené postupy: Udržujte požadavky podrobné, testovatelné a namapované na obchodní cíl a zjišťujte je prostřednictvím pohovorů a workshopů.

Funkční požadavky v softwarovém inženýrství

Co je to funkční požadavek?

A Funkční požadavek (FR) je popis služby, kterou musí software nabízet. Popisuje softwarový systém nebo jeho komponentu. Funkce je definována vstupy, chováním a výstupy. Může se jednat o výpočet, manipulaci s daty, obchodní proces nebo interakci s uživatelem, která definuje, co musí systém dělat. Funkční požadavky v softwarovém inženýrství se také nazývají Funkční specifikace.

Funkční požadavek sahá od potřeby zúčastněných stran na vysoké úrovni až po podrobnou matematickou specifikaci. Funkční software požadavky zachycují zamýšlené chování systému.

Co zahrnout do dokumentu funkčních požadavků

Zde je to, co by měl dokument s funkčními požadavky obsahovat:

Příklad funkčních požadavků

Příklad funkčních požadavků

Dokument s funkčními požadavky obvykle obsahuje:

  • Podrobnosti o provedených operacích na každé obrazovce
  • Logika zpracování dat, kterou musí systém aplikovat
  • Descriptiony systémových zpráv a dalších výstupů
  • Úplné informace o pracovních postupech, které systém provádí
  • Kdo má oprávnění vytvářet, upravovat nebo mazat data v systému
  • Jak systém splňuje příslušné regulační a compliance požadavky

Výhody funkčních požadavků

Hlavní výhody dobře napsaného dokumentu funkčních požadavků jsou:

  • Ověřuje, zda aplikace poskytuje všechny zadané funkce.
  • Definuje funkcionalitu systému a jeho subsystémů na jednom místě
  • V kombinaci s analýzou požadavků pomáhají funkční požadavky identifikovat chybějící potřeby a objasnit očekávané chování systému.
  • Chyby odhalené ve fázi požadavků se nejlevněji opravují
  • Podporuje cíle, úkoly a aktivity uživatelů

Typy funkčních požadavků

Mezi běžné kategorie funkčních požadavků patří:

  • Zpracování transakcí
  • Obchodní pravidla
  • Požadavky certifikátů
  • Požadavky na hlášení
  • Správní funkce
  • Úrovně autorizace
  • Audit Tracking
  • Externí rozhraní
  • Správa historických dat
  • Právní a regulační požadavky

Příklady funkčních požadavků

Níže jsou uvedeny praktické příklady funkčních požadavků:

  • Software bude automaticky ověřovat zákazníky v systému správy kontaktů ABC.
  • Prodejní systém by měl uživatelům umožnit zaznamenávat prodeje zákazníků.
  • Barva pozadí pro všechna okna v aplikaci musí být modrá s hexadecimální hodnotou RGB 0x0000FF.
  • Právo nahlížet do údajů o příjmech mají pouze zaměstnanci na vedoucích pozicích.
  • Softwarový systém se bude integrovat s bankovním API.
  • Softwarový systém musí splňovat Oddíl 508 požadavky na přístupnost.

Funkční vs. nefunkční požadavky

Zde jsou klíčové rozdíly mezi funkčními a nefunkčními požadavky v Softwarové inženýrství:

parametry Funkční požadavek Nefunkční požadavek
Co to je Sloveso Atributy
Požadavek Je to povinné Není to povinné
Typ snímání Je zachycen v případě použití. Je zachycen jako atribut kvality.
Konečný výsledek Funkce produktu Vlastnosti produktu
Zachycení Snadno zachytitelné Těžko zachytitelné
Objektivní Pomáhá vám ověřit funkčnost softwaru. Pomáhá vám ověřit výkon softwaru.
Oblast zaměření Zaměřte se na požadavky uživatele Soustředí se na očekávání uživatele.
Dokumentace Popište, co produkt dělá Popisuje, jak produkt funguje
Typ testování Funkční testování jako systém, integrace, end to end, API testování, Etc. Nefunkční testování, jako je výkon, stres, použitelnost, Testování zabezpečení, Etc.
Provedení testu Provedení testu se provádí před nefunkčním testováním. Po funkční zkoušce
Informace o výrobku Vlastnosti produktu Vlastnosti produktu

Nejlepší postupy pro psaní funkčních požadavků

Nejdůležitější osvědčené postupy pro psaní dokumentu s funkčními požadavky jsou:

  • Neslučujte dva požadavky do jednoho; každý požadavek udržujte podrobný.
  • Každý požadavek uveďte co nejúplnější a nejpřesnější.
  • V dokumentu napište všechny technické požadavky.
  • Propojte každý požadavek s cíli a principy, které vedou k úspěšnému dodávání softwaru.
  • Zjišťujte požadavky prostřednictvím pohovorů, workshopů a neformálních rozhovorů.
  • Zdokumentujte každé známé a ověřené omezení, které podstatně ovlivňuje požadavek.
  • Zaznamenejte si do dokumentu každý předpoklad.

Časté chyby při psaní funkčních požadavků

Mezi běžné chyby, kterých se dopouštíme při vytváření dokumentu funkčních požadavků, patří:

  • Přidávání neodůvodněných dodatečných informací, které mate vývojáře
  • Vynechání detailů, které vývojáři potřebují k vytvoření funkce.
  • Pravidla míchání, příklady, scoping prohlášení nebo cíle do samotného požadavku.
  • Vynechání informací, které jsou nezbytné pro úplné a přesné vyjádření požadavku.
  • Obhajoba existujícího požadavku, když dorazí žádost o změnu, namísto nalezení správné odpovědi.
  • Požadavky na psaní, které nejsou mapovány na žádný cíl nebo princip.

Nejčastější dotazy

Nástroje umělé inteligence shlukují poznámky z pohovorů, generují koncepty uživatelských příběhů, označují nejednoznačný jazyk a detekují duplikáty napříč velkými sadami požadavků. Obchodní analytici stále ověřují každý návrh oproti skutečným potřebám zainteresovaných stran, než se dostane do schválené základní úrovně.

Copilot a GPT vytvářejí návrhy uživatelských příběhů, kritéria přijetí a shall-statementy z krátkých výzev. Obchodní analytik upraví každý výstup z hlediska testovatelnosti a před formálním přezkoumáním potvrdí soulad s obchodními cíli.

Obchodní požadavek uvádí důvod existence projektu, například růst tržeb nebo dodržování předpisů. Funkční požadavek uvádí, co musí systém udělat, aby dosáhl daného výsledku, například ověřit platbu nebo vygenerovat zprávu.

Použijte jasný podmět, slovo „shall“ a jednu testovatelnou akci pro každý příkaz. Vyhněte se nejednoznačným slovům jako „fast“ a zahrněte jedno chování, aby bylo možné požadavek otestovat jednou kontrolou „pass“ nebo „fail“.

EARS, Easy Approach to Requirements Syntax, nabízí pět šablon: všudypřítomné, událostmi řízené, stavy řízené, volitelné funkce a nežádoucí chování. Každá z nich vynucuje testovatelnou strukturu, například Když TRIGGER, systém by měl REAGOVAT.

Specifikace softwarových požadavků je hlavní dokument popisující, co musí systém dělat. Funkční požadavky tvoří největší část, spolu s rozhraními, nefunkčními požadavky, případy užití a omezeními.

Funkční požadavky řídí testovací případy v systémovém, integračním, end-to-end, API a uživatelském akceptačním testování. Každý požadavek se mapuje na alespoň jeden testovací případ a požadavky Traceability Matrix potvrzuje pokrytí před vydáním.

Agilní týmy vyjadřují funkční požadavky jako uživatelské příběhy ve formátu „Jako role chci schopnost, takže tato hodnota“. Kritéria přijetí připojená k příběhu promění požadavek v testovatelnou definici hotového.

Shrňte tento příspěvek takto: