Compartilhar via

Requisitos de desenvolvimento

  • Artigo

Requisitos de descrevem o que esperam os participantes do produto. Você deve expressar suas necessidades em termos de quais eles podem facilmente ser discutido com as partes interessadas no negócio, usando o vocabulário e conceitos de domínio corporativo. Requisitos devem, discutir nem dependem da implementação. Requisitos incluem não apenas o comportamento e qualidade das expectativas dos usuários, mas também as restrições legais e comerciais padrões de serviço.

Criando requisitos no TFS, você obtém os seguintes benefícios:

  • Verifique se os requisitos foram atendidos vinculando-os a casos de teste.

  • Monitorar o andamento rumo Implementando os requisitos de vinculá-los aos itens de trabalho da tarefa.

  • Estruturar os requisitos em geral e requisitos mais detalhados para que você possa gerenciá-los mais facilmente e para que os relatórios de andamento podem resumir as informações.

  • Os requisitos de modelo Visual Studio Ultimate, elementos de modelo de vinculação requisitos Team Foundation Server.

Este tópico não tenta replicar o corpo muito grande de literatura disponível sobre o assunto de determinar os requisitos. Em vez disso, ele se concentra nos aspectos são importantes para usar o Visual Studio Ferramentas de uma maneira compatível com CMMI. Para obter mais informações sobre CMMI, consulte Plano de fundo para CMMI.

As atividades que são descritas neste tópico, como todas as atividades de desenvolvimento, não devem ser executadas na ordem estrita. Desenvolva um modelo de domínio enquanto você está gravando cenários porque uma atividade ajudará a que melhorar a outra atividade. Desenvolva cenários como o tempo para codificá-los abordagens. Feed a experiência com código gravado e demonstrou para os cenários que ainda precisam ser implementados.

Quando requisitos de desenvolvimento

TFS oferece suporte ao trabalho iterativo e essa prática é mais eficaz quando as primeiras iterações são usadas para obter comentários de usuários em potencial e outras partes interessadas. Este comentário pode ser usado para melhorar os requisitos estabelecidos para as iterações futuras. Isso resulta em um produto que é muito mais eficiente em sua instalação ultimate que um produto é desenvolvido no mesmo período sem qualquer versão de avaliação do usuário. Se seu projeto for um componente entre muitas em um programa maior, início integração com outros componentes permite que os arquitetos de programa aprimorar o produto geral.

Essa flexibilidade deve ser ponderada em relação a necessidade de dar compromissos sólidos para seus clientes ou parceiros em projetos paralelos.

Uma extensão controlado, portanto, requisitos são desenvolvidos e refinados em todo o projeto. Como os requisitos detalhados são provavelmente serão alterados durante o projeto, determinar-las por completo antes da implementação apropriada é provavelmente resultará em desperdício de esforço.

  • Na iteração 0, desenvolva um conjunto de requisitos que descrevem recursos principais, com detalhes suficientes para formar um plano de produto. O plano de produto atribui requisitos para iterações e informa o requisito será preenchido no final de cada iteração. Criar um modelo de domínio dos principais conceitos e as atividades e definir o vocabulário que será usado para esses conceitos em discussão com os usuários e na implementação. Determine requisitos abrangentes que pervade todos os recursos, como segurança e outra qualidade dos requisitos de serviço.

  • No ou no início de cada iteração, desenvolva os requisitos para esses recursos mais detalhadamente. Determine as etapas que os usuários seguirão, defini-los com a Ajuda de diagramas de atividade ou sequência. Defina o que acontece em casos excepcionais.

  • Verificar sempre que possível todos os requisitos que foram implementados. Requisitos abrangente, como segurança, deverá ser verificados com testes estendidos para cada novo recurso. Se possível, automatize os testes porque testes automáticos podem ser executados continuamente.

Gerenciamento de alterações de requisitos

