Vývoj požadavků

Požadavky popisují zúčastněných očekávat z produktu.Vaše požadavky měla express, který umožní snadno být projednán s obchodní zúčastněným stranám pomocí slovníku a koncepty obchodní domény.Požadavky měla projednat ani závisí na implementaci.Požadavky zahrnují nejen behaviorální a kvalitu služby očekávání uživatelů, ale také omezení zákonné a obchodních norem.

Záznam požadavků v Visual Studio Team Foundation Server pomocí požadavky pracovní položky, získat následující výhody:

• Ověřte, že byly splněny požadavky na testování případech jejich spojením.

• Sledování pokroku směrem k uplatňování požadavků propojením k úkolu pracovní položky.

• Požadavky na celkové a podrobné požadavky strukturu, takže je lze snadněji spravovat, a tak, aby zprávy o pokroku lze sumarizovat informace.

• Model požadavky Visual Studio Ultimate, propojení prvky modelu požadavky v Team Foundation Server.

Toto téma se nepokouší velmi velkou část dokumentace, který je předmětem stanovení požadavků na replikaci.Místo toho zaměřuje na aspekty, které jsou důležité pro použití Visual Studio nástroje způsobem, který odpovídá CMMI. Další informace o CMMI Pozadí CMMI.

Činnosti popsané v tomto tématu, stejně jako všechny vývojové činnosti nesmí provést v přísném pořadí.Rozvíjet modelu domény při psaní scénářů protože jednu činnost pomůže zvýšit jiné činnosti.Vyvinout scénáře jako čas pro kódování je přístupů.Zkušenosti s kódem, který je zapsán a prokázat krmiva zpět do scénáře, které ještě mají být provedeny.

V tomto tématu

Při vývoji požadavků

Zápis prohlášení vize

Psaní scénářů

Model domény Business

Vývoj jakosti požadavky služby

Přehled požadavků

Ověření

Kontrola a úpravy požadavky

Při vývoji požadavků

Team Foundation Serveriterační podporuje práci a tento postup je nejúčinnější při včasné iterací slouží k získání zpětné vazby od možným uživatelům a dalšími zúčastněnými stranami. Tuto zpětnou vazbu lze zlepšit požadavky, které bylo stanoveno pro budoucí iterací.Výsledkem je produkt, který je mnohem účinnější v jeho instalaci ultimate než produkt, který je vyvinuta ve stejném období bez jakékoli hodnocení uživatele.Pokud projektu jedné součásti mezi mnoha v programu větší, umožňuje včasné integrace s dalšími součástmi architects program pro zlepšení celkového produktu.

Tato pružnost musí být porovnán s potřebu dát pevně závazky zákazníkovi nebo partnerům v paralelních projektech.

Řízené rozsahu proto požadavky jsou vyvíjeny a kontrast v celém projektu.Podrobné požadavky jsou pravděpodobně změní během projektu, stanovení před provedení je pravděpodobně výsledkem plně požadovaných plně využívána úsilí.

• V opakování 0 vytvořte sadu požadavků, které popisují hlavní funkcí s právě dost podrobností k plánu produktu.Plán produktu přiřadí požadavky iterací a státy, jaké požadavky budou splněny na konci každé opakování.Vytvoření modelu domény hlavní koncepty a činností a definování slovníku používaná pro tyto koncepty v diskusi pro uživatele i v provádění.Určení obecných požadavků, které pervade všechny funkce zabezpečení a další jakostní požadavky služby.

• Na nebo poblíž začátku každé opakování vypracovat požadavky na tyto funkce podrobněji.Určete kroky, které bude následovat uživatelů je definování pomoci diagramy činnosti nebo posloupnosti.Definujte, co se stane ve výjimečných případech.

• Ověřte často možné všech požadavků, které byly implementovány.Všude požadavky, jako je zabezpečení, musí být ověřena s testy, které jsou rozšířené pro každou novou funkci.Protože automatické testy lze průběžně provádět pokud možno automatizovat zkoušky.

Správa změn požadavků

Následující pokyny vám umožňují pracovat dílčích procesů při sledování jeho požadavky CMMI.

