Develop requirements

Požadavky na popisují zúčastněných nečekal z produktu. Podmínky, které jim budou snadno projednávat s firemními účastníky, pomocí slovníku a konceptů obchodní domény umožňuje by měl vyjadřovat vašim požadavkům. Požadavky na by měl diskutovat o ani závisí na implementaci. Požadavky zahrnovat nejen chování a kvalitu služeb očekávání uživatelů, ale také zákonných omezení a obchodní standardy.

Vytvořením požadavky v rámci TFS, získáte následující výhody:

• Ověřte, že byly splněny požadavky na jejich propojováním k otestování případů.

• Sledování pokroku směrem k implementaci požadavky propojením s pracovními položkami úloh.

• Strukturu požadavky na celkový a podrobnější požadavky, takže vám mohou spravovat snadněji a tak, aby zprávy o pokroku lze shrnout informace.

• Model požadavky uvedené v Visual Studio Ultimate, propojování prvky modelu v požadavky na Team Foundation Server.

Toto téma nepokouší replikovat rozsáhlou textu dokumentace, která je k dispozici na předmětem určení požadavků. Místo toho je zaměřen na aspekty, které jsou důležité pro použití Visual Studio Nástroje způsobem, který odpovídá CMMI. Další informace o CMMI, naleznete v části Background to CMMI.

Aktivity, které jsou popsány v tomto tématu, stejně jako jakékoli vývojových činnosti by neměl být provedena v přísné pořadí. Vyvíjejte modelu domény při psaní scénářů vzhledem k tomu, že vám pomůže jedné aktivity, že vylepšit další aktivity. Vyvíjejte scénáře jako čas pro kódování jejich přístupů. Informační kanál zkušenost s kódem, který byl zapsán a prokáže zpět do scénáře, které ještě mají být implementováno.

Při vývoji požadavky

Sady TFS podporuje iterační práci a tento postup je nejefektivnější, když early iterací se používají k získání zpětné vazby od potenciálních uživatelů a další zainteresované uživatele. Tuto zpětnou vazbu lze použít ke zlepšení požadavky, které jsou uvedeny pro budoucí iterací. Výsledkem produkt, který je mnohem efektivnější v jeho ultimate instalaci než produkt, který je vyvinutý za stejné období bez jakékoli zkušební verze uživatele. Pokud je název projektu jedné součásti mezi mnoho v větší programu, umožňuje early integraci s jinými součástmi architekty program ke zlepšení celkového produktu.

Tato flexibilita musí být porovnán s potřeby tak, aby poskytovala pevně závazky zákazníkovi nebo partnerům v paralelní projektech.

Řízené rozsahu proto požadavky jsou vyvinutý a upravený v celém projektu. Vzhledem k tomu, že podrobné požadavky jsou pravděpodobně změní průběhu projektu, určení v plné výši dříve, než je pravděpodobnost, že bude mít za následek provedení požadovaných plně využívána úsilí.

• V iteraci 0 vyvíjejte sada požadavků, které popisují hlavní funkce, s právě dost podrobnou tvoří plán produktu. Plán produktu přiřadí požadavky iterací a samostatně, jaké požadavky budou splněny na konci každé iteraci. Vytvoření modelu domény hlavní konceptů a aktivity a definovat slovník, který se bude používat pro tyto koncepty v diskusi s uživateli i v implementaci. Určete širokou požadavky, které pervade všechny funkce, jako je například zabezpečení a dalších kvalitu požadavků na služby.

• Na nebo v blízkosti začátku každé iteraci vyvíjejte požadavky na tyto funkce podrobněji. Zjistěte, kroky, které budou uživatelé provést, je definovat pomocí diagramů aktivit nebo sekvence. Definujte, co se stane, že ve výjimečných případech.

• Ověřte, tak často, možná všech požadavků, které byly provedeny. Všude požadavky, například zabezpečení, musí být ověřen pomocí testů, které jsou rozšířeny pro jednotlivé nové funkce. Pokud je to možné můžete automatizovat testy vzhledem k tomu, že automatické testy provést nepřetržitě.

Správa změn požadavky

Podle následujících pokynů umožňují pracovat přírůstkové proces při jeho splňovat požadavky CMMI monitorování.

• Požadavky, které jsou nastaveny pro iterace neměňte. V případě vzácné náhlému změny v případech bude pravděpodobně nutné zrušit iterace, zkontrolujte plán produktu a můžete začít nové iterace.

