Modelování uživatelských požadavků

Článek
06/10/2015

Microsoft Visual Studio Ultimatepomáhá pochopit a projednat a kreslení diagramů o své činnosti a část komunikaci potřebám uživatelů systému hraje v pomoci jim dosažení jejich cílů.Požadavky modelu je sada tyto diagramy, které se zaměřuje na jiný aspekt potřebám uživatelů.

Ukázku videa, viz: domény obchodní modelování.

Požadavky na model pomáhá:

Zaměřit se na vnější chování v systému, odděleně od jeho vnitřní návrhu.
Popsat uživatelů a je třeba zúčastněných stran s mnohem méně nejednoznačnosti, než lze v přirozeném jazyce.
Definujte konzistentní Glosář termínů, které lze uživatelům a vývojářům testerům.
Zmenšení mezer a nekonzistence v požadavcích.
Omezte práci nutné reagovat na změny požadavků.
Pořadí, ve kterém bude rozvíjet funkce plánování.
Modely můžete použijte jako základ pro zkoušky systému, což vztah mezi zkoušky a požadavky.Při změně požadavky, pomáhá tento vztah zkoušky správně aktualizovat.Tím zajistíte, že systém splňuje požadavky na nové.

Požadavky modelu poskytuje největší výhody použití fokus rozhovory s uživateli nebo jejich zástupci a opět na začátku každé opakování.Nemáte dokončení podrobně před psaní kódu.Částečně pracovní aplikace, i když velmi zjednodušená, obecně je základem nejvíce stimulovat diskusi požadavky s uživateli.Model je efektivní způsob shrnují výsledky těchto diskusí.Další informace naleznete v tématu Použití modelů v procesu vývoje.

[!POZNÁMKA]

V rámci těchto témat "systémem" rozumí systém nebo aplikace, která při vývoji.Může to být velké kolekce mnoha softwarových a hardwarových komponent; nebo jedna aplikace; nebo softwarová součást uvnitř větších systému.V každém případě požadavky model popisuje chování, které je viditelné z vnějšku vašeho systému prostřednictvím uživatelského rozhraní nebo v rozhraní API.

Běžné úkoly

Můžete vytvořit několik různých zobrazení požadavky uživatelů.Každé zobrazení obsahuje určitý typ informací.Při vytváření těchto zobrazení je nejvhodnější často přesunout z jednoho do druhého.Můžete spustit v libovolném zobrazení.

Diagram nebo dokumentu	Popis modelu požadavky	Oddíl
Diagram případu použití	Kdo používá systém a jsou s ním dělat.	Popisující použití systému
Třída konceptuální diagram	Glosář typy používané k popisu požadavků; typy viditelné na rozhraní v systému.	Definice termínů používaných pro popis požadavků
Diagram činnosti	Tok práce a informací mezi činnosti prováděné uživatele nebo systému nebo jeho části.	Zobrazení průběhu prací mezi uživateli a počítači
Sekvenční diagram	Řada interakce mezi uživateli a systém nebo jeho části.Alternativní zobrazení do diagramu činnosti.	Zobrazení interakce mezi uživateli a počítači
Další dokumenty nebo pracovní položky	Kritéria pro výkon, zabezpečení, použitelnosti a spolehlivost.	Popisující jakostní požadavky služby
Další dokumenty nebo pracovní položky	Omezení a pravidla, které nejsou specifické pro určitý případ použití	Zobrazení obchodní pravidla

Všimněte si, že většina typů diagramů lze použít pro jiné účely.Přehled typů diagramů, viz Vývoj modelů pro návrh softwaru.Základní informace o kreslení diagramů, Úpravy modelů a diagramů UML.

Popisující použití systému

Vytvořte diagramy případu použití, kdo používá systém a co mohou ji používat.Případ použití představuje cíl uživatele systému a postup mohou provést k dosažení cíle.

Například online moučka, prodejní systém musí umožnit zákazníkům výběr položek z nabídky a musí umožnit poskytování restaurace aktualizovat v nabídce.To lze sumarizovat v diagramu případu použití:

Případy použití pro zákazníka a restauraci

Můžete zobrazit, jak případ použití je tvořen menší případy.Například objednání pokrmu je součástí moučka, který také zahrnuje platby a dodání nákupu:

Systém se podílí na platby, ale nikoli na dodání.

