Análise de Requisitos de Software

Quando um produto de software tem de ser desenvolvido, uma das primeiras tarefas no livro do Gerente de Projeto cronograma é a Análise de Requisitos.

O que é a Análise de Requisitos?

Simplificando, os requisitos do processo de Análise tem como objetivo identificar e documentar os requisitos do cliente para um sistema proposto.
Um praticante de software treinado chamado de Analista de Requisitos (RA) se comunica com o usuário experiente (s) para entender o que são os requisitos. Na maioria das vezes, o cliente terá uma breve idéia do que eles precisam no sistema proposto.

O trabalho do analista é a carne-lo, adicione exigências implícitas e requisitos obrigatórios ou regulamentar o cliente pode não estar ciente de e criar um documento chamado de Requisitos de Software Especificação ou SRS.

No final do processo, a SRS acaba por ser a cópia azul do produto. Um ponto de referência para o cliente, o gerente do projeto, o testador e designer. O SRS devem, idealmente, limitar-se a especificar "o que" o produto deve fazer, em vez de "como" fazer. Nunca incluir detalhes de implementação, tais como a estrutura de banco de dados, arquitetura e assim por diante.

Qual deveria ser a Especificação de Requisitos de Software inclui?

Idealmente, um SRS deve incluir, no mínimo, as seguintes informações.

Requisitos funcionais

Os requisitos funcionais são as "características" de um software tem. Requisitos de exemplo para um carrinho de compras são Loja Procurar, vista detalhada do produto, check-out, Ver carrinho, Minha conta.

O analista deve também identificar as necessidades que o cliente tenha perdido ou aqueles que são necessários para apoiar as principais características. Estes requisitos são chamados de condições implícitas. Por exemplo, se o cliente pediu para um site de compras, o analista inclui requisitos para o carrinho de compras, como o carrinho Ver, Checkout e Excluir do carrinho.

Requisitos não funcionais

Como eficiente é o produto de software? É de alta performance, é confiável, o quão rápido é isso, é que consumir uma grande quantidade de recursos do sistema. Estes são aspectos abordados nos requisitos não funcionais. Programadores iniciantes geralmente não atender a esses requisitos. Estes requisitos afecta directamente a qualidade do produto.

Exigências reguladoras

Em muitas indústrias, pode haver regulamentos em que o produto de software deve cumprir. Por exemplo, as leis fiscais do país em que um produto de contabilidade tem de ser implantado. Preferências de idioma, as leis, as normas de criptografia de senhas padrões de URL, e-mail. Estes são alguns dos requisitos regulamentares que o cliente pode não estar ciente. O analista tem de incluir estes requisitos, se aplicável à indústria ou país em que o produto de software está a ser implantado.

Requisitos de interface externa

Será que este produto interagir com outros softwares ou hardwares? O analista precisa listar os requisitos mínimos dessas interfaces.

Critérios de aceitação

Por fim, os critérios de aceitação deve ser declarada. Quais os critérios que irá confirmar que o software está funcionando de acordo com a especificação do cliente. Normalmente, as especificações testadas serão os requisitos funcionais e não funcionais indicados na SRS.

É importante que todos os requisitos devem incluir o código de função. Isso melhora a rastreabilidade de cada recurso ao longo do ciclo de vida do projeto. No projeto, construção e em fases de testes, os membros do projeto sabem que eles estão projetando, codificação ou teste Recurso n º FE-2 ou FE-45.

Requisitos priorizando

O SRS deve incluir as prioridades para cada recurso. Os clientes podem pedir para alguns recursos para ser concluída no início. Um cuidadosamente priorizados documento de requisitos leva a um desenvolvimento mais rápido das características mais importantes.

Não é a Especificação de Requisitos de Software (SRS) um desperdício de tempo. Quem se beneficia?

Isso é uma falácia. O SRS é útil a todos que tem alguma coisa a ver com o projeto. O gerente de projeto sabe o que planejar. Os designers sabe o que desenhar. Os testadores saber como o produto é esperado para trabalhar. Tudo com a SRS.

