Sdílet prostřednictvím

Vývoj požadavků

  • Článek

Požadavky jsou popsány investorů očekávat z produktu.Vaše požadavky mají vyjádřit v číslech, umožňující snadno projednána se zúčastněnými stranami podniku pomocí slovníku a koncepty business domény.Požadavky by měla projednat ani závisí na provedení.Požadavky zahrnují nejen chování a kvalitu služeb očekávání uživatelů, ale také zákonné omezení a obchodních norem.

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

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

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

  • Požadavky na celkovou strukturu a podrobnější požadavky, takže je lze snadněji spravovat a tak, aby zprávy o pokroku lze shrnout informace.

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

Toto téma se nepokouší velmi velkou část dokumentace, která je k dispozici na předmět určení požadavků na replikaci.Místo toho jej se zaměřuje na aspekty, které jsou důležité pro použití Visual Studio způsobem, který odpovídá CMMI nástroje.Další informace o knihovnách CMMI naleznete v tématu Základní informace o CMMI.

Činnosti, které jsou popsány v tomto tématu, stejně jako všechny vývojové činnosti by neměla provést v přísné pořadí.Vývoj modelu domény při psaní scénáře protože jedna aktivita pomůže, že zlepšení jiné činnosti.Vyvinout scénáře jako čas pro kódování jejich přístupů.Zkušenosti s kódem, který je zapsán a prokázat krmení zpět do scénáře, které ještě mají být provedeny.

Při vývoji požadavků

TFS podporuje iterativní práci a tento postup je nejúčinnější při včasné iterací slouží k získání zpětné vazby od potenciálních uživatelů a dalšími zúčastněnými stranami.Tento názor lze zlepšit požadavky, které jsou uvedeny pro budoucí iterací.Výsledkem je produkt, který je mnohem účinnější při konečné instalaci než produkt, který je vyvinutý v tomtéž období bez jakékoli hodnocení uživatele.Pokud váš projekt je jedna ze součástí mezi mnoha větší aplikace, umožňuje včasné integrace s jinými součástmi architects program ke zlepšení celkového produktu.

Tato flexibilita musí být vyváženo potřebu dát pevné závazky zákazníkům nebo partnerům v paralelních projektech.

Řízené rozsahu tedy požadavky jsou vyvíjeny a kontrast v celém projektu.Vzhledem k tomu, že podrobné požadavky se mohou změnit během projektu, stanovení v plné výši před provedení bude pravděpodobně za následek plýtvat úsilí.

  • V opakování 0 vytvořte sadu požadavků, které popisují hlavní funkcí právě dostatek podrobných informací k vytvoření plánu produktu.Plán produktu přiřazuje požadavky iterací a je uvedeno, jaké požadavek bude splněn na konci každé iteraci.Vytvoření modelu domény, hlavní pojmy a činnosti a definování slovníku, který bude použit pro tyto koncepce v diskusi s uživateli i v provedení.Určení hlavních požadavků, které pervade všechny funkce, jako je zabezpečení a další jakostní požadavky na služby.

  • Nebo blízko začátku každé iteraci rozvíjet požadavky pro tyto vlastnosti podrobněji.Určete kroky, které bude následovat uživatelů, definování jejich činnosti nebo sekvence diagramy pomocí.Definujte, co se stane, že ve výjimečných případech.

  • Co nejčastěji všech požadavků, které byly implementovány ověření.Objevují požadavky, jako je zabezpečení, je nutné ověřit pomocí testů, které jsou rozšířeny pro každou novou funkci.Pokud možno automatizovat zkoušky, protože automatické testy lze provádět průběžně.

Správa změn požadavků