As diretrizes a seguir permitem que você operar um processo incremental durante o monitoramento para atender aos requisitos de CMMI.

  • Não altere os requisitos que são definidos para uma iteração. No caso raro de uma alteração abrupta em circunstâncias, você talvez precise cancelar uma iteração, revise o plano de produto e iniciar uma nova iteração.

  • Procure incertezas nos requisitos. Tente organizar o plano para que a experiência do usuário com as primeiras iterações gera informações que reduz as incertezas.

  • Use itens de trabalho de solicitação de alteração para solicitações de registro para alterar o comportamento que já foi implementado, a menos que a melhoria solicitada já faz parte do plano. Vincule cada solicitação de alteração para os itens de trabalho de requisito apropriado.

  • Revise as solicitações de alteração ao analisar o produto antes de cada iteração. Examine o impacto da solicitação em projetos dependentes e usuários e estimar o custo em relação a alterações em seu código. Se uma solicitação de alteração for aceita, atualize o requisito.

  • Atualize os testes de acordo com cada alteração de requisitos.

  • Designe uma data de fechamento (por exemplo, após a iteração 2 ou 3) depois de quais alterações de requisitos devem ser muito mais fortemente justificadas. Se seu projeto for um cliente pagante, esta é a data para que o cliente aprovar um conjunto de requisitos e alternar de pagamento por hora para preço fixo.

  • Use itens de trabalho de bug para comportamento de registro implementado que não executa de acordo com os requisitos explícitos ou implícitos. Onde for possível, crie um novo teste que poderia ter pego o bug.

Escrever uma declaração de visão

Discuta uma declaração de visão com a equipe e exibi-lo no portal de Web do projeto para Team Foundation Server.

Uma declaração de visão é um breve resumo do que se beneficiar do produto fará. O que os usuários poderão fazer o que eles não pode fazer antes? A declaração de visão ajuda a esclarecer o escopo do produto.

Se o produto já existir, escreva uma declaração de visão para esta versão. O que os usuários do produto poderá que eles não pode fazer antes de fazer?

Cenários de gravação

Trabalhar com o cliente e outros participantes para criar cenários e inseri-los como itens de trabalho de requisito com o campo de tipo de requisito definido para o cenário.

Um caso de uso ou de cenário é uma narrativa que descreve uma sequência de eventos, mostra como uma meta específica é obtida e geralmente envolve a interação entre as pessoas ou organizações e computadores.

Forneça um título descritivo que claramente o distingue de outros quando exibidos em uma lista. Certifique-se de que o ator principal ou atores são informados e que seu objetivo é criptografado. Por exemplo, isso seria um bom título:

Cliente comprar uma refeição.

Você pode escrever um cenário nas seguintes formas. Às vezes, ele pode ajudar a usar mais de um formulário:

  • Uma ou duas frases na descrição do item de trabalho:

    Um cliente solicita uma refeição em um site e paga com cartão de crédito. A ordem é passada para um restaurante, que prepara e oferece a refeição.

  • Etapas numeradas na descrição do item de trabalho:

    1. Um cliente visita o site da Web e cria um pedido de uma refeição.

    2. O site da Web redireciona o cliente para um site de pagamento para fazer o pagamento.

    3. A ordem é adicionada à lista de trabalho do restaurante.

    4. O restaurante prepara e entrega a refeição.

  • Storyboard. Um storyboard é essencialmente uma faixa de desenhos que revela a história. Você poderá desenhá-lo no PowerPoint. Anexar o arquivo de storyboard para o item de trabalho de requisito ou carregue o arquivo no portal da equipe e adicionar um hiperlink para o item de trabalho.

    Um storyboard é especialmente útil para mostrar as interações do usuário. Mas para um cenário de negócios, é recomendável usar um esboço estilo que torna limpar que esse não é o design da interface do usuário final.

  • Documentos de requisito. Documentos de requisito lhe dá a liberdade para fornecer o nível apropriado de detalhe para cada requisito. Se você decidir usar documentos, criar um documento do Word para cada requisito e anexar o documento para o item de trabalho de requisito ou carregue o arquivo no portal da equipe e adicionar um hiperlink para o item de trabalho.

  • Diagrama de sequência de linguagem de marcação (UML) unificada. Um diagrama de sequência é especialmente útil quando interagem de várias partes. Por exemplo, a ordenação da refeição requer o cliente, o site do DinnerNow, o sistema de pagamento e o restaurante interagir em uma sequência específica. Desenhar o diagrama de sequência em um modelo UML, verificá-lo em Team Foundation Server, e insira um link no item de trabalho de requisito. Para obter mais informações, consulte Diagramas de sequência UML: diretrizes.

