Especificação de Requisito de Desenvolvimento de Sistemas Modelo CMMI Visual Studio 2010

Especificação de Requisito de Desenvolvimento de Sistemas Modelo CMMI Visual Studio 2010

A DANRESA Consultoria de Informática utiliza em seus projetos de desenvolvimento de sistemas e fábrica de software diversos tipos de modelos de especificação de requisito de desenvolvimento de sistemas, incluindo especificação funcional, especificação técnica, especificação de regras de negócios, incluindo o detalhamento dos requisitos funcionais e não funcionais.

Ferramentas de gestão de projetos e gestão de softwares auxiliam na organização dos documentos de especificação de requisitos, permitindo a visão de todos os artefatos envolvidos, colaboração da informação entre a equipe de projeto, clientes e parceitos de negócios.

Utilizar um bom modelo de documento de especificação de requisitos, especificação funcional e especificação técnica juntamento com ferramentas que se propõe a organizá-los aumenta ainda mais o potencial de sucesso em projetos de desenvolvimento de sistemas e fábrica de software bem como na satisfação do cliente final e na entrega de um produto de qualidade.

A proposta da Microsoft com a ferramenta Visual Studio 2010 aliada a modelos de documentos aderentes ao trabalho da equipe de desenvolvimento de sistemas e fábrica de software ajudam neste processo.

Os documentos de especificação de requisitos, sejam documentos de especificação funcional, especificação técnica ou especificação de regras de negócios podem ser armazenados em work items do tipo Requisito ( Requirement ), versionados no repositório do team foundation server e compartilhados e colaborados por toda a equipe de projeto, clientes e parceiros de negócios dentro e fora da empresa de forma segura.

Veja abaixo como usar a work item do tipo Requirement ( Requisito ) do template CMMI para organizar suas especificações de requisito de sistemas.

Um requisito aborda funcionalidades e é de grande valor para o cliente do produto ou sistema. Cada requisito deve indicar brevemente o que o usuário quer fazer com uma funcionalidade do software e descreve-o a partir da perspectiva do usuário. Para mais informações, consulte Planejamento do Projeto (CMMI).

Para exibir um requisito você deve ser um membro do grupo de leitores ou ter permissão para exibir requisitos. Para criar ou modificar um requisito, você deve ser um membro do grupo de Colaboradores ou ter permissão de edição de requisitos.  Para mais informações, consulte Gerenciando permissões.

Definido um requisito de sistema

Para definir um requisito deve-se ter em mente quais são as funcionalidades solicitadas pelos usuários do sistema, para que elas servem, qual o objetivo das funcionalidades, para quem são e o porquê delas serem implementadas.

Deve-se evitar especificar como o recurso será desenvolvido.
Quando cria-se um requisito, é necessário especificar apenas o título. No entanto, você pode definir uma variedade de outros tipos de informação, como as ilustrações a seguir mostram:

Como definir um requisito de sistema

 

Quando você define um requisito, é necessário definir o título. Você pode deixar todos os campos em branco ou aceitar outro seus valores padrão.

Para definir um requisito
Na parte superior do formulário de item de trabalho, especificar um ou mais dos seguintes tipos de informação:
1. No título (obrigatório), digite uma descrição curta.
2.Um bom título de requisito deve ser uma informação clara e objetiva a ser entendida pelo cliente ou a equipe que deve implementar a funcionalidade.
3. Em tipo de requisito, clique no tipo de exigência que você está definindo.
3.1. O valor padrão é de recursos.
4. Na lista de responsáveis, clique no nome do membro da equipe responsável pelo requisito.

Você pode atribuir itens de trabalho apenas para os membros do grupo de Contribuintes.

Se você deixar o campo em branco, ao salvar ele será atribuído para você.

5. Na lista de Estado, deixe o valor padrão, proposto. Na lista Razão, deixe o valor padrão, Nova

6. Nas listas de área e iteração, clique na área apropriada e iteração.

7. Na lista de prioridade, clique no nível de importância para o requisito em uma escala de 1 (mais importante) a 4 (menos importante).

8. Na lista de triagem selecione um valor adequado para o requisito

Este campo identifica um nível de triagem para requisitos que estão no estado proposto.

9. Na lista de bloqueados, clique em Sim se um problema está bloqueando o progresso em direção à implementação do requisito.

10. Na lista de implementação marque Sim apenas quando o requisito for implementado

11. Na guia de Detalhes descreva detalhadamente todos os requisitos para a validação do requisito pelo cliente e pela equipe de trabalho. Descreva o cenário, todo o levantamento com o cliente, os recursos, funcionalidades, tarefas, fluxo principal, fluxo alternativo, fluxo de exceção, cenários de testes e validações.