Následující pokyny vám umožňují pracovat přírůstkové proces při sledování jeho požadavkům CMMI.

  • Neměňte žádné požadavky, které jsou nastaveny pro iteraci.Ve výjimečném případě náhlému změna okolností bude pravděpodobně nutné zrušit iterace, zkontrolovat plán produktu a spusťte novou iteraci.

  • Vyhledejte nejistoty v požadavcích.Pokuste se uspořádat plán tak, aby uživatelské zkušenosti s dřívější iterací dává informace, které snižuje nejistoty.

  • Pomocí položky práce změna požadavku zaznamenávat požadavky Chcete-li 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žadavek.

  • Zkontrolujte požadavky na změny při kontrole výrobku před každou iteraci.Přezkoumá účinek požadavek na závislé projekty a uživatelů a odhadování nákladů s ohledem na změny ve vašem kódu.Když je přijat požadavek na změnu, aktualizujte požadavek.

  • Aktualizujte zkoušky, které splňují všechny požadavky na změny.

  • Určete datum přerušení (například po iterace 2 nebo 3) po které požadavky na změny musí být odůvodněna mnohem silněji.Pokud váš projekt platících zákazníků, to je datum, které má zákazník schválí základní sada požadavků a přepnout z hodinová platba na pevnou cenu.

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

Zápis záměru

Projednání záměru s týmem a zobrazit na webovém portálu projektu pro Team Foundation Server.

Záměru je krátký souhrn co výhody produktu přinese.Co uživatelé budou moci udělat, aby se nemohla před?Záměru pomůže objasnit rozsah produktu.

Pokud již produkt napište záměru pro tuto verzi.Co uživatelé produktu budou provádět, aby se nemohla před?

Psaní scénářů

Práce se zákazníkem a dalšími zúčastněnými stranami, vytvoření scénáře a zadat jako pracovní položky požadavku, s polem Typ požadavku, nastavte na 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 interakce mezi lidmi a organizacemi a počítačů.

Zadejte popisný název, který jasně odlišuje od ostatních při zobrazení v seznamu.Ujistěte se, uvádí hlavní herec nebo subjekty a aby jejich cíl byl jasný.Například by to bylo dobré hlavy:

Zákazník si koupí pokrm.

Můžete napsat scénář v těchto formách.Někdy můžete použít více než jeden formulář:

  • Jedna nebo dvě věty v popisu pracovní položky:

    Zákazník objedná pokrm na webu a zaplatí platební karty.Pořadí je předán k restauraci, která připravuje a nabízí jídla.

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

    1. Zákazník navštíví na webu a vytvoří objednávky pro pokrm.

    2. Webový server přesměruje na web platby k provedení platby zákazníka.

    3. Pořadí je přidán do seznamu práce restauraci.

    4. Restauraci připravuje a nabízí jídla.

  • Scénáře.Scénář je v podstatě proužek Kreslený vtip říká č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ál a přidat hypertextový odkaz na položku práce.

    Scénář je zvláště 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 na 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 k požadavku pracovní položku, dokument nebo soubor odeslat týmu portál a přidat hypertextový odkaz na položku práce.

  • Sekvenční diagram jednotný Markup Language (UML).Sekvenční diagram je zvláště užitečná, je-li několik stran spolupracovat.Objednává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 odkaz do pracovní položky požadavku.Další informace naleznete v tématu Sekvenční diagramy UML: Pokyny.

Konkrétní scénáře

Začněte psát konkrétní scénáře, které konkrétní sadu specifickou řadou činitelů.Například "Carlos objednávky pizza a česnek chléb na webu DinnerNow.Webový server přesměruje Carlos služby platba banky Woodgrove Bank.Fourth Coffee připraví pizza a doručí jej. "

Konkrétní scénáře můžete počítat systému používá a jsou velmi užitečné při prvním procházení funkce.

To může být užitečné vytvořit pojmenovanou 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 jeho manželka při své práci; Společnost Contoso spustí řetěz 2 000 restauracích po celém světě; Fourth Coffee je spuštěn pomocí páru, který doručit podle jízdních kol.

Obecnější scénářů, které jsou zapsány ve smyslu "zákazníkovi" "z nabídky," a tak dále může být pohodlnější, ale jsou méně pravděpodobné, že povede k zjištění užitečných funkcí.

Úrovně podrobností

V opakování 0 napsat několik důležitých scénářích podrobně, ale zápis většiny scénářů v osnově.Když se blíží iterace ve kterém konkrétním případě je plně nebo částečně implementována, přidat další podrobnosti.