Cenários específicos

Começar escrevendo cenários específicos, que seguem um conjunto específico de atores através de uma seqüência específica. Por exemplo, "Carlos ordena uma pizza e garlic pão no site do DinnerNow. O site da Web redireciona Carlos ao serviço de pagamento do Woodgrove Bank. Fourth Coffee prepara a pizza e entrega.

Cenários específicos ajudarão-lo a imaginar as o sistema em uso e são mais úteis ao explorar um recurso pela primeira vez.

Ele também pode ser útil criar personas nomeados que descrevem os planos de fundo e outras atividades de pessoas e organizações. Carlos dorme áspero e usa um cybercafé; Wendy reside em uma comunidade check; Sanjay ordens de refeições sua esposa em seu trabalho. A Contoso executa uma cadeia de 2.000 restaurantes em todo o mundo; Fourth Coffee é executado por algumas que entregar de bicicleta.

Cenários mais genéricos que são escritos em termos de "um cliente," "um item de menu" e assim por diante podem ser mais convenientes, mas são menos prováveis a descoberta de recursos úteis.

Níveis de detalhe

Na iteração 0, escrever alguns cenários importantes em detalhes, mas a maioria dos cenários de gravação na estrutura de tópicos. Quando se aproximar uma iteração em que um determinado cenário é totalmente ou parcialmente implementadas, adicionar mais detalhes.

Ao considerar um cenário pela primeira vez, pode ser útil descrever o contexto de negócios, aspectos mesmo que nenhuma parte leva o produto. Por exemplo, descrevem o método DinnerNow de entrega: cada restaurante organizar seus próprio entregas ou DinnerNow executa um serviço de entrega? As respostas a essas perguntas fornecem contexto útil para a equipe de desenvolvimento.

Os cenários mais detalhados que você desenvolve no início de uma iteração podem descrever interações de interface do usuário e storyboards podem mostrar o layout da interface do usuário.

Organizando os cenários

Você pode organizar cenários usando os seguintes métodos:

  • Desenhe diagramas de caso de uso que mostram cada cenário como um caso de uso. Esse método é recomendado porque torna os cenários muito fácil de apresentar e discutir. Para obter mais informações, consulte Diagramas de caso de uso UML: diretrizes.

    • Vincule cada caso de uso para o item de trabalho que define o cenário. Para obter mais informações, consulte Vincular elementos de modelo e itens de trabalho.

    • Desenhe relações estende para mostrar que um cenário é uma variação de outro. Por exemplo, "Cliente especifica pagamento separado e endereços de entrega" é a extensão do basic "Cliente faz um pedido" caso de uso. As extensões são particularmente úteis separar cenários em que serão implementados em uma iteração mais recente.

    • Desenhe relações inclui para separar um procedimento como "Cliente fizer logon," que é comum para vários casos de uso.

    • Desenhar os relacionamentos de generalização entre cenários gerais como "Cliente paga" e variantes específicas, como "O cliente paga por cartão."

  • Crie vínculos entre itens de trabalho do cenário de pai-filho. Você pode exibir a hierarquia no Team Explorer. Para obter mais informações, consulte Organizar requisitos em um plano de produto.

Modelo de domínio de empresa

Crie um modelo UML que descreve as principais atividades e os conceitos envolvidos no uso do produto. Use os termos definidos neste modelo como uma "linguagem onipresente", nos cenários, em discussões com os participantes, na interface do usuário e qualquer manuais do usuário e no próprio código.