• Neměňte požadavky, které jsou nastaveny pro iteraci.Ve vzácných případech náhlému změna okolností pravděpodobně zrušit iteraci, přezkoumat plán produktu a začít novou iteraci.

• Vyhledejte nejistoty v požadavcích.Zkuste uspořádat plán tak, aby uživatelské zkušenosti s iterací včasného dává informace, které snižuje nejistot.

• Pomocí položky požadavku práce změnit zaznamenávat požadavky změnit chování, které již bylo provedeno, pokud požadovaná zlepšení již není součástí plánu.Propojte každý požadavek na změnu pracovních položek odpovídající požadavku.Další informace naleznete v tématu Požadavek na změnu (CMMI).

• Zkontrolujte požadavky na změnu při kontrole výrobku před každou iteraci.Dopad požadavek na závislé projekty a uživatele a odhad nákladů s ohledem na změny v kódu.Pokud je přijat požadavek na změnu, aktualizujte požadavek.

• Testy splňují všechny požadavky změnit aktualizujte.

• Určete koncové datum (například po iterace 2 nebo 3) po které požadavky na změny musí být mnohem více důrazně odůvodněné.Pokud je projekt pro platební zákazníka, je datum mít zákazník schválí základní sada požadavků a přepnout z hodinová platba na pevnou cenu.

• Pomocí bug pracovní položky se neprovádí podle požadavků explicitní nebo implicitní chování implementováno záznamu.Pokud je to proveditelné, vytvořte nový test, který by mít ulovených chyb.

Zápis prohlášení vize

Diskutovat o záměru s týmem a zobrazit na Web portálu projektu pro Team Foundation Server.

Prohlášení výhled je krátký souhrn o jaké výhody produktu přinese.Co uživatelé budou moci provádět nelze provést?Prohlášení vize pomáhá vyjasnit rozsah výrobku.

Pokud již produkt zapisovat záměru pro tuto verzi.Co produktu uživatelé budou moci provádět nelze provést?

Psaní scénářů

Práce s zákazníkovi a ostatních zainteresovaných stran vytvořit scénáře a zadat jako požadavek pracovní položky s poli Typ požadavku, nastavte scénář.

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

Uveďte popisný název, který jasně odlišuje od ostatních při zobrazení v seznamu.Přesvědčte se, zda je uvedeno hlavní actor nebo objekty actor a jejich cílem je vymazat.Například by to bylo dobré nadpis:

Zákazník nakupuje pokrmu.

Následující formuláře můžete psát scénáře.Někdy může pomoci použít více než jeden formulář:

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

  Zákazník objednávky pokrmu na webu a zaplatí prostřednictvím platební karty.Pořadí je předána restaurace, které připraví a nabízí jídla.

• Popis položky očíslovaných kroků na práci:

  Zákazník návštěvy webového serveru a vytvoří objednávky pro pokrmu. Webový server přesměruje webu platby k provedení platby odběratele. Pořadí je přidán do seznamu práce restauraci. Restauraci připraví a nabízí jídla.

• Scénáře.Scénáři je v podstatě pruh Kreslený vtip, že článek.Je možné nakreslit v aplikaci PowerPoint.Scénáře soubor připojit k pracovní položku požadavek nebo soubor odeslat týmu portálu a přidat hypertextový odkaz na položku práce.

  Scénáři je užitečné pro zobrazení interakce uživatele.Ale pro obchodní scénář je doporučeno používat skicy styl, který umožňuje vymazat, že to není konečný návrh uživatelského rozhraní.

• Požadavek dokumenty.Požadavek dokumentů umožňují volný pohyb odpovídající úroveň detailů pro každý požadavek.Pokud se rozhodnete používat dokumenty, vytvořit dokument aplikace Word pro každý požadavek a připojit dokument k pracovní položku požadavek nebo soubor odeslat týmu portálu a přidat hypertextový odkaz na položku.

• Sekvenční diagram Sjednocený Markup Language (UML).Sekvenční diagram je zvláště užitečné, pokud několik stran spolupracovat.Objednání jídla vyžaduje například zákazníka, na webu DinnerNow, platebním systému a restauraci pracovat v určitém pořadí.Kreslení sekvenční diagram modelu UML, zkontrolujte jej do Team Foundation Servera zadejte položku požadavek odkaz.Další informace naleznete v tématu Sekvenční diagramy UML: pokyny.