Deve-se fornecer o máximo de detalhes necessários para assegurar que um desenvolvedor possa implementar as exigências da especificação funcional e que um testador possa realizar os testes necessários para validar as solicitações do requisito.

A equipe de trabalho irá utilizar esta informação para criar itens de trabalho para tarefas e casos de teste.

12. Na guia Análise, descreva para o cliente quais os impactos caso o requisito não seja implementado.
13, Na guia Outros, especificar os seguintes tipos de informação:

13.1 Sob especialistas no assunto, clique nos nomes de até três membros da equipe que estão familiarizados com a área do problema e as expectativas dos clientes para o requisito.

13.2 Na caixa de estimativa original, digite a quantidade de hora de trabalho para a execução das atividades relacionadas ao requisito

Em geral, você aponta estes dois campos no final do ciclo de desenvolvimento e não quando define requisito.

13.3 Na lista de integrado, clique no nome ou número da compilação em que a equipe de desenvolvimento integrou o requisito.

13.4 Na lista de teste, clique no status do teste de aceitação do usuário para este requisito.

Os valores permitidos são de: aprovação, reprovação, não está pronto, pronto, ou ignoradas. Você deve especificar “não está pronto” quando a exigência é estiver no estado ativo e pronto quando a exigência estiver no estado Resolvido.

14. Para as Guias Implementação, Solicitações de Mudança, Casos de T, e todas as guias Links, você pode criar links a partir da requisitos de outros itens de trabalho, tais como tarefas, solicitações de mudança, casos de teste, erros e problemas.

15 Na guia Anexos, você pode anexar as especificações, imagens ou outros arquivos que fornecem mais detalhes sobre o requisito.

Após preencher todos os dados necessários para a colaboração da especificação de requisitos no formulário de work item do tipo Requisito, Salve o formulário e anexe um modelo de documento de especificação de requisito com todo o detalhamento do requisito.

Abaixo segue um modelo de capa e índice de especificação de requisitos, especificação funcional que utilizamos na Fábrica de Software da DANRESA

Na especifiação funcionao utilizada pela DANRESA Consultoria de Informática devem constar obrigatoriemante os tópicos abaixo

Introdução

Este documento tem como objetivo fornecer aos desenvolvedores as informações necessárias para o projeto e implementação, assim como para a realização dos testes e homologação da aplicação xxxxx

1.1.     Convenções, termos e abreviações

A correta interpretação deste documento exige o conhecimento de algumas convenções, termos específicos e abreviações, que são descritos a seguir.

 

2. Atores

A tabela abaixo descreve brevemente cada ator da aplicação.

<Cada ator representa um papel particular de usuário da aplicação. Porém, além de representar pessoas, os atores também podem ser dispositivos de hardware ou até outras aplicações que devam trocar informações com a aplicação a ser desenvolvida.>

 

Ator Descrição
<Indique o nome do ator> <Apresente uma breve descrição do   ator. Se o ator for uma generalização de um conjunto de atores, isso deve ser   indicado.>

 

 

3. Requisitos Funcionais

Essa seção apresenta todos os requisitos funcionais da aplicação, especificados como casos de uso.

 

Prioridade: Essencial Importante Desejável
Ator(es): <Informe os atores que irão interagir com este caso de uso.>

<Para preencher a prioridade do caso de uso, dê dois cliques no quadrado ao lado da prioridade desejada e, no diálogo que surgir, selecione a opção Checked.>

 

Descrição: <Forneça uma pequena explicação do propósito do caso de uso (útil quando o nome do caso de uso não deixa suficientemente claro qual é o seu objetivo).>

 

Pré-condições: <Liste cada pré-condição deste caso de uso (estado em que a aplicação deve estar ou um fator externo necessário para que o caso de uso possa ser realizado).>

 

Pós-condições: <Liste todas as pós-condições deste caso de uso (lista de possíveis estados em que a aplicação pode ficar imediatamente após o término da execução do caso de uso, ou alteração de um fator externo à aplicação).>

 

Tarefas para o desenvolvedor

<Descreva, passo a passo de forma simplificada tarefas que serão executadas pelos desenvolvedores>

 

Fluxo principal

<Descreva, passo a passo, o que os atores e a aplicação fazem neste caso de uso. Também deverão ser descritas as regras de negócio específicas para este caso de uso, quando houver. Quando este caso de uso incluir um outro, utilize a palavra Incluir. Para estender, deve-se utilizar a palavra Estender. Um determinado passo, pode, em determinada condição, fazer referência a um fluxo alternativo ou de erro.>

 

<Opcionalmente, podem ser apresentados esboços das telas da aplicação que forem necessários ou convenientes para o esclarecimento do caso de uso. Para aplicações que possuem protótipos já em desenvolvimento, uma opção interessante é capturar telas desse protótipo. O detalhamento completo da interface, entretanto, deverá ser apresentado apenas em um outro documento (Look and Feel da Interface com o Usuário), em um momento posterior.