Můžete také zobrazit případy použití, které jsou zahrnuty do působnosti systému, který vyvíjíte.Například obrázek systému neúčastní případu použití dodat moučky.To pomáhá nastavit kontext pro vývojové práce.(V diagramu případu použití subsystému kontejnerů lze představovat systému nebo jeho součástí.)

Také pomáhá týmu diskutovat, které budou zahrnuty v sobě vydaných.Nelze například diskuse, zda v počáteční systému mzdy k verzi moučka uspořádána přímo mezi restaurace a zákazník namísto prostřednictvím systému.V takovém případě nelze přesunout mzdy za jídlo mimo systém nyní večeři obdélník pro původní vydání.

Diagram případu použití pouze poskytuje Souhrn případů použití.Chcete-li poskytnout podrobnější popisy můžete propojit případy použití v diagramu do samostatných dokumentů a dalších diagramech.Zjistěte, jak to provést, naleznete v tématu Postupy: Propojení případu použití s dokumenty a diagramy.

Tým výkresu diagramu případu použití pomáhá:

Zaměřit se na očekávali uživatelé provést v systému bez probíhá podle prováděcí distracted.
Diskutovat o působnosti systému nebo konkrétní verze systému.

Další informace o následujících tématech:

Informace o	Čtení
Podrobnější informace o vytvoření případů použití.	Diagramy případů použití UML: Pokyny
Prvky v diagramu případu použití	Diagramy případů použití UML: Referenční dokumentace
Jak vytvořit kód z případů použití	Modelování architektury softwarového systému

Definice termínů používaných pro popis požadavků

Diagramy tříd jazyka UML slouží vám vyvinout konzistentní Slovník pojmů podnikání pro následující účely:

Uživatelé sami projednat business, ve kterém pracuje systém.
Popište potřebám uživatelů, například v popisy případů použití, obchodní pravidla a články uživatele.
Typy informací vyměňovaných v rozhraní API systému nebo prostřednictvím uživatelského rozhraní.
Popis zkoušky systému nebo přijetí.

Používají se pro tento účel, se nazývá třídy konceptuální diagram obsahu třídy diagramu UML.(Je známá také jako modelu domény nebo model třídy analýzy.)

V diagramu třídy rámcové můžete zobrazit pouze tyto třídy potřebné v popisech požadavků, bez zobrazení žádné podrobnosti vnitřní návrhu systému.Diagram nezobrazuje žádné podrobnosti vnitřní návrhu systému.Jste neukazuje obvykle operací nebo rozhraní na koncepční tříd.

Například při kreslení tyto rámcové třídy systému nyní večeři:

Nabídka tříd, pořadí, položky nabídky položka objednávky.

Třída konceptuální diagram obsahuje slovník termínů, které použijete v celém požadavky modelu.Například v podrobný popis použití případ objednat jídlo, můžete vytvořit:

Si zákazník vybere nabídky ze kterého chcete vytvořit pořadía pak vytvoří Pořadí položek v pořadí výběrem Položky nabídky z nabídky.

Všimněte si, jak jsou termíny použité v tomto popisu názvy tříd v modelu.Diagram odstraní nejasnosti vztahy mezi těchto tříd.Například je jasně ukazuje, že každé objednávky je spojen s pouze jednu nabídku.

Nedorozuměním o požadavcích uživatelů lze vysledovat často k nedorozuměním, o podrobné významy slov.Například většina restaurací, bude mít sdílené pochopení podmínek nabídky a objednávky, ale je méně jasný rozdíl mezi položky na objednávce a položky v nabídce.Požadavky se projednávají s obchodní zúčastněným stranám, je důležité zpřístupnit tyto rozdíly.Diagram třídy je užitečný nástroj k vyjasnění podmínek a jejich vztahy.

Třída konceptuální model můžete formulář základní slovník, který může být popsáno obchodní logiku systému.Ale tříd v softwaru obvykle bude mnohem složitější než konceptuální model, protože implementace musí zvážit například výkon, distribuce, flexibilitu a další faktory.Několik různých implementacích rámcové třídy se často nacházejí v jeden systém.

Například objednávek nelze reprezentovat v XML, SQL, HTML a C# v různých částech systému a na různých rozhraní mezi částmi.Přidružení mezi objednávky a nabídky nelze reprezentovat v mnoha různými způsoby, například odkazů v rámci kódu C#, vztahy v databázi, nebo křížové odkazy ID v XML.Ale i přes tyto varianty konceptuální model obsahuje důležité informace, které platí v každé části softwaru.Příklad diagramu třídy víme, že v každém zavádění bude pouze jedné nabídky spojené s každou objednávku.

