Compartilhar via

Organizar requisitos em um plano de produto

  • Artigo

Depois de analisar seus requisitos de cliente para entender o que o produto deve fazer, você deve trabalhar um plano para implementar o produto. Ou, para um produto existente, você deve trabalhar qual funcionalidade está ausente e elaborar um plano para fazer as alterações. Mas os requisitos automaticamente informa o plano.

Este tópico descreve um método de obtenção de um plano, a partir de um conjunto de requisitos. Isso é apenas um método entre uma variedade funcionará em Visual Studio, e você deve adaptá-la para que ele atenda às suas necessidades.

Você pode usar o pendências e listas de pendências de portfólio para definir e mapear os requisitos e recursos.

Requisitos e recursos

Há dois tipos de requisito nesse método: recursos e requisitos do cliente. Requisitos do cliente são os resultados obtidos ao analisar o que o cliente deseja do produto. Recursos são itens no plano de produto, que correspondem aos pequenos subconjuntos das necessidades do cliente. Cada recurso pode incluir partes dos requisitos de cliente que vêm de diferentes partes da experiência do usuário e as áreas funcionais.

Requisitos do cliente

  • Requisitos do cliente são determinados pela discussão com os usuários em potencial e outros participantes.

  • Para ajudar a analisar esses requisitos, você normalmente cria modelos e storyboards e decompor os cenários em etapas menores, formando uma árvore. Você pode vincular elementos como casos de uso e atividades para itens de trabalho do cenário de modelagem.

  • Há dois tipos de requisitos do cliente:

    • Cenários, também conhecido como casos de uso, representam sequências de interações entre os usuários e o produto na objetivos específicos. Um cenário de exemplo pode ter o título "Usuário compra um livro."

    • Qualidade de serviço incluem o desempenho, segurança, usabilidade e outros critérios.

  • Você pode representar esses requisitos como itens de requisito de tipo de trabalho com o campo de tipo de requisito definido para o cenário ou a qualidade de serviço. Para obter mais informações, consulte Requisitos de desenvolvimento.

  • Esses itens de trabalho de requisito devem ser vinculados aos testes de sistema para que você possa garantir que todos os requisitos são testados. Consulte Planejar testes manuais usando o Team Web Access.

  • Exibir a lista de pendências ou abra a consulta a necessidade do cliente para listar esses itens de trabalho de requisito.

  • Use o Relatório Andamento de Requisitos (CMMI) relatórios para monitorar quais requisitos foram atendidos.

Recursos

  • Um recurso é um item em um plano de produto que representa um grupo de tarefas. Planejamento do produto, representantes da equipe de desenvolvimento e participantes atribuir recursos para iterações. Para obter mais informações, consulte Planejar um projeto (CMMI).

  • Insira recursos como conjunto de itens de trabalho de requisito com o campo tipo de requisitos para o recurso.

  • Título do recurso declara, em termos de usuários, o que os usuários serão capazes de fazer com o produto, o que eles não poderiam fazer nas iterações anteriores. Há nenhum item ou muito poucos itens, no plano que não fornecer um novo valor de usuário.

    Por exemplo, essa seqüência de recursos pode formar um plano de implementação:

    • "Um comprador pode escolher de uma lista de um livro e adicioná-lo a uma lista de desejos."

    • "A lista de livros exibe os preços. Na lista de desejos, o preço total é exibido."

    • "Fornecedores podem anexar marcas de livros. Compradores podem filtrar a lista de livros por marca."

    Observe que nenhum recurso toca apenas uma etapa na experiência do usuário e nenhum recurso envolve apenas uma parte da arquitetura do produto. Em vez disso, como os recursos são implementados, várias funções são revistas e incrementadas com o novo valor de usuário.

  • Um recurso é atribuído a uma iteração durante o planejamento do produto. Todas as tarefas em um recurso devem ser atribuídas à iteração mesma.

  • Um recurso descreve uma percepção parcial dos requisitos de cliente. É um subconjunto dos requisitos de cliente e ele pode implementar o requisito de cada cliente até certo ponto.

  • Todos os recursos podem ser vinculados a um ou mais casos de teste que testam a parte dos requisitos que representa o recurso. Nesses casos de teste são um subconjunto dos testes de sistema que são vinculados para as necessidades do cliente.

  • Estado do recurso não deve ser marcado concluído até que os testes são totalmente definidos e passam.

  • Cada recurso é um grupo de tarefas de desenvolvimento e teste. É a raiz de uma árvore de tarefas. As tarefas de desenvolvimento implementam os requisitos parciais que descreve o recurso. As tarefas de teste criar e executar casos de teste apropriados.

  • Use a consulta de requisitos de produto a recursos da lista.