• Vyhledejte nejistoty v požadavcích. Pokuste se upravit plán, tak, aby uživatelské prostředí s early iterací poskytuje informace, které snižuje nejistoty.

• Chcete-li změnit chování, které již bylo provedeno, není-li požadovaný zlepšení je již součástí plánu pomocí změnu požadavku pracovní položky zaznamenávat požadavky. Odkaz na každou žádost o změnu s pracovními položkami odpovídající požadavků.

• Při prohlížení produktu před každé iteraci, zkontrolujte žádosti o změnu. Zkontrolujte v důsledku požadavku na závislé projekty a uživatelé a odhadněte náklady s ohledem na změny ve vašem kódu. Pokud je přijata žádost o změnu, aktualizujte požadavek.

• Aktualizujte zkoušky, které odpovídají každé změně požadavky.

• Určete datum přerušení (například po iterace 2 nebo 3), po které požadavky na změny musí být mnohem víc silného oprávněné. Pokud je název projektu pro platební zákazníka, je to datum, které si zákazník schválit sadu standardních hodnot požadavky a přejděte z hodinových platba na pevný poplatek.

• Použijte chybu pracovních položek na záznam implementována chování, které neprovádí podle požadavků explicitním či implicitním. Pokud je to praktické, vytvořte nové test, který by mít zachycena této chyby.

Napíšete příkaz vizi

Diskuze o příkaz vizi s týmem a zobrazíte jej v projektu webový portál pro Team Foundation Server.

Příkaz vizi je, že otevřete krátký souhrn jaké výhody produktu. Jaké uživatelé budou moci provést, aby se nepodařilo před? Příkaz vizi pomůže přesně určit dosah produktu.

Pokud produkt již existuje, napište příkaz vize pro tuto verzi. Jaké produktu uživatelé budou moci provést, aby se nepodařilo před?

Zápis scénáře

Pracovat s zákazníkem a další zainteresované uživatele k vytvoření scénáře a s polem Typ požadavku, který je nastaven na scénář je zadat jako pracovními položkami požadavků.

Scénář nebo použití případu je popisů, který popisuje posloupnost událostí, ukazuje, jak je dosaženo určitého cíle a obvykle zahrnuje interakce mezi osob nebo organizace a počítače.

Pojmenujte ji popisný název, který jasně odlišuje od ostatních, pokud jsou zobrazeny v seznamu. Ujistěte se, že jsou uvedeny hlavní actor nebo objekty actor a že je jejich cíli vymazat. Například to bude dobrý název:

Odběratel nakupuje pokrm.

V následujících podob může zapisovat scénáře. V některých případech mohou pomoci používat více než jeden formulář:

• Jedno nebo dvě věty popis pracovní položky:

  Zákazník řadí pokrm na webu a platí s vaší platební karty. Pořadí je předána restauraci, který připraví a přináší jídla.

• Číslovaný kroky v popisu pracovní položky:

  Zákazník navštíví webovou stránku a vytvoří objednávku pro pokrm. Na webu zákazníka přesměruje na web platby, aby platby. Pořadí je přidán do seznamu práce restauraci. Restaurace, zadané připraví a dodává jídla.

• Scénáře. Scénář je v podstatě proužek Kreslený vtip informující o tom textu. Je možné nakreslit v aplikaci PowerPoint. Tento soubor scénáře připojit k pracovní položce požadavek nebo soubor odešlete k portálu týmu a přidat hypertextový odkaz s pracovní položkou.

  Scénář je obzvláště užitečný pro zobrazení uživatele. Ale pro obchodní scénář, je doporučeno používat nákresu styl, která usnadňuje vymazat, že se nejedná o finální návrhu uživatelského rozhraní.

• Požadavek dokumenty. Požadavek dokumenty vám poskytují svobodu při poskytování odpovídající úroveň podrobností pro každý požadavek. Pokud se rozhodnete použití dokumentů, vytvořit dokument aplikace Word pro každý požadavek a připojit k pracovní položce požadavek dokument nebo soubor odešlete k portálu týmu a přidat hypertextový odkaz s pracovní položkou.

• Jednotné sekvenční diagram Markup Language (UML). Sekvenční diagram je obzvláště užitečný, pokud interakci několik stran. Můžete například řazení jídla vyžaduje, aby zákazníka, DinnerNow webový server, systém platby a restaurace, zadané interakci v určitém pořadí. Kreslit sekvenční diagram v modelu UML, zkontrolujte do Team Foundation Server, a zadejte odkaz v pracovní položce požadavek. Další informace naleznete v tématu Sekvenční diagramy UML: Pokyny.