Muitos requisitos não são explicitamente indicados pelo cliente e compreender os requisitos implícitos depende de uma compreensão do domínio comercial, ou seja, o contexto em que o produto funcionará. Parte do trabalho de coleta em um domínio não familiar de requisitos é, portanto, obter o conhecimento de que o contexto. Depois que esse tipo de dados de conhecimento foi estabelecido, ela pode ser usada em mais de um projeto.

Salve o modelo no controle de versão.

Para obter mais informações, consulte Requisitos de usuário do modelo.

Comportamentos de modelagem

Desenhe diagramas de atividade para resumir os cenários. Use raias para agrupar as ações executadas por diferentes atores. Para obter mais informações, consulte Diagramas de atividade UML: diretrizes.

Embora um cenário normalmente descreve uma seqüência de eventos, um diagrama de atividade mostra todas as possibilidades. Desenho de um diagrama de atividade pode solicitar que você pensar em alternativas sequências e pedir a seus clientes de negócios o que deve acontecer nesses casos.

A ilustração a seguir mostra um exemplo simples de um diagrama de atividade.

Activity with three actions and a loop.

Em que o intercâmbio de mensagens é importante, pode ser mais eficiente usar um diagrama de sequência que inclui uma linha da vida para cada ator e o componente do produto principal.

Diagramas de caso de uso permitem resumir os fluxos diferentes de atividade que oferece suporte ao seu produto. Cada nó no diagrama representa uma série de interações entre os usuários e o aplicativo na meta usuário específico. Também é possível calcular sequências comuns e extensões opcionais em nós de casos de uso separado. Para obter mais informações, consulte Diagramas de caso de uso UML: diretrizes.

A ilustração a seguir mostra um exemplo simples de um diagrama de caso de uso.

Use cases for previous actions

Conceitos de modelagem

Desenhe diagramas de classe de domínio para descrever as entidades importantes e suas relações mencionadas nos cenários. Por exemplo, o modelo DinnerNow mostra restaurante, Menu, Order, Item de Menu e assim por diante. Para obter mais informações, consulte Diagramas de classe UML: diretrizes.

As funções (termina) das relações com cardinalidades e nomes de rótulo.

Em um diagrama de classe de domínio, não normalmente anexar operações para as classes. O modelo de domínio, os diagramas de atividade descrevem o comportamento. Atribuir as responsabilidades às classes de programa faz parte do trabalho de desenvolvimento.

A ilustração a seguir mostra um exemplo simples de um diagrama de classes.

Rule in Comment attached to Order class.

Restrições estáticas

Adicione os diagramas de classe restrições que governam os atributos e relações. Por exemplo, os itens em uma ordem devem todos vêm de restaurante mesmo. Esses tipos de regras são importantes para o design do produto.

Consistência de modelo

Certifique-se de que o modelo e cenários são consistentes. Um dos usos mais poderosos para um modelo é resolver ambiguidades.

  • As descrições de cenários usam os termos que são definidos no modelo e são consistentes com as relações que define. Se o modelo define os itens de menu, os cenários não devem se referir a mesma coisa que produtos. Se o diagrama de classes mostra que um item de menu pertence a exatamente um menu, os cenários não falar de compartilhar um item entre menus.

  • Cada cenário descreve uma série de etapas que são permitidos com os diagramas de atividade.

  • Cenários ou atividades descrevem como cada classe e uma relação no diagrama de classes são criados e destruídos. Por exemplo, o cenário cria um item de menu? Quando um pedido for destruído?

Desenvolver a qualidade dos requisitos de serviço

Crie itens de trabalho que especificam a qualidade dos requisitos de serviço. Defina o campo de tipo de requisito de qualidade de serviço.

Qualidade de serviço ou requisitos não-funcionais incluem o desempenho, usabilidade, confiabilidade, disponibilidade, integridade de dados, segurança, acessibilidade, manutenção e a capacidade de atualização, entrega, facilidade de manutenção, design e ajuste e de término.

Considere a possibilidade de cada uma dessas categorias para cada cenário.

O título de cada qualidade de requisito de serviço deve capturar sua definição apresentando um contexto, uma ação e uma medida. Por exemplo, você pode criar os seguintes requisitos: "Durante uma pesquisa de catálogo, retornar os resultados da pesquisa em menos de três segundos."