Finalmente, o SRS ajuda o cliente a mais. O cliente sabe o que ele vai ficar no final. Geralmente, o desenvolvimento começa somente após o cliente lê e aprova o SRS. Por exemplo, se o cliente quer o sistema do site de compras para incluir uma lista de desejos, ele pode rapidamente digitalizar o SRS e pedir a lista de desejos para ser adicionado, se ele já não estiver lá. Aumentou a entrada do cliente de modo no início do projeto, ajuda a todos saber o que está a ser desenvolvido e que precisa ser desenvolvido em primeiro lugar.

Comente Requisitos de Software

Obtendo os requisitos para a direita nos custos lugar primeiros 50 a 200 vezes menos do que corrigir código. É importante rever o SRS antes de ir para a próxima fase.

Normalmente, uma sessão de revisão irá incluir, pelo menos, 3-4 especialistas e será realizada para um máximo de 2 horas por sessão. Os participantes irão ler o documento antes de participar da reunião. Uma boa revisão irá desenterrar cerca de 60-90% dos defeitos no produto.

Algumas empresas de desenvolvimento de software ignorar essa reunião crucial levando a conseqüências desastrosas. Uma revisão de requisitos simples irá resultar numa poupança líquida Calendário de 10-30%. E sim, estas inspecções são cerca de 20 vezes mais eficaz como testar o produto. Ele vem como nenhuma surpresa que cada hora passada em revisão evita uma média de 33 horas de manutenção.

Gerir a mudança requisitos

Nenhum projeto é estático. Requisitos podem mudar e líder do projeto bom deve aprender a antecipar isso. No entanto, cada mudança nos requisitos custa tempo e dinheiro, especialmente se mudanças cruciais surgem durante a codificação ou testes e pior se ele vem depois do desenvolvimento.

O analista "tem", para tentar minimizar mudanças tardias, tanto quanto possível. A melhor maneira de fazer isso é mostrar ao cliente o que ele vai ficar usando pequenos protótipos e da SRS. Os clientes podem facilmente ver o que eles vão ficar e pedir mudanças muito antes do desenvolvimento já começou. Desta forma, o analista consegue reduzir os custos para o cliente.

No caso de mudanças ocorrem, durante ou após a codificação, o líder do projeto tem de assegurar que essas mudanças são controladas. Todas as mudanças na especificação deve ser aprovado pelo cliente e deve ser revisto pelos membros da equipe. Todos os membros da equipe devem obter cópias do mais recente especificação.

A maioria dos projetos em geral experimentam uma mudança de 25% em requisitos. Methodlogies bons requisitos irá reduzir o n º de mudanças e custo por mudança. Por exemplo, se o RA pode reduzir o número de mudanças de 10% e o custo de mudança por um factor de 5 ou 10, o efeito combinado seria muito grande.

Você não pode código sem análise de requisitos.

Você pode codificar sem qualquer teste de análise de projetos, ou mesmo. Isto é o que a maioria dos programadores fazer.

Clientes, líderes de projetos e programadores geralmente subestimam o valor da análise de requisitos bem e dar-lhe a ir por causa de um produto de software "pode" ser desenvolvidas sem adequada requisitos, design ou testes.

Mas os problemas começam surgindo em vários incidentes não relacionados.

Por exemplo, testador alegam ter concluído os testes e apresentar o projeto para o cliente. O cliente diz: "Ei isso não é o que eu queria. Eu queria que o carrinho de compras para ser armazenado no caso de o cliente decide concluir o processo de compra depois de 2 dias?" O testador não pode mesmo ter conhecido este requisito, o codificador não teria sabido, o líder do projeto não teria conhecido. Finalmente todos trabalham horas extras para desenvolver este novo recurso. O codificador vai alegar que é impossível desenvolver esse recurso com o design existente. Em seguida, o designer tem que torcer para o design de alguma forma incluir o novo recurso. Será que vai ser melhor design? Bem, quem sabe? Ninguém tem tempo para descobrir isso. Eventualmente, depois de toda a confusão que, o cliente é dada a nova função que está mal concebido e executado.

Análise de requisitos é importante em projetos menores.

Em projetos menores, a mesma pessoa poderia analisar, projetar e código. À medida que aumenta o tamanho do projeto, tudo o que acontece é que os papéis são tomadas por pessoas diferentes. O que é pequeno projeto? Qualquer projeto de mais de 2 semanas de duração deve necessariamente incluir o processo de análise de requisitos.