Konkrétní scénáře

Začněte tím, že zápis konkrétní scénáře, které postupujte podle konkrétní sadu objekty actor prostřednictvím určitém pořadí. Například "Carlos objednávky pizza a česnek chléb na DinnerNow webovém serveru. Webový server přesměruje Carlos Woodgrove Bank platby služby. Fourth Coffee připraví pizza a dodává jej."

Určitých scénářů umožňují počítat systém používán a jsou velmi užitečné, pokud první prozkoumat funkce.

Může být také užitečná k vytvoření pojmenovaných osoby, které popisují pozadí a jiné činnosti osob a organizací. Carlos vytvoření základního v režimu spánku a používá Internetu café; Wendy bydlí v gated Společenství; Sanjay objednávky jídla pro jeho manželka při svou práci; Contoso spouští řetězci 2 000 restaurace po celém světě; Fourth Coffee je spouštět páru, který doručit podle vyrábějící jízdní.

Více obecné scénáře, které byly vytvořeny z hlediska "zákazníkem," "položku nabídky," a tak dále může být vhodnější, ale jsou méně pravděpodobně povede k zjišťování užitečných funkcí.

Úrovně podrobností

V iteraci 0 psát několik důležitých scénářích podrobně, ale zápis většině případů v přehledu. Když se blíží iterace ve kterém určitých scénářů má být plně nebo částečně implementováno, přidejte více podrobností.

Pokud je první vzít v úvahu scénáře, může být užitečný popisují kontext obchodní i aspekty, ve kterých produkt přebírá žádná z částí. Například popis metody DinnerNow doručení: každý restaurace uspořádávat své vlastní doručení nebo DinnerNow spustit službu doručení? Odpovědi na tyto dotazy poskytují užitečné kontext pro vývojového týmu.

Podrobnější scénáře, které vyvíjíte na začátku iterace můžete popsat interakce uživatelské rozhraní a scénáře můžete zobrazit rozvržení uživatelského rozhraní.

Uspořádání scénáře

Scénáře můžete uspořádat pomocí následujících metod:

• Nakreslete diagramy případu použití, které se zobrazí všechny scénáře jako případu použití. Tato metoda je doporučeno, protože umožňuje scénářích velmi snadno se přítomné a diskutovat o nich. Další informace naleznete v tématu Diagramy případů použití UML: Pokyny.

  • Každý případ použití propojte s pracovní položkou, která definuje scénáře. Další informace naleznete v tématu Propojení prvků modelu a pracovních položek.

  • Kreslit rozšiřuje relace, chcete-li zobrazit tuto situaci, jeden je variantou jiného. Například "Zákazník Určuje samostatnou platbu a adresy pro doručování" je rozšíření Basic "Zákazník usnadňuje pořadí" případu použití. Rozšíření jsou obzvláště užitečná oddělit scénáře, které budou provedeny v novější iteraci.

  • Zakreslit zahrnuje vztahy k oddělení postup, jako je například "Zákazník přihlásí," společné pro několik případy použití.

  • Nakreslete generalizace vztahy mezi obecné scénáře, jako je například "Zákazník platí" a konkrétní variant, jako je například "Zákazník platí kartou."

• Nadřazený podřízený mezi vytvořte vazbu scénář pracovní položky. Můžete zobrazit hierarchii v Průzkumník týmových projektů. Další informace naleznete v tématu Arrange requirements into a product plan.

Model domény business

Vytvoření modelu UML, který popisuje hlavní aktivity a koncepty, které se účastní používání produktu. Pomocí podmínky, které jsou definovány v tomto modelu jako "všudypřítomná jazyk," v situacích, v diskusích s účastníky, v uživatelském rozhraní a všech uživatelských příruček a v samotném kódu.

Mnoho požadavků nejsou výslovně uvedeny vaše zákazníkem a porozumění předpokládané požadavky závisí na pochopení obchodní domény, to znamená, kontext, ve kterém bude fungovat produktu. Některé úkoly požadavků shromažďování v doméně neznámé je proto o získání znalost tohoto kontextu. Poté, co bylo zjištěno, tento druh znalostní báze, lze použít na více než jeden projekt.

Uložte model v nástroji správy verzí.