Tým výkresu diagramu třídy požadavky pomáhá:

Definovat a standardizovat základní pojmy používané v diskusích potřebám uživatelů.
Vyjasnit vztahy mezi těmito podmínkami.

Další informace o následujících tématech:

Informace o	Čtení
Podrobnější informace o hledání požadavky třídy	Diagramy tříd UML: Pokyny
Prvky třídy konceptuální diagram	Diagramy tříd UML: Referenční dokumentace
Jak vyvinout kód z rámcové tříd	Modelování architektury softwarového systému

V diagramu třídy rámcové není zpravidla užitečné umístit šipky na přidružení představuje schopnost navigace.Důvodem je diagram nepředstavuje implementace.Sdružení znázornit vztahy mezi objekty reálného světa.Následující Visual Studio rozšíření provést jiné směrové šipky výchozí: vzorku: funkce modelování UML domény.

Zobrazení obchodní pravidla

Obchodní pravidlo, je požadavek, který není spojen s případem použití zejména a měla být dodržena v celém systému.

Mnoho obchodní pravidla jsou omezení na vztahy mezi třídami koncepční.Můžete psát tyto statickéobchodní pravidla jako komentáře přidružené třídy konceptuální diagram příslušných tříd.Příklad:

Pravidlo v komentáři připojené k třídě objednávka.

Dynamické obchodní pravidla omezit přípustné posloupnosti událostí.Například pomocí sekvence nebo činnosti diagramu zobrazit, že se uživatel musí přihlásit před provedením další operace v systému.

Však mnoho dynamických pravidel lze účinněji a genericky uvést nahrazením statické pravidel.Například můžete přidat atribut typu Boolean zaznamenána v třídy v rámcové třídy modelu.By přidat jako koncová podmínka v případě použití protokolu zaznamenána a přidejte jej jako předpoklad většiny ostatních případů použití.Tento přístup umožňuje vyhnout se definování všechny možné kombinace posloupnosti událostí.Je také flexibilnější při potřebujete přidat nové případy použití modelu.

Všimněte si, že je volba zde jak definovat požadavky a to je nezávislý jak implementovat požadavky v kódu programu.

Další informace o následujících tématech:

Informace o	Čtení
Podrobnější informace o hledání a zaznamenávání statické obchodní pravidla	Diagramy tříd UML: Pokyny
Prvky třídy konceptuální diagram	Diagramy tříd UML: Referenční dokumentace
Jak vytvořit kód, který dodržuje pravidla obchodní	Modelování architektury softwarového systému

Popisující jakostní požadavky služby

Existuje několik kategorií kvality služby požadavek.Mezi ně patří následující:

Výkon
Zabezpečení
Použitelnost
Spolehlivost
Odolnosti

Zahrnout některé z těchto požadavků v popisech zvláštní případy.Ostatní požadavky nejsou specifické případy použití a nejefektivnější zapsána v samostatném dokumentu.Je to možné, je vhodné dodržovat slovník definovanými požadavky modelu.V následujícím příkladu si, že hlavní slova použitá v požadavku jsou názvy aktérů a případy použití třídy v předchozí ilustrace:

Pokud restaurace odstraní položku nabídky, zatímco zákazník objednává pokrmu, objednávka zboží, který odkazuje na danou položku nabídky se zobrazí červeně.

Další informace o následujících tématech:

Informace o	Čtení
Podrobnější informace o záznamu jakostní požadavky služby	Guidelines for Defining Quality of Service Requirements
Připojení k případům použití dalších dokumentů	Postupy: Propojení případu použití s dokumenty a diagramy
Jak vytvořit kód, který splňuje jakostní požadavky služby	Modelování architektury softwarového systému

Zobrazení průběhu prací mezi uživateli a počítači

Můžete zobrazit tok práce mezi případy použití různých diagram činnosti.Je často užitečné začít požadavky modelu podle výkresu diagramu činnosti zobrazující hlavní úkoly, které uživatelé provádět - s systému i mimo něj.

Příklad:

Aktivita s třemi akcemi a smyčky.