Pokud nejprve zvažte scénáře, může být užitečné popsat i aspekty, které produkt účastní žádné obchodní kontextu.Například popisují DinnerNow způsob dodání: každá restaurace organizovat své vlastní dodávky nebo DinnerNow spustit služby doručení?Odpovědi na tyto otázky získáte užitečné kontext pro vývojový tým.

Podrobnější scénářů, které vyvinete na začátku iterace můžete popsat interakce uživatelské rozhraní a scénářů 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:

  • Kreslit diagramy případu použití, které ukazují jednotlivé scénáře jako případ použití.Tato metoda se doporučuje, protože scénáře je velmi snadno prezentovat a diskutovat.Další informace naleznete v tématu Diagramy případů použití UML: Pokyny.

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

    • Vystavení rozšiřuje vztahy chcete-li zobrazit tuto situaci, jeden je jinou variantu.Například "Zákazník Určuje samostatnou platbu a doručovací adresy" je rozšíření základní "Zákazník se stává objednávka" případ použití.Rozšíření jsou zvláště užitečné oddělit scénářů, které budou prováděny v pozdější opakování.

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

    • Kreslit generalizace vztahy mezi obecné scénáře jako "Zákazník zaplatí" a konkrétní varianty jako "Zákazník zaplatí kartou."

  • Vytvoření propojení mezi pracovní položky scénář nadřazený podřízený.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 organizační domény

Vytvoření modelu UML, který popisuje hlavní činnosti a konceptů, které jsou spojena s používáním produktu.Podmínky, které jsou definovány v tomto modelu jako "všudypřítomná jazyk", použijte v situacích, do diskuse zúčastněnými stranami, v uživatelském rozhraní a všechny uživatelské příručky a v samotném 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 pracovat na produkt.Některé úkoly v cizí doméně shromažďování požadavků je proto o získání znalostí o této souvislosti.Po navázání tohoto druhu znalostí lze použít na více než jeden projekt.

Uložte model ve verzi ovládacího prvku.

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

Modelování chování

Kreslit diagramy činnosti k sumarizaci scénáře.Plavecké dráhy slouží k seskupení akcí prováděných různými aktéry.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.Kreslení diagram činnosti může vyzvat přemýšlet o alternativní sekvence a požádat obchodní klienti, co by mělo nastat v těchto případech.

Následující ilustrace zobrazuje jednoduchý příklad diagram činnosti.

Aktivita s třemi akcemi a smyčky.

V případě výměny zpráv je důležité, může být efektivnější použití sekvenčního diagramu obsahující životnost pro každý objekt actor a součást hlavních produktů.

Diagramy případu použití umožňují shrnout různé toky aktivity, který podporuje váš produkt.Každý uzel v diagramu představuje řadu interakcí mezi uživatele a aplikace pro dosažení cíle daného uživatele.Můžete také faktor společných sekvencí a volitelné rozšíření do uzlů case pro samostatné použití.Další informace naleznete v tématu Diagramy případů použití UML: Pokyny.

Následující ilustrace zobrazuje jednoduchý příklad diagramu případu použití.

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

Koncepty modelování

Kreslit diagramy třídy domény popisující důležité subjekty a jejich vztahy, které byly uvedeny v situacích.DinnerNow model příkladem restaurace, nabídky, objednávky, položky nabídky a podobně.Další informace naleznete v tématu Diagramy tříd UML: Pokyny.

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

V diagramu třídy domény není připojení obvykle operací na třídy.Diagramy činnosti v modelu domény popisují chování.Přiřazení odpovědnosti program třídy je součástí vývojové práce.

Následující ilustrace zobrazuje jednoduchý příklad diagramu třídy.

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

Statické omezení