Další informace naleznete v tématu Modelování uživatelských požadavků.

Chování modelování

Kreslení diagramů aktivit ke shrnutí scénářů. Plavecké dráhy slouží k seskupení akce, které provádí různé třídy actor. Další informace naleznete v tématu Diagramy činnosti UML: Pokyny.

Přestože scénáře obvykle popisuje konkrétní posloupnost událostí, diagramu činnosti jsou uvedeny všechny možnosti. Kreslení diagramu činnosti lze zobrazit výzvu Zamyslete se alternativní sekvence a požádat obchodní klienti, co by mělo nastat v těchto případech.

Následující obrázek ukazuje jednoduchý příklad diagramu činnosti.

Kde výměny zpráv je důležité, může být efektivnější použití sekvenčním diagramu zahrnující prostředkem pro každý actor a součástí hlavních produktů.

Diagramy případu použití umožňují shrnout různé toky aktivit, který podporuje produkt. Každý uzel v diagramu reprezentuje řadu interakce mezi uživatelů a aplikací pro dosažení cíl daného uživatele. Můžete také faktor běžné sekvence a volitelné rozšíření do uzlů case oddělené používání. Další informace naleznete v tématu Diagramy případů použití UML: Pokyny.

Následující obrázek ukazuje jednoduchý příklad diagramu případu použití.

Koncepty modelování

Nakreslete diagramy tříd domény k popisu důležité entity a jejich vztahy, které jsou uvedeny v situacích. Můžete například modelu DinnerNow ukazuje restaurace, nabídky, objednávky, položky nabídky a tak dále. Další informace naleznete v tématu Diagramy tříd UML: Pokyny.

Popisek role (končí) vztahů s názvy a cardinalities.

V diagramu třídy domény není připojíte obvykle operations do tříd. V modelu domény popisují diagramy aktivit chování. Určení odpovědnosti na třídy program je součástí vývojové práci.

Následující obrázek ukazuje jednoduchý příklad diagramu třídy.

Statické omezení

Přidejte do diagramy tříd omezení, které řídí atributy a vztahy. Můžete například položek v pořadí musí všechny pocházet ze stejné restaurace. Tyto typy pravidel jsou důležité pro návrh produktu.

Model konzistence

Zajistěte, aby byly konzistentní modelu a scénářů. Je jedním z nejdůležitějších využití pro model, chcete-li vyřešit nejasnosti.

• Popisy scénář pomocí podmínky, které jsou definovány v modelu a jsou v souladu s vztahy, které definuje. Pokud je model definuje položky nabídky, scénáře nesmí odkazovat na totéž jako produkty. Pokud diagram třídy zobrazuje, které položky nabídky patří do přesně jeden nabídky, scénáře by neměl mluvit sdílení položku mezi nabídkami.

• Každý scénář popisuje řadu kroků, které jsou povoleny pomocí diagramů aktivit.

• Scénáře nebo aktivity popisují, jak je vytvořen a zlikvidovány každou třídu a vztahu v diagramu třídy. Například jaké scénář vytvoří položky nabídky? Pokud je pořadí zlikvidovány?

Vývoj kvalitu požadavků na služby

Vytvořte pracovní položky, které určují kvalitu požadavků na služby. Nastavte pole Typ požadavku na kvalitu služeb.

Kvalitu služeb nebo nefunkční požadavky zahrnují výkonu, použitelnost, spolehlivost, dostupnost, integrity dat, zabezpečení, dostupnost, použitelnost a procesory, deliverability, udržovatelnost, návrh a přizpůsobení a dokončit.

Zvažte každé z těchto kategorií pro jednotlivé scénáře.

Název každé kvalitu služeb požadavek by měl vystihnout jeho definici podle prezentaci kontextu, akce a měření. Můžete například vytvořit následující požadavek: "Při vyhledávání v katalogu vrátit výsledky hledání za méně než tří sekund."

Kromě toho je užitečné zaznamenat více podrobností, která vysvětluje, proč je nezbytné požadavku. Popisují, proč by hlavní hodnota požadavku a proč je nutné tato úroveň služeb. Zadejte kontext a zarovnání do bloku. Toto vysvětlení mohou zahrnovat informace o správě užitečné riziko například data z průzkum trhu, cílová skupina zákazníků nebo použitelnost studie; Nápověda k oddělení technické podpory sestavy/lístky; nebo jiných anecdotal evidence.