Specifické scénáře

Spustit zapisování určitých scénářů, které konkrétní sadu aktérů specifickou řadou.Například "Carlos objednávky pizza a česnek chléb na webu DinnerNow.Webový server přesměruje Carlos služby platby banky Woodgrove Bank.Čtvrtý kávy připraví pizza a doručí jej.

Specifické scénáře pomoci stanovit systém používán a jsou nejužitečnější, když nejprve vyzkoušet funkce.

Může být také užitečné k vytvoření pojmenované personas, které popisují pozadí a další činnosti osob a organizací.Carlos hrubě v režimu spánku a používá internetové kavárně; Wendy žije v gated Společenství; Sanjay objednávky jídla pro svou manželku při své práci; Contoso spustí řetězec 2 000 restaurací po celém světě; Čtvrtý kávy je spustit pár, který byl podle jízdních kol.

Může být vhodnější obecnější scénářů, které jsou zapsány jako "zákazník," "položku nabídky," a podobně, ale pravděpodobně povede k zjištění užitečné funkce.

Úrovně podrobností

Iterace 0 zapsat několik důležitých scénářích podrobně, ale psát většiny scénářů osnovy.Při iteraci přístupů ve které konkrétní scénář je plně nebo částečně implementována, přidat více podrobností.

Pokud nejprve zvažte scénář, může být užitečné popsat kontext obchodní i aspekty, které trvá produkt žádná část.Například popisují DinnerNow metodu doručení: každá restaurace uspořádat vlastní dodávky nebo DinnerNow spustit službu doručení?Odpovědi na tyto otázky poskytují užitečné kontext pro vývojový tým.

Rozvíjet na začátku iteraci podrobnější scénáře můžete popsat interakce uživatelské rozhraní a scénářů lze 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é zobrazit každý scénář jako případu použití.Tato metoda je doporučena, protože díky tomu scénáře velmi snadno prezentovat a diskutovat.Další informace naleznete v tématu Diagramy případu použití UML: pokyny.

  • Pracovní položka definující scénáře propojení každého případu použití.Další informace naleznete v tématu Propojení prvků modelu a pracovních položek.

  • Kreslit rozšiřuje vztahy zobrazit jeden scénář je změnu jiného.Například "Zákazníka určuje oddělené platby a adres dodání" je rozšíření základní "Stává zákazník objednávku" případu použití.Rozšíření jsou zvláště užitečné oddělit scénářů, které budou prováděny později iterace.

  • Nakreslete vztahů zahrnuje oddělit postup jako "Zákazník přihlásí," společné pro několik případů použití.

  • Nakreslete generalizace vztahy mezi obecné scénáře například "Zákazník platí" a určité varianty jako "Zákazník platí kartou."

• Nadřazený podřízený, vytváříte propojení mezi scénáři pracovních položek v Team Foundation Server. Můžete zobrazit hierarchii v Průzkumník týmových projektů.Další informace naleznete v tématu Uspořádání požadavků do plánu produktu.

Model domény business

Vytvoření modelu UML popisující hlavních činností a koncepty, které se týkají používání produktu.Podmínky, které jsou definovány v tomto modelu jako "komunikační jazyk", použijte v situacích, v diskusích s zúčastněných osob, v uživatelském rozhraní a všechny uživatelské příručky a samotného kódu.

Mnoho požadavků nejsou výslovně uvedeny podle vašeho zákazníka a porozumění předpokládané požadavky závisí na pochopení domény business, kontext, ve kterém bude funkční produkt.Některé úkoly požadavky shromažďování v cizí doméně je tedy o získání znalostí v této souvislosti.Po navázání tohoto druhu znalostí lze použít na více než jeden projekt.

Uložte model řízení verze.

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

Modelování chování

Nakreslete diagramy činnosti sumarizovat scénáře.Skupiny akcí prováděných různými aktéry pomocí dráhami.Další informace naleznete v tématu Diagramy činnosti UML: pokyny.