Můžete kreslit diagramy případu použití a diagramy činnosti zobrazit různá zobrazení stejných informací.Diagram případu použití je účinnější v zobrazení vnoření menších akcí v rámci činnosti větší, ale nezobrazuje tok práce.Příklad:

Případy použití pro předchozí akce

Všimněte si, že můžete také diagramy činnosti k znázornění algoritmů v softwaru, ale diagramy slouží pro obchodní proces zaměření na akce, které jsou viditelné mimo systém.

Další informace o následujících tématech:

Informace o	Čtení
Další informace o definování obchodních toků práce	Diagramy činnosti UML: Pokyny
Prvky v diagramu činnosti	Diagramy činnosti UML: referenční dokumentace
Jak vytvořit kód z diagramy činnosti	Modelování architektury softwarového systému

Zobrazení interakce mezi uživateli a počítači

Sekvenční diagram můžete zobrazit výměny zpráv mezi systémem a externí účastníky nebo mezi částmi systému.To umožňuje zobrazení kroků v případu použití, který velmi jasně ukazuje řadu interakcí.Sekvenční diagramy jsou zvláště užitečné, pokud je že interakce několika stranami v případě použití a také kde má systém rozhraní API.

Příklad:

Sekvenční diagram systému a účastníky.

Sekvenční diagramy výhodou je, jaké zprávy pocházejí systému jsou konstruování snadné je.Chcete-li navrhnout systém nahradit jeden životnost systému samostatné životnost pro jeho jednotlivé součásti a poté zobrazit interakce mezi nimi v odpovědi na příchozí zprávy.

Další informace o následujících tématech:

Informace o	Čtení
Další informace o definování interakce	Sekvenční diagramy UML: Pokyny
Prvky v sekvenčním diagramu	Sekvenční diagramy UML: Referenční dokumentace
Jak vytvořit kód z sekvenční diagramy	Modelování architektury softwarového systému

Snížit nekonzistencí pomocí modelu

Vytváření modelu obvykle způsobí významné snížení nekonzistence a nejasnosti ve požadavky uživatelů.Různé zúčastněné strany mají často různé ujednání obchodního světa, ve kterém pracuje systém.Prvním úkolem je proto vyřešit tyto rozdíly mezi klienty.

Zjistíte, že mnoho otázek o obchodních domény vznikají přirozeně při vytváření modelu.Uvedení těchto otázek uživatelům bude snížit potřebu změny v pozdější fázi projektu.Zde jsou některé specifické otázky, můžete položte na první a požádejte obchodní zúčastněným stranám pokud je odpověď nejasné:

Pro každou třídu v modelu požadavky požádejte "co případu použití vytvoří instance této třídy?" Například v moučka objednání služby online, budete pravděpodobně požádáni, "co případu použití vytvoří instance třídy restaurace nabídku?" To vede k diskusi jak nové restaurace přihlásili ke službě a přispívá jeho nabídky.Podobné otázky můžete požádat o co vytvoří nebo změní atributy a přidružení.
Pro každý případ použití modelu požadavky Zkuste popsat výsledek nebo koncová podmínka každého případu použití poskytnutých diagramy třídy slovy.Je často užitečné zobrazit efekt případu použití Načrtnutím instance tříd před a po výskytu případu použití.Pokud je koncová podmínka případu použití "položky nabídky je přidán k objednávce zákazníka", Skica instancí třídy objednávky a nabídky.Zobrazte efekty případu použití, například nový odkaz nebo nový objekt jinou barvou nebo nový výkres.To často vede k diskuse o jaké informace je třeba v modelu.Ačkoli požadavky třídy se netýkají přímo s implementací, popisují informace, které bude nutné systém ukládání a přenosu.
Požádejte o omezení na atributy a přidružení, zejména omezení zahrnující více než jeden atribut nebo přidružení.
Požádejte o platných a neplatných sekvencí případy použití sekvence nebo činnosti diagramy znázorňující jejich kreslení.

Porovnáním vztahy mezi zobrazeními, které poskytují různé diagramy lze rychle pochopit hlavní koncepty, které uživatelé pracovat, a pomoci jim pochopit, co potřebují ze systému.Také dosáhnout lepší porozumění, jaké požadavky zúčastněných jsou určité nejméně o.Můžete naplánovat rozvíjet tyto funkce alespoň ve zjednodušené formě v raném stadiu projektu, aby uživatelé experimentovat s nimi.