Compartilhar via

Requisitos de desenvolvimento

  • Artigo

Os requisitos descrevem o que esperam os participantes do produto. Você deve expressar seus requisitos em condições que permitem que são discutidos 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 incluírem não apenas o comportável e a qualidade de expectativa do serviço de usuários mas também de estatutárias e restrições de padrões comerciais.

Criando requisitos em TFS, você ganha os seguintes benefícios:

  • Verifique se os requisitos foram satisfeitos vinculando aos casos de teste.

  • Monitorar o andamento para implementar os requisitos de vinculação para designar os itens de trabalho.

  • Estrutura os requisitos em requisitos gerais e mais detalhados de forma que você possa gerenciá-los mais fácil e de forma que os relatórios de progresso pode resumir informações.

  • Modelar os requisitos em Visual Studio Ultimate, vincular os elementos modelo aos requisitos em Team Foundation Server.

Este tópico não tenta replicar o corpo muito grande de literatura disponível relativas a determinar os requisitos. Em vez disso, enfoca os aspectos que são importantes para usar as ferramentas de Visual Studio de um modo em conformidade 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 restrita. Para desenvolver um modelo de domínio quando você escrever cenários como uma atividade o ajudará a melhorar a outra atividade. Para desenvolver os cenários como o tempo para codificar-los abordagens. Alimente a experiência com o código que foi registrado e demonstrou de volta para os cenários que têm ser implementados ainda.

Ao desenvolver requisitos

TFS suporte ao trabalho iterativo, e essa prática é mais eficiente quando as iterações anteriores são usadas para obter comentários dos usuários potenciais e os outros participantes. Esses comentários podem ser usados para melhorar os requisitos que foram declarados para as iterações futuras. Isso resulta em um produto seja muito mais eficiente na instalação do final de um produto que foi desenvolvido no mesmo período sem nenhuma experimentação do usuário. Se o projeto é um componente entre muitos em um programa maior, a integração do dia com outros componentes permite que os arquitetos de programa melhorem o total product.

Essa flexibilidade deve ser balanceada com a necessidade de executar em paralelo comprometimentos firmes ao cliente ou nos projetos dos parceiros.

Para uma extensão controlada, consequentemente, os requisitos são desenvolvidos e refinados no projeto. Como os requisitos detalhados são prováveis sido alterada durante o projeto, determinar os completamente antes da implementação apropriado é provável que resultar em busca desperdiçado.

  • Na iteração 0, desenvolva um conjunto de requisitos que descrevem os recursos principais, com detalhes suficientes apenas para formar um plano de produto. O plano de produto atribui requisitos para as iterações e indica que requisito será cumprido ao final de cada iteração. Crie um modelo de domínio os conceitos e atividades principais, e defina o vocabulário que será usado para esses conceitos na discussão com os usuários e na implementação do. Determine os requisitos largos que se difundem cada recurso, como a segurança e a outra qualidade dos requisitos de serviço.

  • No ou no início de cada iteração, para desenvolver os requisitos desses recursos com mais detalhes. Determina as etapas que os usuários seguirão, definição de com a ajuda dos diagramas de atividade ou de sequência. Define o que acontece em casos excepcionais.

  • Verifique com a maior frequência possível todos os requisitos que foram implementadas. Os requisitos patentes, como segurança, devem ser verificados com testes que são estendidos para cada novo recurso. Se possível, automatizar o teste porque os testes automática podem ser executados continuamente.

Gerenciando alterações de requisitos

As diretrizes a seguir permitem a operação de um processo de forma incremental com monitorar o com para atender os requisitos CMMI.

  • Não altere os requisitos que são definidos para uma iteração. Em casos raros de uma alteração abrupta nas condições, você pode precisar cancelar uma iteração, examine o plano de 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 antiga renda informações que reduz as incertezas.

  • Use itens de trabalho da solicitação de alteração às solicitações de registro modificar o comportamento que já foi implementado já, a menos que a melhoria solicitada já esteja parte do plano. Vincular cada solicitação de alteração aos itens de trabalho apropriados ao requisito.

  • Revise as solicitações de alteração quando você examina o produto antes de cada iteração. Examine o impacto da solicitação em projetos e dependentes em usuários, e estimativa de custo em relação a alterações em seu código. Se uma solicitação de alteração é aceita, atualize o requisito.

  • Atualizar os testes para refletir a cada alteração dos requisitos.

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

  • Use itens de trabalho de bugs para registrar o comportamento implementado que não é executado de acordo com os requisitos explícitas ou implícitas. Onde possível, crie um novo teste que captura o bugs.

Escreva uma instrução de visão

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

Uma instrução de visão é um resumo sucinto que benefício do produto trará. Que os usuários poderão fazer isso antes não podem fazer? Ajuda da instrução de visão do escopo do produto.

Se o produto já existir, escrever uma instrução de visão para esta versão. Os usuários do produto poderá fazer isso antes não podem fazer?

Cenários de gravação

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

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

Atribua um título descritivo que o distinga claramente de outro quando exibido em uma lista. Certifique-se de que o ator ou atores os principais são indicados e se seu objetivo é apagado. Por exemplo, este seria uma boa título:

O cliente comprar uma refeição.

Você pode escrever um cenário nos seguintes formulários. Às vezes pode ajudar a usar mais de um formulário:

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

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

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

    1. Um cliente visite o site e cria um pedido para uma refeição.

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

    3. A ordem é adicionado à lista de trabalho de um restaurante.

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

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

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

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

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

Cenários específicos

Início gravando os cenários específicos, que seguem um conjunto específico de atores com uma sequência específica. Por exemplo, “Carlos regras um pão de pizza e de alho no site de DinnerNow. O site redireciona Carlos ao serviço de pagamento de banco de Woodgrove. O quarto café prepara a pizza e entrega-a”.