Diagramy tříd přidáte omezení, které řídí atributy a vztahy.Například zboží na objednávce musí všechny 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.Jedno z nejúčinnějších použití modelu je vyřešit nejasnosti.

  • Popis scénáře použití za podmínek, které jsou definovány v modelu a jsou v souladu se vztahy, které definuje.Model definuje položky nabídky, scénáře by neměla odkazovat na totéž jako produkty.Diagram třídy ukazuje, že položka nabídky patří přesně nabídkami, neměli hovořit scénáře sdílení položky nabídek.

  • Každý scénář popisuje řadu kroků, které mohou diagramy činnosti.

  • Scénáře nebo aktivity popisují, jak jednotlivé třídy a vztah v diagramu třídy je vytvořen a zničeno.Například jaký scénář vytvoří položku nabídky?Při objednávce zničen?

Vývoj jakostních 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.

Kvalita služby nebo non funkční požadavky patří výkon, použitelnost, spolehlivost, dostupnost, integritu dat, zabezpečení, cenovou dostupnost, použitelnost a procesory, deliverability, udržovatelnost, návrhu a přizpůsobit a dokončit.

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

Název každé jakosti požadavku služby sbíral prezentuje kontext, akce a měření jeho definici.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 méně než tři sekundy."

Kromě toho je vhodné zachytit podrobněji vysvětluje, proč je nezbytné požadavky.Popište, proč by hlavní hodnota požadavku a proč je nutné tento rozsah služeb.Poskytují kontext a zdůvodnění.Toto vysvětlení mohou obsahovat informace o řízení rizika užitečné údaje z průzkumu trhu, cílová skupina zákazníků nebo studie použitelnosti; help desk sestavy/lístky; nebo jiné anecdotal doklady.

Kvalitu služeb požadavek propojte všechny scénáře (pracovní položky požadavku), který má vliv kvalitu služeb.Propojení souvisejících pracovních položek umožňuje uživatelům Team Foundation Server k udržení přehledu o závislé požadavky.Dotazy a sestavy můžete zobrazit vliv funkční požadavky, které jsou zachyceny jako scénáře jakostních požadavků na služby.

Přehled požadavků

Když byly zapsány nebo aktualizovat požadavky, je třeba přezkoumat podle příslušné zúčastněné strany k zajištění, že dostatečně popsat 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 také kontrolovány pro zajištění, aby mohl být zaveden v projektu bez jakékoliv nejasnosti nebo problémy.Pokud problémy se nanese, scénářů musí být stanovena tak, aby byly platné při ukončení této činnosti.

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

Projděte všechny scénáře pro následující vlastnosti:

  • Scénář je zapsán v souvislosti s co úkol musí provést, co již znají 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 označeny všechny příslušné uživatelské interakce s produktem.

  • Předmět odborné, obchodní analytik a architekt zkušenosti uživatele projít všechny scénáře v rámci projektu pro ověření, že je úspěšně provedeny všechny scénáře.Pokud scénář není platný, je revidován tak, aby byla platná.

  • Scénáře lze implementovat pomocí dostupné techniky, nástrojů a prostředků v rámci rozpočtu a plánu.

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

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

  • Lze je scénář.

Ověření

Plánujete nasadit na své pracovní prostředí před jeho konečné verze beta verze produktu.Chcete aktualizovat požadavky, na základě připomínek účastníků z tohoto nasazení.

"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 MSF pro CMMI je dosaženo ověření prokázat pracovní software zúčastněným stranám na konci každé iteraci v celém projektu.Plán je uspořádány takovým způsobem, který se týká, získávají zpět a vývojáři z rané předvádění se mohou řešit v plánu pro zbývající počet iterací.

K dosažení skutečné ověřování, výrobek nesmí být spuštěn pouze v prokázání nebo simulované kontextu.Pokud je možno, že by měly být zkoušeny ve skutečných podmínkách.

Prohlížení a úpravy požadavky

Scénář a jakostních požadavků na služby, které vedou k většině vývojářské úlohy, můžete zkontrolovat pomocí dotazu požadavky zákazníka.Pokud chcete zobrazit všechny požadavky, můžete vytvořit dotaz, , který vrací všechny pracovní položky Typ pracovní položky požadavku.Nastavte sloupce zobrazit cestu iterace výsledku.

Váš tým měli vytvořit většinu požadavků v raném iterace projektu.Budou přidány nové požadavky a ostatní upravenými tak, jak získané zpětné vazby dřívějších verzích.

Další zdroje

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