Se você utilizar esboços de telas, use legendas (com nomes e/ou números) para identificar cada tela. Ao descrever os fluxos de eventos dos casos de uso, esses identificadores de telas podem ser referenciados.>

 

Fluxos alternativos

[FA 001]

<Descreva cada fluxo alternativo possível para este caso de uso, detalhando os passos a serem seguidos. Um fluxo alternativo modela uma seqüência que foge ao fluxo principal, descrito mais acima, mas que não é um erro.>

 

Fluxos de erro

[FE 001]

<Descreva os passos a serem seguidos para cada situação de erro identificada para este caso de uso. Erros podem envolver falha na comunicação via rede, entrada de dados inválidos, etc.>

 

 

4. Requisitos Não Funcionais

 

Nesta seção, estão especificados os requisitos não-funcionais da aplicação.

<Alguns exemplos de categorias de RNFs seguem abaixo:

  • Usabilidade:  RNFs associados à facilidade de uso da aplicação;
  • Confiabilidade: RNFs associados à freqüência e severidade de falhas da aplicação e habilidade de recuperação das mesmas;
  • Desempenho: RNFs associados à eficiência, uso de recursos e tempo de resposta da aplicação;
  • Segurança: RNFs associados à integridade, privacidade e autenticidade dos dados da aplicação;
  • Implantação: RNFs associados ao modo como será implantada a solução;
  • Padrões: RNFs associados a padrões ou normas que devem ser seguidos pela aplicação ou pelo seu processo de desenvolvimento;
  • Hardware e Software: RNFs associados a restrições de hardware e software usados para desenvolver ou executar a aplicação;

Cada RNF deve ser especificado em uma subseção própria, como indicado abaixo. Descreva o RNF, assinale sua prioridade e, em seguida, se o RNF estiver relacionado a um caso de uso ou a um grupo de casos de uso específico, indique isso através do campo “Casos de uso associados”. Se o RNF em descrição diz respeito à aplicação como um todo, esse campo não deverá ser utilizado.>

[NF01] <Incluir ao lado do identificador um nome para o RNF>

<Descrição do RNF>

 

Prioridade: Essencial Importante Desejável
Casos de uso associados: <Usar   este campo para identificar a que caso(s) de uso esse requisito não-funcional   está relacionado.>

<Para preencher a prioridade do RNF, dê dois cliques no quadrado ao lado da prioridade desejada e, no diálogo que surgir, selecione a opção Checked.>

 

5. Referências

Nesta seção, são apresentadas as referências utilizadas para a elaboração deste documento.

 

<Basicamente, as referências do Documento de Especificação Funcional mostram a fonte dos requisitos (casos de uso e RNFs), urls de aplicações já existentes relacionadas, etc. Uma sugestão para apresentação das referências segue abaixo:>

<Título; Número (se aplicável); Data; Instituição, divisão ou equipe responsável pelo documento; Link para o documento (se aplicável);>

 

6. Anexos

<Nesta seção, devem ser listados ou adicionados os anexos, links que complementam o documento.>

 

7. Comentários

<Nesta seção, devem ser apresentadas as solicitações de revisão, comentários e complementos que serão analisados para alterações no documento.>

Após preencher o documento de especificação funcional anexar o arquivo na work item do tipo requirement ( requisito ) gerada para o documento em questão.

 

Sobre a DANRESA – Com mais de 14 anos de experiência no mercado de TI, a DANRESA é uma Consultoria de Informática com atuação em todo o território nacional, focada em duas linhas de serviços principais e complementares: Fábrica de SoftwareDesenvolvimento de Sistemas, Infraestrutura e Outsourcing de TI. A área de Desenvolvimento é voltada a Projetos de Negócios por meio de Sistemas Personalizados de TI de acordo com a especificidade de cada cliente, realizando levantamento dos processos, análise e programação através de sua fábrica de software ou com profissionais alocados no cliente. Já a área de Infraestrutura inclui serviços como Outsourcing de TI, Gerenciamento e Monitoramento de equipamentos de missão crítica como Servidores, Roteadores, Switches e Links de conectividade, Instalação e Manutenção de pontos de rede, voz e dados, Suporte Técnico por meio de Service Desk – em que os atendimentos são feitos por uma equipe especializada e certificada nas práticas do ITIL – entre outros. Com cerca de 400 colaboradores e 100 clientes, a DANRESA possui em sua carteira empresas como ANFAVEA, BASF (Suvinil), Ernst Young, Sem Parar, Schneider, CBC, Eurobras, Avape, Alves Feitosa Advogados, Instituto Airton Senna, Grupo Kaduna, CVC, WoodBrook, Salles Leite (Iguaçu Energia ), etc. Para mais informações, ligue: (11) 4452-6450