Os cenários específicos ajudam a prever o sistema em uso e são-nos 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 das pessoas e organizações. Carlos dorme a direita e usa um café da Internet); Vidas de Wendy em um condomínio fechado; Refeições pedidos de Sanjay para sua esposa em seu trabalho; Contoso executa uma cadeia de 2.000 restaurantes no mundo inteiro; O quarto café é executado por um par que entrega de bicicleta.

Obter cenários mais genéricas que sejam gravados em termos “de um cliente,” um item de menu”, e assim por diante podem ser mais convenientes mas é menos provável que resultar na descoberta de recursos úteis.

Níveis de detalhes

Na iteração 0, escreva alguns cenários importantes em algum detalhes, mas escreva a maioria dos cenários no esboço. Quando uma iteração aparece na qual um determinado cenário deve para implementar total ou parcialmente, adicione mais detalhes.

Se você considerar primeiro um cenário, pode ser útil descrever o contexto empresarial, mesmo os aspectos em que o produto não toma nenhuma parte. Por exemplo, descreva o método de DinnerNow de entrega: Cada restaurante organizará suas próprias entregas, ou DinnerNow executa um serviço de entrega? As respostas a perguntas como 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 da interface do usuário, e storyboards podem mostrar o layout da interface do usuário.

Organizando os cenários

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

  • Diagramas dos casos de uso de descompasso que mostram cada cenário como um caso de uso. Esse método é recomendado porque torna os cenários muito fáceis a tabela e discutir. Para obter mais informações, consulte Diagramas de caso de uso UML: diretrizes.

    • Vincular 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.

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

    • Um descompasso inclui relações para separar um procedimento como “cliente se conecta,” comuns a vários casos de uso.

    • As relações de generalização de descompasso entre cenários gerais como “cliente” pagam e as consultas específicas como “customer pagam pelo cartão.”

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

Modelagem o domínio comercial

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

Muitos requisitos não for declarado explicitamente pelo cliente, e entender os requisitos implícitos depende de uma compreensão do domínio comercial, isto é, o contexto no qual o produto funcionará. Qualquer de trabalho requisitos que coletam em um domínio é estranho, consequentemente, o ganho de conhecimento a partir desse contexto. Depois que esse tipo de conhecimento foi estabelecido, 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 da modelagem.

Comportamentos de modelagem

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

Embora um cenário descreve geralmente uma sequência de eventos específica, um diagrama de atividade exibe todas as possibilidades. Desenhar um diagrama de atividade você pode ser solicitado a pensar em sequências o backup e a solicitar a seus clientes corporativos o que deve acontecer nos casos.

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

Atividade com três ações e um loop.

Na troca de mensagens é importante, pode ser mais eficiente usar um diagrama de sequência que inclua uma corda de salvamento para cada componente do produto de ator e do principal.

Os diagramas dos casos de uso permitem resumir os fluxos diferentes de atividade que seus backups o produto. Cada nó no diagrama representa uma série das interações entre os usuários e o aplicativo em busca de meta do usuário específico. Você também pode influenciar sequências mais comuns e as extensões opcionais em uso separado e 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.

Casos de uso para ações anteriores

Conceitos de modelagem

Diagramas da classe do domínio de descompasso 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 (pontas) de relacionamento com nomes e cardinalidades.

Em um diagrama da classe de domínio, anexar normalmente operações a classes. No modelo de domínio, os diagramas a seguir descrevem o comportamento de atividade. 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 da classe.

Regra em comentário anexado à classe Order.

Restrições estáticos

Adicionar a diagramas da classe as restrições que governam os atributos e as relações. Por exemplo, todos os itens em uma ordem devem vêm 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 os cenários sejam consistentes. Um os mais avançados 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 o. Se o modelo define itens de menu, os cenários não devem se referir a mesma coisa que produtos. Se o diagrama da classe que mostra um item de menu pertence a exatamente um menu, os cenários não devem compartilhar um item de conversa entre menus.

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

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

Desenvolva a qualidade dos requisitos de serviço

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

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

Considere cada uma dessas categorias para cada cenário.

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

Além disso, é útil capturar mais detalhe que explica por que o requisito é necessário. Descreve como a personalidade avaliaria o requisito e pois esse nível de serviço é necessário. Fornecer contexto e a justificação. Essa explicação pode incluir informações de gerenciamento de riscos útil como dados de uma pesquisa de compras, de um grupo foco do cliente, ou um estudo da usabilidade; relatórios/permissões de suporte técnico; ou outra prova anedótica.

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

Requisitos de revisão

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

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

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

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

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

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

  • O especialista do assunto, o analista empresarial, e a revisão do arquiteto da experiência do usuário cada cenário no contexto de validar projeto que todos os cenários podem ser implementados com êxito. Se um cenário não é válido, está revisado de modo que é válida.

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

  • O cenário tem uma única interpretação que é explicativos.

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

  • O cenário é testavel.

Validação

Plano para implantar versões betas de produtos em seu ambiente de trabalho antes do lançamento final. Planeje atualizar os requisitos, com base em comentários de participantes dessa implantação.

A validação significa garantir que o produto atende a seu uso pretendido no ambiente operacional. Em MSF para CMMI, a validação é obtida para demonstrar o software trabalhando aos participantes no final de cada iteração por meio do projeto. A agenda é organizado de modo que os interesses que são alimentados de volta para os desenvolvedores de demonstrações anteriores podem ser tratados no plano para as iterações restantes.

Para obter a validação for true, o produto não deve ser executado apenas em uma demonstração ou em um contexto imitam. É tão bem quanto possível, deve ser testada em circunstâncias reais.

Inspecionando e editando os requisitos

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

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

Recursos adicionais

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