Odkaz kvalitu služeb požadavek na jakékoli scénáře (požadavek pracovní položku), který je ovlivněn kvality služeb. Propojení související pracovní položky umožňuje uživatelům Team Foundation Server ke sledování závislé požadavky. Dotazy a sestavy můžete zobrazit vliv funkční požadavky, které jsou zachyceny jako scénáře kvalitu požadavků na služby.

Zkontrolujte požadavky na systém

Pokud požadavky byly zapsány nebo aktualizovat, by měl být kontrolovány odpovídající účastníky zajistit, aby odpovídajícím způsobem popisují všechny uživatele interakce s produktem. Běžné účastníky mohou zahrnovat odborníkem na toto téma, obchodní analytik a architekt uživatelské prostředí. Scénáře jsou zkontrolovány také zajistit, že mohou být provedeny v projektu bez jakákoli záměna nebo problémy. Pokud se nanese jakékoli problémy, scénáře je nutno opravit tak, aby byly platné na závěr tuto aktivitu.

Vytvořte kontrolní pracovní položky můžete sledovat tuto revizi. Tato položka obsahuje důležité poznatky pro standardní způsob hodnocení CMMI hodnocení zlepšování procesu (SCAMPI) a může poskytovat dobrý zdroje informací pro analýza hlavní příčiny v budoucnu.

Přečtěte si jednotlivé scénáře pro tyto vlastnosti:

• Scénář je napsána v souvislosti s co musí úloha uživatelé provádět, co už znají a způsobu očekáváno interakci s produktem.

• Scénář jsou uvedeny požadavky na problém a nebude skryt podle navrhované řešení problému.

• Jsou označeny všech relevantních uživatelských interakce s produktem.

• Odborníkem Toto téma, obchodní analytik a architekt zkušenost uživatele projít všechny scénáře v kontextu projektu k ověření, že všechny situace může být implementováno úspěšně. Pokud scénář není platný, je to upravit tak, aby byla platná.

• Scénář může být implementováno s dostupných technik, nástroje a prostředky a v rámci rozpočtu a plánu.

• Scénář má jeden výklad, který je snadno pochopitelný.

• Scénář není v konfliktu s jinou scénářů.

• Scénář je testování.

Ověřování

Plánujete nasazení do své pracovní prostředí před jeho finální beta verze produktu. Plán k aktualizaci požadavky, založené na zpětnou vazbu od účastníků z tohoto nasazení.

Ověření se rozumí zajistit, že produkt splňuje všechny jeho zamýšlené použití v jeho provozním prostředí. V používáte MSF for CMMI ověření dosáhnout představením pracovní softwaru účastníkům na konci každé iteraci cyklu v celém projektu. Plán je uspořádány tak, aby se týká, získávají zpět vývojáři z early ukázky se mohou řešit v plánu pro zbývající iterací.

Chcete-li dosáhnout true ověření, produkt nesmí být spuštěn pouze v ukázku nebo simulované kontextu. Pokud je, co je to možné, že musí být testovány v reálných podmínkách.

Probíhá kontrola a úpravy požadavky

Scénář a kvalitu požadavků na služby, které vedly k většině úkoly vývoje, mohly být zkontrolovány pomocí dotazu požadavky zákazníků. Pokud chcete zobrazit všechny požadavky, můžete dotazem který vrací všechny pracovní položky typu požadavek pracovní položky. Nastavte sloupce výsledek, který má-li zobrazit cesty iterace.

Váš tým vytvořte většinu požadavků v rané iterací projektu. Nové požadavky budou přidány a ostatními přizpůsobené jako dřívější verze získané zpětnou vazbu.

Další zdroje

Další informace naleznete v následujících webových zdrojích:

• Praktické vodítko s funkcí řízené vývoj, Stephen r Palmer a Miroslav J. Felsing; Prentice Hall PTR, 2002.

• Zjednoduší objekt modelování: vzorky, pravidla a implementace, Jill Nicola, Mayfield označit a Mika Abney; Prentice Hall PTR, 2001.

• Agilní modelování: platnost postupy pro extrémní programování a jednotný proces Scott Ambler; Wiley, 2002.

• Domény řízené návrh: boji složitosti srdce softwaru, zařízení Eric Evans; Addison Wesley Professional 2003.

• Objekt návrhu: úkoly, odpovědnost a spolupráce, společnosti Milena Wirfs-Brock a Alan McKean; Addison Wesley Professional 2002.