Localizando recursos

Separar os requisitos em recursos incrementais é uma tarefa criativa que deve envolver participantes, analistas e desenvolvedores. Um recurso define uma parte da funcionalidade do produto que facilmente pode ser implementada separadamente das funções ao redor. Portanto, um conjunto viável de definições de recursos e uma ordenação em um plano depende em parte, a arquitetura do sistema.

Por esse motivo, o planejamento e o design inicial do produto devem trabalhar em paralelo, particularmente na iteração 0 onde a maior parte do plano está sendo elaborada.

Decomposição de cenário

Para ajudá-lo a organizar os requisitos de recursos, ele ajuda a decompor os cenários em etapas menores.

Storyboards geralmente ajudam com esta atividade. Um storyboard é uma seqüência de imagens que ilustram o cenário. Diagramas de atividade UML são úteis para mostrar caminhos alternativos e diagramas de sequência UML podem ajudá-lo a discutir as interações entre vários atores. Depois que você pode usar essas ferramentas para analisar um cenário, você pode inserir os cenários decompostos em Team Explorer. Isso permite vincular casos de teste para os cenários e, portanto, certifique-se de que os requisitos foram atendidos. Para obter mais informações, consulte Diagramas de atividade UML: diretrizes e Diagramas de sequência UML: diretrizes.

Recursos - requisitos preenchidas em cada iteração

Um recurso é um requisito que resume o que os usuários podem fazer após a conclusão de cada iteração. Você pode criar mais de um recurso para cada iteração. Digite-os como itens de trabalho de requisito, definindo o tipo de requisito de recurso.

Use as atribuições de cenários para itens de trabalho para ajudá-lo a definir os recursos. O plano de recurso de exemplo a seguir é derivado de atribuições de cenários para iterações na seção anterior:

  • Iteração 1

    • Cliente escolhe itens em um menu, adiciona-os a um pedido e adiciona um endereço de entrega.

  • Iteração 2

    • Os clientes começa exibindo uma lista de restaurantes e, em seguida, escolha um.

    • Quando o cliente conclui uma ordem, a ordem é exibida na tela do restaurante escolhido.

    • Os preços de itens e o preço total são exibidos na ordem.

  • Iteração 3

    • Restaurante marca a ordem como "Done" quando a refeição preparada foi enviada. A refeição será registrada no restaurante.

    • Cada restaurante pode inserir e atualizar seu menu.

    • Cliente pode procurar o menu de cada restaurante antes de selecionar um.

  • 4 de iteração

    • Cliente entra em detalhes de pagamento na conclusão de um pedido. Cartão do cliente será cobrado quando o restaurante marca a ordem como concluídas.

    • Restaurante é pago por pedidos que estão marcados como concluídas.

  • Iteração 5

    • Restaurantes podem definir suas áreas de entrega. Cliente insere código postal no início da sessão. O site da Web exibe apenas os restaurantes podem fornecer para a rede local.

Cenários parcialmente implementados

Decompondo os cenários em pequenas etapas ajuda você a separar algumas etapas que podem ser implementadas antes de outras pessoas que podem ser implementados mais tarde.

Mas, às vezes, você pode separar outros aspectos dos cenários. Neste exemplo, a equipe pode implementar uma versão básica da experiência do usuário em primeiras iterações e aprimorá-la posteriormente. Portanto, você pode adicionar o seguinte recurso:

  • Iteração 6 - restaurante pode escolher o esquema de cores e a fonte do menu e carregar seu próprio logotipo e imagens de refeições.

Esse tipo de recurso não emerge diretamente a decomposição em etapas, mas ela geralmente surge na discussão de storyboards. Recursos da experiência do usuário são bons candidatos para iterações posteriores.

Inserindo e recursos de inspeção

Criar itens de trabalho com o tipo de item de trabalho de requisito e definir o campo de tipo de requisito para o recurso. Defina o título de recurso para a descrição resumida.