Přestože scénář obvykle popisuje konkrétní posloupnost událostí, diagram činnosti jsou uvedeny všechny možnosti.Výkresu diagramu činnosti může vyzvat přemýšlet o alternativní sekvencí a požádat obchodní klienti, co by mělo nastat v těchto případech.

Následující obrázek znázorňuje jednoduchý příklad diagramu činnosti.

Výměnu zpráv je důležité, mohou být účinnější použití sekvenční diagram obsahující životnost pro každý objekt actor a součást hlavních produktů.

Shrnutí různých toků produkt podporuje aktivity umožňují diagramy případu použití.Každý uzel v diagramu představuje řadu interakcí mezi uživatele a aplikace při sledování cíle konkrétního uživatele.Můžete také faktor společné sekvencí a volitelné rozšíření do samostatné použití uzlů case.Další informace naleznete v tématu Diagramy případu použití UML: pokyny.

Následující obrázek znázorňuje jednoduchý příklad diagramu případu použití.

Koncepty modelování

Nakreslete diagramy třídy domény popisující důležité subjekty a jejich vztahy, které jsou zmíněny v situacích.DinnerNow model zobrazuje například restaurace, nabídky, objednávky, nabídky a podobně.Další informace naleznete v tématu Diagramy tříd jazyka UML: pokyny.

Popisek role (ukončení) relace s názvy a cardinalities.

V diagramu třídy domény můžete nepřipojujte obvykle operací na třídy.Diagramy činnosti v modelu domény popisují chování.Určení odpovědnosti třídy program je součástí vývojové práce.

Následující obrázek znázorňuje jednoduchý příklad diagramu třídy.

Statické omezení

Diagramy tříd přidáte omezení, které řídí atributy a vztahy.Například zboží na objednávce musí všechna pocházet ze stejné restaurace.Tyto typy pravidel jsou důležité pro návrh produktu.

Konzistence modelu

Zajistěte, aby byly konzistentní model a scénáře.Jedním z nejúčinnějších použití modelu je vyřešit nejasnosti.

• Popisy scénář použít podmínky, které jsou definovány v modelu a jsou v souladu se vztahy, které definuje.Pokud model definuje položky nabídky, by neměly scénáře naleznete totéž jako produkty.Diagram třídy ukazuje, že položka nabídky patří právě jednu nabídku, scénáře by neměla hovořit sdílení položky nabídek.

• Každý scénář popisuje řadu kroků povolených diagramy činnosti.

• Scénáře nebo činností popisují, jak je vytvořen a likvidaci každé třídy a vztah v diagramu třídy.Například jaký scénář vytvoří položku nabídky?Když je zničen objednávky?

Vývoj jakosti požadavky služby

Vytvoření pracovních položek, které určují kvalitu požadavky služby.Nastavte pole Typ požadavku na kvalitu služeb.

Kvalita služby nebo funkční požadavky zahrnují výkonu, použitelnosti, spolehlivost, dostupnost, integrity dat, zabezpečení, cenovou dostupnost, použitelnost a možnost upgradovat, deliverability, požadavky na servis, návrhu a přizpůsobit a dokončit.

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

Název každé jakosti požadavku služby by měl zachytit jeho definice prezentuje kontext, akce a měření.Můžete například vytvořit následující požadavek: "Při vyhledávání v katalogu vrátí výsledky hledání v nejméně tří sekund."

Navíc je užitečné zachytit více podrobností, která vysvětluje, proč je nezbytné požadavky.Popište, proč by persona hodnota požadavku a proč je nutné tuto úroveň služeb.Zadejte kontext a zdůvodnění.Toto vysvětlení mohou zahrnovat informace o správě riziko užitečné údaje z průzkumu trhu, zájmovou skupinu odběratelů nebo studie použitelnosti; help desk sestavy nebo lístky; nebo jiné anecdotal doklady.

Kvalita služby požadavek propojte všechny scénáře (pracovní položky požadavku), který je ovlivněna kvalita služby.Propojení souvisejících pracovních položek umožňuje uživatelům Team Foundation Server ke sledování závislé požadavky.Dotazy a sestavy můžete zobrazit, jak ovlivňují kvalitu požadavky služby funkční požadavky, které jsou zachyceny jako scénáře.

