ALM – Criando um Requisito de Desenvolvimento de Software no TFS
Introdução
No contexto de construção de uma aplicação, requisitos são a expressão do que a aplicação deve fazer e o que é esperado dela em momento de execução. Um requisito pode ser entendido como a descrição do comportamento de um sistema, por exemplo, em uma aplicação de comércio eletrônico teríamos um requisito definido “durante a visita de um usuário ao site, o site deve apresentar uma série de sugestões de produtos em conformidade com comportamento de compra do mesmo”.
Gerenciamento de Requisito
O gerenciamento de requisitos é a prática de documentar e manter a rastreabilidade dos requisitos ao longo do ciclo de vida da aplicação. Dentro do gerenciamento de requisitos temos algumas ações:
- Documentar os requisitos funcionais e não-funcionais;
- Identificar se os requisitos estão aderentes com as necessidades de negócio;
- Priorizar os requisitos;
- Selecionar os requisitos que serão implementados no projeto ou em fase específica;
- Identificar a dependência entre os requisitos;
- Mapear os requisitos com a arquitetura;
- Mapear os requisitos com as funcionalidades da aplicação;
- Verificar se os requisitos foram atendidos e estão em conformidade com as necessidades dos usuários.
O que é um Work Item Requirement no TFS?
Esse Work Item pode ser utilizado para representar as funcionalidades do software. Podem representar um Use Case, um requisito funcional, requisito não funcional, um item do Cenário, etc. Embora o nome do Work Item seja Requirement, este Work Item não é utilizado para representar apenas requisitos.
Segundo MSF CMMI: Representa a descrição do que sua aplicação deveria ou deve fazer para resolver o problema ou necessidade do cliente. (Fonte: http://msdn.microsoft.com/en-us/library/bb668962.aspx)
Criando um Requisito no Team Foundation Server
http://qualidadeeti.files.wordpress.com/2014/12/image_thumb64.png?w=244&h=115
Tipos de Requisitos:
Feature: Será utilizado para agrupar Tasks que implementarão uma nova característica no produto;
Functional: Será utilizado para agrupar Tasks que implementarão uma funcionalidade no produto;
Interface: Será utilizado para agrupar Tasks que implementarão a criação ou alteração de interface;
Operational: Especificação de características relacionadas com o processamento do software, tais como: volume, frequência, disponibilidade, performance, localização física, etc;
Quality of Service: Para uma aplicação, oferecer seus serviços com qualidade significa atender as expectativas do usuário em termos do tempo de resposta e da qualidade, muitas vezes subjetiva, do serviço que esta sendo provido, ou seja, processamento completo de um documento, recebendo uma integração sem interrupção devido a uma falha na comunicação ou erro no arquivo. Fonte: (https://www.rnp.br/noticias/2003/not-031017b-coord.html). Representa uma exigência restritiva como o sistema deve trabalhar. (http://msdn.microsoft.com/en-us/library/bb668962.aspx)
Safety: Segurança. Este tipo é aplicável como um requisito não-funcional à ações feitas para evitar perdas de dados em caso de algum acidente;
Scenario: Representa uma simples interação com o usuário através do software. Pode representar um Use Case;
Security: Representa a segurança do software, como controle de acesso via senhas, permissões de usuários, acesso restrito a módulos avançados do software, etc.
Associações no Requisito:
Um requisito deve agrupar:
- Tarefas de Desenvolvimento (que irão refletir em tempo, o custo de um requisito)
- Tarefas de Testes (que irão refletir em tempo, o custo de um requisito)
- Casos de Testes (que irão refletir em qualidade um requisito)
Vá em My Work –> Available Work Items –> New –> Requirement
http://qualidadeeti.files.wordpress.com/2014/12/image_thumb65.png?w=236&h=244
Para escrever o título do Requisito, você poderá usar diversas formas e técnicas, conforme sua abordagem de desenvolvimento, um exemplo seria:
http://qualidadeeti.files.wordpress.com/2014/12/image_thumb66.png?w=244&h=146
Caso tenha dúvidas, acesse os links abaixo:
http://msdn.microsoft.com/en-us/library/bb668962.aspx
http://msdn.microsoft.com/en-us/library/dd997574.aspx
Guia de Gerenciamento de Requisitos ALM Rangers
Defina o título, tipo do requisito, descrição, telas de protótipo, triagem, e os demais campos conforme sua necessidade.
http://qualidadeeti.files.wordpress.com/2014/12/image_thumb67.png?w=244&h=78
Esse requisito deverá conter:
- Tarefas de Desenvolvimento e Testes, inclusive com os tempos estimados com Child.
http://qualidadeeti.files.wordpress.com/2014/12/image_thumb68.png?w=244&h=33
http://qualidadeeti.files.wordpress.com/2014/12/image_thumb69.png?w=244&h=49
- Test Case como Tested By, para o vinculo dos BUGS em aberto.
http://qualidadeeti.files.wordpress.com/2014/12/image_thumb70.png?w=244&h=55
Depois, quando as tarefas estiverem sendo executadas e os tempos alterados, você poderá acompanhar nos relatórios de requisitos. Veja um exemplo abaixo:
http://qualidadeeti.files.wordpress.com/2014/12/image_thumb71.png?w=244&h=229
http://qualidadeeti.files.wordpress.com/2014/12/image_thumb72.png?w=244&h=103
