Requisitos desenvolvimento

Os requisitos descrevem o que os participantes esperam do produto.Você deve expressar seus requisitos em termos que permitem que são abordados facilmente com os participantes comerciais, usando o vocabulário e os conceitos de domínio comercial.Os requisitos devem ou discutir ou depender de implementação.Os requisitos incluem não apenas o comportamental e a qualidade de expectativas de serviço de usuários mas também de restrições estatutárias e padrões de negócios.

Gravando requisitos em Visual Studio Team Foundation Server usando os requisitos do item, você ganham os seguintes benefícios:

• Verifique se os requisitos foram (os vinculando-o para situações de teste.

• Monitorar o progresso para implementar os requisitos para encarregar vinculando os itens de trabalho.

• Estrutura os requisitos nos requisitos gerais e mais detalhados de modo que você possa gerenciar os mais facilmente e para que os relatórios de progresso possam resumir informações.

• A modelagem os requisitos em Visual Studio Ultimate, aos elementos modelo aos requisitos em Team Foundation Server.

Este tópico não tenta replicar o corpo muito grande de literatura que está disponível para determinar quanto dos requisitos do.Em vez de isso, enfoca os aspectos que são importantes para usar as ferramentas de Visual Studio de forma que está de acordo com a CMMI. Para obter mais informações sobre o CMMI, consulte Plano de fundo a CMMI.

As atividades que são descritas em este tópico, como todas as atividades de desenvolvimento, não devem ser executadas na ordem estrita.Desenvolva um modelo de domínio quando você escrever cenários como uma atividade o ajudarão a melhorar a outra atividade.Desenvolva ambos os cenários como o tempo para codificar-los abordagens.Alimente a experiência com código que foi escrita e demonstrou de volta para os cenários que têm ainda ser implementados.

Neste tópico

Quando desenvolver requisitos

Escreva uma declaração da visão

Escreva cenários

A modelagem o domínio de negócios

Desenvolva a qualidade de requisitos de serviço

Revise os requisitos

Validação

Inspecionando e editando os requisitos

Quando desenvolver requisitos

Team Foundation Server suporta trabalhar iterativo, e essa é a prática mais eficiente quando as iterações adiantadas são usadas para ganhar comentários de usuários em potencial e outros participantes. Esses comentários podem ser usados para melhorar os requisitos que foram indicados para as iterações futuras.Isso resulta em um produto que é muito mais eficiente em sua instalação final do que um produto que é desenvolvido durante o período mesmo sem nenhuma experimentação do usuário.Se seu projeto é um componente entre muitas em um programa maior, a integração inicial com outros componentes permite que os arquitetos do programa melhorem o produto total.

Essa flexibilidade deve ser fechamento contra a necessidade de dar paralelamente compromissos firmes ao seu cliente ou a projetos de parceiros.

Para uma extensão controlada, portanto, os requisitos são desenvolvidos e refinados em todo o projeto.Porque os requisitos detalhados são prováveis mudar durante o projeto, determinando os completamente antes da implementação apropriada é provável levar a esforço desperdiçado.

• Em a iteração 0, desenvolva um conjunto de requisitos que descrevem os recursos principais, com apenas o suficiente para formar um plano detalhes do produto.O plano atribui às necessidades de produtos iterações e indica o requisito será atingido o final da cada iteração.Crie um modelo de domínio conceitos e as atividades chave, e defina o vocabulário que será usado para esses conceitos na discussão com os usuários e na implementação.Determinar os requisitos de largura que se difundem cada recurso, como a segurança e a outra qualidade de requisitos de serviço.

• Em ou próximo de início de cada iteração, desenvolva os requisitos para esses recursos com mais detalhes.Determine as etapas que os usuários seguirão, definindo as com a ajuda de diagramas de atividade de seqüência ou.Define o que acontece em casos excepcionais.

• Verificar muitas vezes quanto possível todos os requisitos que foram implementados.Os requisitos patentes, como a segurança, devem ser marcados com testes que são estendidos para cada novo recurso.Se possível, automatiza os testes porque os testes automáticos podem ser executados continuamente.

Gerenciando alterações dos requisitos

As seguintes diretrizes permitem que você operar um processo incremental para o mais monitorá-lo para satisfazer os requisitos CMMI.

• Não altere os requisitos que são definidos para uma iteração.Em os exemplos raros de uma alteração abrupta em circunstâncias, você pode ter que cancelar uma iteração, revise o plano do produto, e iniciar uma nova iteração.

• Procure incertezas nos requisitos.Tente organizar o plano de modo que a experiência do usuário com iterações adiantadas gere informações que reduz as incertezas.

• Use itens de trabalho de solicitação de alteração às solicitações de registro alterar o comportamento que já tenha sido implementado, a menos que a melhoria solicitada já está parte do plano.Vincular cada solicitação de alteração apropriadas para itens de trabalho do requisito.Para obter mais informações, consulte Solicitação de alterações (CMMI).

• Examine solicitações de alteração quando você examinar o produto antes de cada iteração.Examine o impacto de solicitação em projetos dependentes e usuários em, e estimar o custo em relação às alterações em seu código.Se uma solicitação de alteração é aceita, atualizar o requisito.

• Atualizar os testes para estar de acordo com a cada alteração dos requisitos do.

• Designe uma data de interrupção (por exemplo, após a iteração 2 ou 3) após o qual as alterações dos requisitos muito mais devem ser fortemente justificadas.Se seu projeto é para um cliente pagando, esta é a data para que o cliente aprovar uma linha de base dos requisitos definida e a opção de pagamento de hora na hora preço fixo.

• Os itens de trabalho de bug de uso para registrar implementa o comportamento que não é executado de acordo com os requisitos explícito ou implícito.Onde for prático, crie um novo teste que captura o erro.

Escreva uma declaração da visão

Discutir uma declaração da visão com a equipe, e exibi-la no portal de projeto da web para Team Foundation Server.

Uma declaração da visão está um resumo sucinto que vantagem do produto trará.Que os usuários poderão fazer que não podem fazer antes?Ajuda da declaração da visão do escopo do produto.

Se o produto já existir, escreva uma declaração da visão para esta versão.Os usuários do produto poderão fazer que não podem fazer antes?

Escreva cenários

O trabalho com seu cliente e outros participantes para criar cenários, e para incorporá-los como itens de trabalho do requisito, com o campo do tipo do requisito define ao cenário.

Os exemplos do cenário ou usar são uma narrativa que descreve uma seqüência de eventos, mostra como um objetivo específico é obtido, e quebra geralmente a interação entre pessoas ou organizações e computadores.

Dê-lhe um título descritivo que o distingue claramente de outro quando exibido em uma lista.Certifique-se de que o ator ou atores os principais são indicados e que seu objetivo é claro.Por exemplo, isso deve ser um bom título:

o cliente compra uma refeição.

Você pode escrever um cenário nos formulários.A as vezes pode ajudar a usar mais de um formulário:

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

  Um cliente de uma refeição em um site e paga-a com um cartão de crédito.A ordem é passado para um restaurante, que prepare e entregue a refeição.

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

  Um cliente visita o site e cria uma ordem para uma refeição. O site redireciona o cliente a um site de pagamento para fazer o pagamento. A ordem é adicionado à lista de trabalho de restaurante. O restaurante prepara e entregar a refeição.

• Storyboard.Um storyboard é essencialmente uma faixa de desenhos animados que indica a essa história.Você pode certifique-se no Powerpoint.Anexar o arquivo do storyboard ao item de trabalho do requisito, ou carregar o arquivo ao portal de equipe, e adicionar um hiperlink a um item de trabalho.

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

• Documentos do requisito.Documentos de requisito oferecem a liberdade para fornecer um nível apropriado de detalhes para cada requisito.Se você decidir usar documentos, criar um documento do word para cada requisito, e anexar o documento ao item de trabalho do requisito, ou carrega o arquivo para o portal da equipe e adicionar um hiperlink a um item de trabalho.

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

Cenários específicos

Escrevendo início os cenários específicos, que seguem um determinado conjunto de atores com uma seqüência específica.Por exemplo, “Carlos de um pão de pizza e de alho no site de DinnerNow.O site redirecione Carlos para o serviço de pagamento de banco de Woodgrove.O quarto coffee preparar a pizza e entrega-a”.

Determinados cenários ajudam a fornecer o sistema em uso e são os mais úteis quando você explora primeiro um recurso.

Também pode ser útil criar os personas nomeados que descrevem os planos de fundo e outras atividades de pessoas e as organizações.Carlos dorme áspero e usa um lanchonete da Internet (IIS); vidas de Wendy em um condomínio fechado; Refeições pedidos de Sanjay para sua esposa em seu trabalho; Contoso executa uma cadeia de restaurantes 2.000 em todo o mundo; O quarto coffee é executado por um controle de entrega por bicicleta.

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

Níveis de detalhe

Em a iteração 0, escrever alguns cenários importantes em alguns detalhes, mas escreva a maioria das situações na estrutura.Quando uma iteração se aproxima em que um cenário específico deve para implementar totalmente ou no, adicione mais detalhes.

Quando você primeiro considera um cenário, pode ser útil descrever o contexto de negócios, mesmo os aspectos em que o produto não executa nenhuma parte.Por exemplo, descreve o método de DinnerNow de entrega: cada restaurante organiza suas próprias entregas, ou DinnerNow dirige um serviço de entrega?As respostas a como perguntas fornecem o 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 de usuário, e storyboards possam mostrar o layout da interface do usuário.

Organizando os cenários

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

• Diagramas dos casos do uso de desenho que mostram como cada cenário os exemplos de uso.Este método é recomendado porque torna os cenários muito fácil apresentar e discutir.Para obter mais informações, consulte Diagramas de caso de uso UML: diretrizes.

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

  • Para desenhar estende relacionamentos para mostrar que um cenário é uma variação de outro.Por exemplo, “cliente especifica o pagamento separado e endereços de entrega” é uma extensão “básicos de cliente são exemplos de uso de um pedido”.As extensões são particularmente úteis para fora separar os cenários que serão implementados em uma iteração posterior.

  • Para desenhar inclui relacionamentos para separar um procedimento como “inserir” cliente, que é comum a vários casos de uso.

  • As relações de generalização de desenho entre cenários gerais como “cliente pagam” e variantes específicas como “cliente pagam por carta.”

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

A modelagem o domínio de negócios

Crie um modelo de UML que descreve as atividades e conceitos chave que estão envolvidos no uso do produto.Use os termos que são definidos em esse modelo como um idioma ubíquo “,” em cenários, em discussões com os participantes, na interface do usuário e todos os manual de usuário, e no próprio código.

Muitos requisitos não são indicados explicitamente pelo cliente, e entender os requisitos implicados depende de uma compreensão de domínio comercial, ou seja, o contexto no qual o produto funcionará.Alguns trabalhos de requisitos que coletam em um domínio é irrelevante, portanto, sobre o ganho de conhecimento do contexto.Após esse tipo de conhecimento foi estabelecido, pode ser usado em mais de um projeto.

Salve o modelo em controle de versão.

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

Modelando comportamentos

Diagramas de atividade de desenho para resumir cenários.Use swimlanes para agrupar ações que são executadas por atores diferentes.Para obter mais informações, consulte Diagramas de atividade UML: diretrizes.

Embora um cenário descreve geralmente uma seqüência de eventos específica, um diagrama de atividade mostra todas as possibilidades.Desenhar um diagrama de atividade solicita que você pode pensar sobre a seqüencia alternativas e pedir a seus clientes de negócios o que acontece em casos.

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

Onde o troca de mensagens é importante, pode ser mais eficiente usar um diagrama de seqüência que inclui uma corda de salvamento para cada componente do e ator de versão principal.

Os diagramas dos casos de uso permitem que você resumir fluxos diferentes de atividade que seus apoios ao produto.Cada nó no diagrama representa uma série de interações entre os usuários e o aplicativo em busca de um objetivo de usuário específico.Você também pode incluir seqüências comuns e extensões opcionais em uso separado encaixotam nós.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 dos casos de uso.

Modelando conceitos

Diagramas de classe do domínio de desenho para descrever as entidades importantes e suas relações que são mencionadas em cenários.Por exemplo, o modelo de DinnerNow mostra o menu, restaurante, ordem, item de menu, e assim por diante.Para obter mais informações, consulte Diagramas de classe UML: diretrizes.

Rotular as funções termina () relacionamentos com nomes e cardinalidades.

Em um diagrama de classe de domínio, você normalmente não anexa operações para classes.Em o modelo de domínio, os diagramas de atividade descrevem comportamento.As responsabilidades de atribuição programar classes fazem parte do trabalho de desenvolvimento.

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

Restrições estáticos

Adicionando a diagramas de classe restrições que controla os atributos e relacionamentos.Por exemplo, todos os itens em uma ordem devem vir do mesmo restaurante.Esses tipos de regras são importantes para o design do produto.

Consistência modelo

Certifique-se de que o modelo e cenários sejam consistentes.Um dos usos mais eficiente para um modelo é resolver ambigüidades.

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

• Cada cenário descreve uma série de etapas que são permitidas por diagramas de atividade.

• Os cenários ou as atividades descrevem como cada classe e relacionamento no diagrama de classe são criadas e destruídas.Por exemplo, cenário que cria um item de menu?Quando um pedido é destruído?

Desenvolva a qualidade de requisitos de serviço

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

A qualidade de serviço ou os requisitos e não incluem o desempenho, a usabilidade, confiabilidade, a disponibilidade, a integridade de dados, segurança, a disponibilidade, a utilidade e o upgradeability, o deliverability, sustentabilidade, o design, e o ajuste e o suporte.

Considere cada uma de essas categorias para cada cenário.

Cada título de qualidade do requisito do serviço deve captar sua definição apresentando um contexto, uma ação, e uma medida.Por exemplo, você pode criar o requisito seguir: “Durante uma pesquisa de catálogo, retornar os resultados da pesquisa em menos de três segundos.”

Além de isso, é útil capturar mais detalhes explicando como o requisito é necessário.Descreve como personalidade avaliaria o requisito e porque esse nível de serviço é necessário.Fornecer contexto e justificação.Esta explicação pode incluir informações de gerenciamento dos riscos útil como dados de uma pesquisa do mercado, de um grupo foco de cliente, ou um estudo de usabilidade; relatórios/permissões de suporte técnico; ou outra sem anedótica.

Vincular a qualidade do requisito de serviço a qualquer cenário (item de trabalho do requisito) que é afetado pela qualidade de serviço.Vincule itens de trabalho relacionados permite que os usuários de Team Foundation Server mantenham-se a par de requisitos dependentes.Consulta e os relatórios poderão mostrar como a qualidade de requisitos de serviço afeta os requisitos funcionais que são capturados como cenários.

Revise os requisitos

Quando os requisitos foram atualizados, ou gravados devem ser examinados por participantes apropriadas para garantir que descrevam adequadamente todas as interações do usuário com o produto.Os participantes comuns podem incluir um especialista de assunto, um analista comercial, e um arquiteto da experiência do usuário.Os cenários são examinados também para garantir que eles sejam implementados no projeto sem confusão ou problemas.Se algum problema é observado, os cenários devem ser corrigidos de modo que são válidos no final da atividade.

Crie um item de trabalho para acompanhar revisão da revisão.Este item fornece a evidência importante para um método padrão de avaliação CMMI para avaliação de melhoria de processo (LAGOSTIM) e pode fornecer uma boa origem de informações para análise de raiz causa no futuro.

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

• O cenário é escrito no contexto do que os usuários devem executar a tarefa, o que já conhecem, e como esperam interagir com o produto.

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

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

• O especialista de assunto, o analista comercial, e a revisão de arquiteto da experiência do usuário cada cenário no contexto de projeto validar que todos os cenários podem ser implementadas com êxito.Se um cenário é inválido, é revisado para que ele seja válido.

• O cenário pode ser implementado com as técnicas, as ferramentas, e os recursos disponíveis e dentro de orçamento e de cronograma.

• O cenário tem uma interpretação somente que é fácil de compreensão.

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

• o cenário é testavel.

Validação

Plano para implantar versões beta de produto em seu ambiente de trabalho antes do lançamento final.Plano para atualizar os requisitos, com base nos comentários de participante da implantação.

A validação significa garantir que o produto atende a seu uso pretendido em seu ambiente operacional.Em o MSF para CMMI, a validação é obtida demonstrando o software trabalhando para os participantes no final da cada iteração em todo o projeto.A agenta é organizada de tal forma que os interesses que são alimentados de volta para os desenvolvedores de demonstrações adiantadas podem ser tratados no plano para as iterações restantes.

Para obter a validação verdadeira, o produto não só deve ser executado em uma demonstração ou em um contexto simulado.É tão distante quanto possível, deve ser testado em condições reais.

Inspecionando e editando os requisitos

O cenário e a qualidade dos requisitos de serviço, que resultam na maioria das tarefas de desenvolvimento, podem ser inspecionados usando a consulta dos requisitos do cliente.Se você preferir exibir todos os requisitos, você pode escrever uma consulta que retorna todos os itens de trabalho do tipo de item de trabalho do requisito.Defina as colunas de resultado para exibir o caminho de iteração.Para obter mais informações, consulte Consultas compartilhadas (CMMI).

Além de exibir a consulta diretamente em Team Explorer ou em Team Web Access, você pode abri-lo em Office Excel ou em Office Project.Essas ferramentas são mais conveniente para editar e adicionar itens de trabalho como um lote.Para obter mais informações, consulte Trabalhando no Microsoft Excel e Microsoft Project conectado ao de Team Foundation Server e Executar o planejamento de cima para baixo usando uma lista de árvore de itens de trabalho (no Excel).

Sua equipe deve criar a maioria dos requisitos de iterações adiantadas do projeto.Os novos requisitos serão adicionados e outros comentários são definidos como ganhados de versões adiantadas.

Recursos adicionais

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

• Um guia prático para caracterizar o desenvolvimento orientadoR, Stephen.Palmer e Malcolm J.Felsing; PTR de Prentice-Salão, 2002.

• A modelagem aerodinâmico de objeto: Padrão, as regras e implementaçãoJill, Nicola, marca Mayfield, e Mike Abney; PTR de Salão de Prentice, 2001.

• A modelagem agile: Práticas eficazes para programação unificado extrema e o processo, Scott Ambler; Wiley, 2002.

• Design dados-driven domínio: Abordando a complexidade de software no coraçãoEric Evans;, profissional de Addison-Wesley, 2003.

• Design de objeto: funções, responsabilidades e colaborações, Rebecca Wirfs-Brock e Alan McKean; profissional de Addison-Wesley, 2002.