Recursos aos requisitos de rastreamento

Você pode vincular recursos aos requisitos das seguintes maneiras:

  • Vincular itens de trabalho do recurso para os requisitos do cenário de folha de suas iterações. Você deve vinculá-las usando links de Item relacionado porque os cenários de folha já tem os pais.

  • Vincular itens de trabalho de caso de teste para os cenários e a qualidade dos requisitos de serviço que os testes. Vincular recursos ao subconjunto de casos de teste que devem passar quando o recurso foi desenvolvido. Dessa maneira, os casos de teste agem como o link entre os recursos e requisitos do cliente.

Qualidade de recursos de serviço

Qualidade de serviço são normalmente predominante em relação ao design de software. Por exemplo, requisitos de segurança não geralmente estão relacionados a uma tarefa de desenvolvimento específico.

No entanto, para cada qualidade de requisito de serviço, você deve criar um item de trabalho de recurso cujos filhos estão testando principalmente tarefas que garantem que uma qualidade de critério de serviço for atendida. Esses itens de trabalho são chamados de qualidade dos recursos de serviço.

Alguns qualidade dos recursos de serviço pode ter tarefas de desenvolvimento. Por exemplo, em uma iteração inicial, você pode implementar uma versão do sistema que pode manipular apenas alguns usuários, como uma prova de conceito. Para uma iteração mais recente, você pode adicionar um recurso que especifica a capacidade de destino conforme indicado nas necessidades do cliente.

Planejamento do produto

Antes do início de cada iteração, fazer uma reunião para revisar o plano de produto. Reunião de planejamento do produto primeiro cria o plano e reuniões subseqüentes revisá-lo com base em iterações anteriores. Para obter mais informações, consulte Planejar um projeto (CMMI).

Em um plano de produto examinar, discutir os recursos com os participantes de negócios e estar preparado para priorizar novamente-los e organizá-los em diferentes iterações. A reunião deve incluir representantes da equipe de desenvolvimento e partes interessadas no negócio.

A reunião discute a sequência na qual os recursos serão desenvolvidos. Isso pode ser feito por projetar ou compartilhamento de tela de Office Excel modo de exibição de consulta requisitos de produto e os recursos de ordenação por iteração.

Uma técnica alternativa é colocar os recursos em uma seqüência específica e, em seguida, considere a quantidade pode ser feito em cada iteração. Por exemplo, os desenvolvedores podem discutir se "cliente pode exibir os preços" deve ser movido da iteração 2 a 3 de iteração, sem movê-lo na sequência. Para colocar os itens em uma seqüência, adicione uma coluna extra chamada classificação na planilha e inserir números inteiros que indicam a sequência. Ordem da planilha por esta coluna. As classificações não serão armazenadas em Team Foundation Server, mas você pode salvar a planilha. Quando você abre a planilha novamente, clique em qualquer célula na tabela de itens de trabalho e, em seguida, clique em Atualizar na guia da equipe.

Planejamento do produto considera as prioridades dos recursos e os custos de desenvolvimento. Prioridades vêm os participantes de negócios, com algumas orientações sobre o risco dos desenvolvedores. Custo estimativas vêm dos desenvolvedores. Para obter uma ideia precisa dos custos, a equipe de desenvolvimento deve ter já trabalhou na arquitetura do produto e precisa de algumas terá das primeiras iterações. Por esse motivo, as estimativas de custo devem ser refinadas em cada revisão do plano de produto.

Planejamento de iteração

Depois da revisão do plano de produto, planeje a iteração. O plano de produto determina os recursos que serão entregues até o final da iteração. O plano de iteração determina que a equipe fará para implementar e testar os recursos de trabalho.

As seguintes atividades são parte do planejamento de iteração:

  • Criar tarefas para desenvolvimento e teste e vinculá-los como filhos os requisitos de recurso.

  • Crie casos de teste para os aspectos do cliente requisitos que devem ser desenvolvidos em cada recurso. Os casos de teste devem ser vinculados para as necessidades do cliente para que você possa monitorar os requisitos são completas.

Você também pode vincular casos de teste aos recursos, você pode controlar a correspondência entre os recursos e requisitos. O recurso não deve ser marcado concluído até que passe os casos de teste vinculados.

Para obter mais informações, consulte Planejar uma iteração (CMMI).