V procesu vývoje výrobku, jedním z důležitých aspektů úspěchu projektu je získat požadavky správně. A mnoho projektů selže, protože zúčastněné strany nechápou rozdíl mezi obchodními požadavky a funkčními požadavky.
konečný úspěch a neúspěch jakéhokoli projektu závisí na kvalitě požadavků. Ačkoli je to zřídka uvedeno tak jednoduše, většina softwarových projektů selže kvůli menšímu důrazu na správu požadavků.
V září 1999 NASA ztratila $125 milionů Mars Climate Orbiter, když se pokusil vstoupit na oběžnou dráhu, jen 100 kilometrů příliš blízko Marsu. Mise selhala kvůli špatnému řízení požadavky: nebylo diskutováno dříve ve fázi, zda navigační software‘ požadované metrické jednotky nebo imperiální jednotky.
výsledek: nekompatibilní SPECIFIKACE; systém řízení polohy byl specifikován pomocí imperiálních jednotek, ale jeho navigační software používal metrické jednotky.
Tak, jak se požadavky správné a jejich využití v plném rozsahu, je rozhodující pro úspěch projektu.
v oblasti vývoje softwarových produktů se význam a význam slova „požadavky“ zvyšuje s rostoucí popularitou metodik agilního vývoje softwaru. Ani jeden z bodů uvedených v Agilní Manifest vysvětluje metodiku, jak ten, který hodnoty:
„Pracovní software, přes komplexní dokumentace“
Získání požadavky práva je rozhodující, zda pracujete v Agilní nebo Vodopád metodiky.
- Podnikání vs Funkční Požadavky – Definice a jeho Druhy
- jaké jsou obchodní požadavky
- Obchodní Požadavky Příklad
- dokument o obchodních požadavcích (BRD)
- Obchodní Požadavky Dokumentu, Příklad – Proč Chrysler PT Cruiser byl Označen Hrdina na Nulu‘
- Tipy pro Psaní Obchodní Požadavky Dokumentu, Šablony (BRD)
- Jaké jsou Funkční Požadavky
- Funkční Požadavky Příklad
- Řešení, že Čisté Řešení Dodána
- dokument o funkčních požadavcích
- Tipy pro Psaní Funkčních Požadavků Šablony Dokumentu (FRD)
- Obchodní Požadavky vs Funkční Požadavky: Klíčové Problémy v Psaní Dokumentu
- Co jsou non-funkční požadavky?
- Obchodní Požadavky vs Funkční Požadavky – Závěr
Podnikání vs Funkční Požadavky – Definice a jeho Druhy
předtím, Než jsme kopat hlouběji do Obchodní Požadavky vs Funkční Požadavky pojďme se podívat na definice a typy.
Podle Mezinárodní Institut Obchodní Analýzy, požadavek je:
- podmínku nebo schopnosti potřebné zúčastněných stran, k vyřešení problému nebo dosažení cíle.
- podmínka nebo schopnost, která musí být splněna, nebo ovládaný systém nebo součást systému uspokojit smlouvě, standardu, specifikaci nebo dalších formálně uložených dokumentů.
- zdokumentovaný znázornění stavu nebo schopnosti jako v (1) nebo (2)
na Základě problémové domény a metodiky, které Obchodní Analytik (BA) pracuje s následující jsou různé požadavky, z nichž nejdůležitější jsou: obchodní požadavky a funkční požadavky.
V tomto blogu, budeme zkoumat rozdíl mezi business požadavky a funkční požadavky. Je nezbytné pochopit rozdíl, abychom nabídli podnikání ideální řešení, které se o problém skutečně postará.
jaké jsou obchodní požadavky
proč klient potřebuje aplikaci?
tyto informace mohou pro mnohé znít zbytečně, protože klient je připraven zaplatit za vytvoření aplikace. Tak, proč by vám mělo záležet na tom, abyste dostali důvody?
No, pokud jste vášnivý o budování kvalitních výrobků a poskytování bezproblémové zkušenosti pro své klienty, pak byste se měli starat o to, ‚proč‘, stejně jako vy o tom, ‚co‘ a ‚jak se má.“
a když se začnete soustředit na část „proč“ projektu, znamená to, že se staráte o obchodní požadavky.
respektujeme vaše soukromí. Vaše informace jsou v bezpečí.
Obchodní Požadavky na životní cyklus vývoje softwaru se zabývá high-level požadavky, nebo chce organizace, která umožňuje podnikání k dosažení svých konečných cílů, vize a cíle.
obvykle popisují, co by měl systém nebo řešení dělat. Dávají rozsah obchodní potřeby nebo problém, který by měl být řešen konkrétním projektem nebo úkolem.
Obchodní Požadavky Příklad
ParcelKiosk je jedním z našich klientů, kteří se k nám přiblížil, aby si webová aplikace, navržen a vyvinut s cílem nabídnout lepší služby doručování balíků zákazníkům. Když se k nám přiblížili, zahájili jsme diskusi s důležitým parametrem: analýzou obchodních potřeb.
co si myslíte, že obchodní požadavek může být pro tuto službu doručování balíků web app?
můžete přijít s důležitým parametrem, jako je zabezpečení. Nicméně, i když bezpečnost je životně důležitým faktorem, není to obchodní požadavek. Nechcete stavět službu jako ParcelKiosk bez bezpečnosti v mysli, ale vytvoření služby jen kvůli zajištění bezpečnosti-není konečný cíl.
a co propojení řady kurýrních služeb a zákazníků?
to dává lepší smysl jako obchodní požadavek ve srovnání s bezpečností, protože popisuje, co služba udělá. Je to však důvod pro vytvoření webové služby, nebo je to opravdu funkce služby?
Zde jsou některé možné důvody (obchodních požadavků) vybudovat ParcelKiosk:
- Nabízejí chytřejší řešení pro měření, zvolte, a loď pozemků,
- Poskytují možnosti sledovat a spravovat své dodávky a pick-up služby
- On čas dodání a zpětné vazby od zákazníků
vidíte rozdíl mezi připojením řadou kurýrních služeb a zákazníky nebo bezpečnost a aktuální obchodní požadavky?
zde lze uvést následující body w. r. t obchodní požadavky:
- obchodní požadavky jsou vždy psány z pohledu klienta.
- jedná se o široké systémové požadavky na vysoké úrovni, ale přesto zaměřené na detaily.
- nejedná se o organizační cíle, ale o pomoc organizaci při dosahování jejích cílů. Splněním těchto obchodních požadavků organizace dosahuje svých širokých cílů.
nyní je zcela jasné, že obchodní požadavky vysvětlují „proč“ část projektu: „Proč“ konkrétní projekt musí být postaven, tj. jaké výhody chce organizace dosáhnout naplněním konkrétního projektu.
dokument o obchodních požadavcích (BRD)
dokument o obchodních požadavcích popisuje obchodní potřeby na vysoké úrovni. Primární cílovou skupinou BRD je zákazník a uživatelé. Obchodní požadavky jsou zdokumentovány v BRD. Dobře napsaný dokument o obchodních požadavcích pomáhá dosáhnout požadovaného cíle budování úspěšného produktu ve stanovené lhůtě.
má následující prvky:
- vize projektu
- Cíle projektu
- Kontextu nebo pozadí projektu
- Rozsah projektu
- Zúčastněných stran identifikace
- Podrobné Obchodní Požadavky
- Rozsah řešení
- Projekt omezení: Časový Rámec, Náklady na Projekt, a Dostupných zdrojů,
Obchodní Požadavky Dokumentu, Příklad – Proč Chrysler PT Cruiser byl Označen Hrdina na Nulu‘
Chrysler Group se nezaměřuje tolik na BRD a šel dopředu s výrobou jejich PT Cruiser, což má za následek mnoho bolesti hlavy pro organizaci. Pojďme se podívat na to, jak jejich obchodní požadavky dokument selhal:
- identifikace zúčastněných stran: skupina Chrysler identifikovala většinu zúčastněných stran docela dobře. Byli na palubě s prodejci a produkčním týmem PT Cruiser. Nicméně, dva důležité zúčastněné strany, které vynechal zahrnuty koncový zákazník nákup vozidla a prodejci Křižník.
- omezení projektu: Chrysler odvedl dobrou práci, pokud jde o zúčastněné strany na nejvyšší úrovni, které dodávají a dohlížejí na stavbu. Co jim však chybělo, bylo zpochybnění časové osy výroby, odpovědi na dotazy zákazníků nebo prodejců, jako je cena, dostupnost modelu a poptávka.
Předpokládejme, že Chrysler BRD zahrnuty všechny požadavky zúčastněných subjektů, nepředvídané zpoždění v dodání produktu (cíl dodávat automobily, obchodní zastoupení tím, 2001) mohl být houpal v dostatečném předstihu výroby a potřeby koncových uživatelů by byly oprávněné.
Tipy pro Psaní Obchodní Požadavky Dokumentu, Šablony (BRD)
Nyní, když máte základní znalosti co je BRD, který by měl splnit, můžete postupujte podle níže uvedené tipy k ujistěte se, že napsat vynikající obchodní požadavky dokumentu.
- Praxe silné požadavky elicitaci
- Používat jednoduchý jazyk bez pasivní hlas a žargon
- Výzkum minulých projektů
- Ověření dokumentace
- Integrovat vizuální
Jaké jsou Funkční Požadavky
Funkční Požadavky, jak název napovídá, popisovat funkce softwaru nebo produktu. Jedná se o funkce, které musí systém provádět, aby splnil obchodní požadavky.
zahrnují technické detaily, výpočty, manipulaci a zpracování dat a další konkrétní funkce, které charakterizují, čeho by měl rámec dosáhnout.
Pokud nemáte jasné funkční požadavky pochopit formalita projektu, v průběhu projektu, vám bude schopen odpovědět, zda rozhodnutí vývoj/design/testování týmů jsou správné.
„pokud nenapíšete specifikaci, je to největší zbytečné riziko, které v softwarovém projektu berete.“~ Joel Spolsky
pokud je funkční detail špatně přizpůsoben obchodním cílům, mohlo by to mít za následek selhání projektu.
Funkční Požadavky Příklad
Jeden z velkých FMCG hráči přiblížil Čisté Řešení pro mobilní vývoj aplikací projekt, který by mohl zlepšit efektivitu svého dodavatelského řetězce.
tento gigant FMCG zahájil projekt v roce 2001, jehož cílem bylo posílit postavení venkovských žen tím, že jim vytvoří příležitosti k prodeji produktů a vydělávání na živobytí.
klient chtěl náš projektový tým k re-dělat své stávající mobilní aplikace způsobem, který by automatizovat jejich dodavatelského řetězce a proces objednávání tím, že venkovské ženy a distributorů na jednom digitální platformu.
jejich cílem bylo zlepšit míru přijetí, digitálně umožnit podnikatelům a vyřešit tření na stávající cestě zákazníků (to vše jsou obchodní požadavky).
pokud jde o funkční požadavky, začali jsme s klientem diskutovat o požadovaných funkcích aplikace, které byly:
- Integrace s třetími-party dodavatelů
- Real-time stock aktualizace
- Objednávky
klient předpokládat, že tyto vlastnosti by mělo stačit k vyřešení tření v aktuální cesta zákazníka, čímž se zlepšuje míra přijetí.
Nicméně, zatímco diskutovat o funkčních požadavků s klientem, jsme si uvědomili, že pokud budeme identifikovat tření ve stávající zákazník cesta a opatření digitální gramotnosti úrovně pro nové uživatele app, rozvoj aplikace by bylo zbytečné.
Řešení, že Čisté Řešení Dodána
Jsme aplikovali přístupu Design thinking a provedla etnografický výzkum k posouzení podnikatelů digitální připravenost a pochopit mezery v cestě stávajícím uživatelům aplikace.
strávili jsme den se všemi zúčastněnými stranami, abychom dále identifikovali jejich problémy.
pomocí přístupu Design Thinking jsme byli schopni zjistit, jaké funkce by měly v nové aplikaci jít. Tento přístup navíc přiměl našeho klienta pochopit, že nejlepší způsob, jak pokračovat v řízení projektu, je provádět jej „postupně“.
Výsledek:
etnografického výzkumu a mapování cesta v rámci našeho konstrukčního myšlení metodiky pomohl nám vybudovat nová aplikace s funkcí, navrženy a potvrzeny zúčastněnými stranami, kteří jsou v konečném důsledku bude používat – což je jeden z významných funkčních požadavků, příklady.
následující body mohou poznamenat w.r.t funkční požadavky:
- Funkční požadavky jsou vždy napsány z pohledu systému a zúčastněných stran.
- SPECIFIKACE funkčních požadavků je mnohem podrobnější.
- prostřednictvím plnění funkčních požadavků je vyvinuto efektivní řešení, které splňuje obchodní potřeby a cíle klienta.
proto funkční požadavky vysvětlují “ jak “ část projektu, tj. softwarové požadavky a jak bude řešení schopno uspokojit potřeby organizace.
dokument o funkčních požadavcích
dokument o funkčních požadavcích popisuje funkce potřebné k dosažení obchodních potřeb. Tyto funkce jsou dokumentovány v dokumentu funkčních požadavků (FRD) nebo v dokumentu specifikací funkčních požadavků (FRS).
dobře napsaný FRD zobrazuje každý procesní tok pro každou aktivitu a propojuje závislosti.
FRD obsahuje následující prvky:
- Cíl projektu
- rozsah projektu
- Podrobné funkční požadavky
- Předpoklady/omezení
- Zastoupení funkčních požadavků pomocí Informační Architektura
Tipy pro Psaní Funkčních Požadavků Šablony Dokumentu (FRD)
Vytváření dokumentu, který požádá o technických funkcí, které jsou nutné pro úspěšné doručení software/produkt, který je stejně jako psaní zprávy na všechny zúčastněné členy týmu o technické úkoly, by je chcete provést.
následující tipy by vám pomoci při psaní efektivní Funkční Požadavky Dokumentu:
- Double-zkontrolujte, zda vaše fakta
- Použít jednoduchý jazyk
- Přidat ilustrací nebo diagramů
- Dodržujte časový rámec
Obchodní Požadavky vs Funkční Požadavky: Klíčové Problémy v Psaní Dokumentu
To je velká výzva, psát „dobré“ nebo „platný“ obchodní a funkční požadavky. Mezi nejčastější výzvy, s nimiž se setkáváme při vytváření těchto požadavků, patří:
- neúplné pochopení požadavku, pokud nepožádáte o vysvětlení.
- nesprávná interpretace požadavku; použití osobních filtrů na informace, které mění záměr.
- psaní o implementaci (jak) místo požadavků (co).
- Prováděcí rozhodnutí by měla být odložena na co nejpozději bod v procesu vyvolávání požadavků.
- použití nesprávné struktury vět.
- význam hodnocení kvality požadavků při vývoji softwarových produktů.
Co jsou non-funkční požadavky?
nefunkční požadavky definují a specifikují provoz systému. Nemá však vliv na funkčnost systému, jak název napovídá. Systém tedy může pokračovat v činnosti, i když nejsou splněny jeho nefunkční požadavky. Důvodem, proč jsou nefunkční požadavky nezbytné, je jejich použitelnost a protože pomáhají při určování faktorů ovlivňujících uživatelský dojem.
co odlišuje funkční a nefunkční požadavky, je to, že zatímco první rozhoduje o vlastnostech produktu a požadavcích uživatelů, druhý se zaměřuje na vlastnosti produktu a očekávání uživatelů.
Obchodní Požadavky vs Funkční Požadavky – Závěr
Z výše uvedeného srovnání je zřejmé, že požadavky jsou páteří každého podnikání. Obchodní i funkční požadavky tvoří základ efektivní obchodní analýzy. Obchodní požadavky vysvětlují“ proč „a“ co „projektu a funkční požadavky vysvětlují“ jak “ projektu.
pravidelný přezkum a srovnávání (vyvinutých) funkčních požadavků s obchodními požadavky zajišťují celkový úspěch projektu. Zde je závěrečné prohlášení, které bude jít dlouhou cestu v pomoci vám jasně rozlišovat obchodní požadavky funkční požadavky – výchozí bod každého podnikání analýzy je pochopit business požadavky (co a proč) klienta a transformovat je do funkční požadavky (jak).