Přehled požadavků

Pokud požadavky byly zapsány nebo aktualizovány, měla být kontrolována podle příslušné zúčastněné strany k zajištění, že dostatečně popisují všechny interakce uživatele s produktem.Společné zúčastněné strany patří předmět odborné obchodní analytik a architekt uživatelské zkušenosti.Scénáře jsou přezkoumány také zajistit mohou být implementovány v projektu bez jakékoliv nejasnosti nebo problémy.Pokud problémy se nanese, scénářů musí být stanovena tak, aby byly platné v závěru této činnosti.

Vytvořte pracovní položku přezkoumání sledovat recenze.Tato položka poskytuje důležité důkazy pro standardní způsob hodnocení CMMI hodnocení zlepšování procesu (SCAMPI) a může poskytnout dobrý zdroj informací pro analýzy kořenové příčiny v budoucnosti.

Zkontrolujte každý scénář pro následující vlastnosti:

• Scénář je zapsán v kontextu co úkol musí provést, co již vědí a očekávají způsob práce s tímto produktem.

• Scénář popisuje problém a neporuší navrhované řešení problému.

• Jsou identifikovány všechny příslušné uživatelské interakce s produktem.

• Předmět odborníka, obchodní analytik a architekt uživatelských zkušeností přezkoumat každý scénář v rámci projektu ověřit, že je úspěšně provedeny všechny scénáře.Pokud scénář není platný, je revidován tak, aby byly platné.

• Scénáře lze implementovat s dostupné techniky, nástroje a prostředky a v rámci rozpočtu a plánu.

• Scénář má jediný výklad, který je snadno srozumitelné.

• Scénář není v konfliktu s jiným scénář.

• Scénář je testable.

Ověření

Plánování nasazení do své pracovní prostředí před jeho konečné verze beta verze produktu.Plánujete požadavky, na základě názorů účastníky z nasazení této aktualizace.

"Ověřením" rozumí zajišťující, že výrobek splňuje jeho zamýšlené použití v jeho operačním prostředí.V rámci MSF pro CMMI ověření dosáhnete prokazování pracovní software zúčastněným stranám na konci každé iteraci v celém projektu.Plán je uspořádány tak, aby se týká, získávají zpět z rané předvádění a vývojáři mohou řešit v plánu pro zbývající počet iterací.

Dosáhnout true ověření výrobku nesmí být spuštěn pouze v prokázání nebo simulované kontextu.Pokud je proveditelné, že musí být testovány v reálné podmínky.

Kontrola a úpravy požadavky

Scénář a jakostní požadavky služby, které vést k většinu úkolů rozvoje, mohly být kontrolovány pomocí dotazu požadavky zákazníka.Pokud chcete zobrazit všechny požadavky, můžete napsat dotaz, který vrátí všechny pracovní položky typu požadavku pracovní položky.Nastavte sloupce výsledek iterace cestu zobrazit.Další informace naleznete v tématu Sdílené dotazy (CMMI).

Kromě zobrazení dotazu přímo v Průzkumník týmových projektů nebo Team Web Access, můžete otevřít v Office Excel nebo Microsoft Office Project.Tyto nástroje jsou vhodnější pro úpravy a přidávání pracovních položek jako dávka.Další informace naleznete v tématu Práce v aplikaci Microsoft Excel a Microsoft Project připojené k Team Foundation Server a Provedení plánování shora dolů pomocí stromu seznam pracovních položek (V aplikaci Excel).

Tým vytvořte většinu požadavků v raném iterací projektu.Budou přidány nové požadavky a jiné upraveny jako názory získané z dřívější verze.

Další zdroje informací

Další informace naleznete na následujících webech:

• Praktické vodítko k funkci řízený rozvoj, Stephen R.Palmer a Miroslav J.Felsing; Prentice Hall PTR, 2002.

• Efektivní modelování objektu: Vzorky, pravidla a implementace, Jill Nicola, Mayfield značkou a Mike Abney; Prentice Hall PTR, 2001.

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

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

• Návrhu objektu: Úkoly, odpovědnost a spolupráce společnosti Wirfs-Brock Rebecca a Alan McKean; Addison Wesley Professional 2002.