Além disso, é útil capturar mais detalhes que explica por que o requisito é necessário. Descreva por que a pessoa teria valor o requisito e por que esse nível de serviço é necessária. Fornece contexto e justificação. Essa explicação pode incluir informações de gerenciamento de risco úteis como dados de uma pesquisa de mercado, um grupo de foco de cliente ou um estudo de usabilidade; relatórios/tíquetes de assistência técnica; ou outra evidência curiosa.

Vincule a qualidade do requisito de serviço para qualquer cenário (item de trabalho de requisito) que é afetado pela qualidade de serviço. Vinculando relacionadas a itens de trabalho permite que os usuários de Team Foundation Server para controlar requisitos dependentes. Consultas e relatórios podem mostrar como a qualidade dos requisitos de serviço afetam os requisitos funcionais são capturados como cenários.

Revisar os requisitos

Quando os requisitos foram escritos ou atualizados, eles devem ser examinados, os participantes apropriados para garantir que eles descrevem adequadamente todas as interações do usuário com o produto. Os participantes comuns podem incluir uma especialista no assunto, um analista de negócios e um arquiteto de experiência do usuário. Os cenários também são examinados para garantir que podem ser implementados no projeto sem qualquer confusão ou os problemas. Se os problemas são identificou, os cenários devem ser corrigidos para que elas sejam válidas ao final dessa atividade.

Crie um item de trabalho de revisão para acompanhar a revisão. Este item fornece provas importantes para um método de avaliação de CMMI padrão para avaliação de aprimoramento de processo (SCAMPI) e pode fornecer uma boa fonte de informações para análise da causa raiz no futuro.

Revise cada cenário para as seguintes características:

  • O cenário é gravado no contexto de quais usuários de tarefas devem executar, o que eles já sabem e como eles esperam que interagem com o produto.

  • O cenário descreve um problema e não é obscurecido por soluções propostas para o problema.

  • Todas as interações de usuário relevantes do produto são identificadas.

  • A especialista no assunto, o analista de negócios e o arquiteto de experiência do usuário revisam cada cenário no contexto do projeto para validar todos os cenários podem ser implementados com êxito. Se um cenário não for válido, ele é revisado para que ele seja válido.

  • O cenário pode ser implementado com recursos, ferramentas e técnicas disponíveis e dentro do orçamento e da agenda.

  • O cenário tem uma única interpretação facilmente compreendido.

  • O cenário não entre em conflito com outro cenário.

  • O cenário é testável.

Validação

Planeje a implantação de versões beta do produto em seu ambiente de trabalho antes de seu lançamento final. Planeje atualizar os requisitos com base nos comentários dos participantes que a implantação.

Validação significa garantir que o produto está de acordo com seu uso pretendido em seu ambiente operacional. No MSF for CMMI, a validação é obtida demonstrando o software de trabalho aos participantes no final de cada iteração durante todo o projeto. A agenda é organizada de forma que preocupações que alimenta novamente para os desenvolvedores de demonstrações iniciais pode ser tratada no plano das iterações restantes.

Para obter validação verdadeira, o produto só não deve ser executado em uma demonstração ou simuladas contexto. Até onde é tão for praticável de acordo, que ele deve ser testado em condições reais.

Inspecionar e editar os requisitos

O cenário e a qualidade dos requisitos de serviço, o que levar a maioria das tarefas de desenvolvimento, podem ser inspecionados usando a consulta de requisitos do cliente. Se você preferir exibir todos os requisitos, você poderá escrever uma consulta que retorna todos os itens de trabalho do tipo de item de trabalho de requisito. Defina as colunas de resultado para mostrar o caminho de iteração.

A equipe deve criar a maioria dos requisitos nas iterações anteriores do projeto. Serão adicionados novos requisitos e outros ajustado conforme comentários é obtido com versões anteriores.

Recursos adicionais

Para obter mais informações, consulte os seguintes recursos da Web: