A Importancia Requisitos

A IMPORTÂNCIA DA ANÁLISE DE REQUISITOS NO DESENVOLVIMENTO

Introdução

Obter qualidade nos processos e produtos de engenharia de software

não é uma tarefafácil. Vários fatores dificultam atingir os objetivos de qualidade. No entanto, nada é maisdecepcionante do que produzir um programa que não satisfaça as necessidades dos clientes.Grandes volumes de recursos são gastos, mas em muitos casos ocorre uma grande frustração por parte dos clientes diante da forma final apresentada pelo software.

Experiências indicam que muitos desses problemas são derivados da falta de atenção na horade definir e acompanhar a evolução dos requisitos durante o processo de construção do software. Este trabalho trata exatamente da questão da engenharia de requisitos e sua importância, por meio de uma pesquisa bibliográfica cujo tema “A importância da análise de requisitos no desenvolvimento de softwares”será abordado de uma forma objetiva, podendo assim esclarecer pontos relevantes a todo desenvolvimento se software.

Análise de requisitos do sistema

A análise de requisitos tem por objetivo tratar do processo de definição dos requisitos de software. Para isso, todas as atividades de desenvolvimento precisam ser criteriosamenteelaboradas e desenvolvidas, é essencial que a equipe de desenvolvimento compreendaexatamente o que é esperado do aplicativo a ser construído e também o que o não é. Isso pode parecer óbvio, mas nem sempre fica claro para todos os envolvidos do projeto qual será oalcance da aplicação.A equipe também deve preocupar-se com o desempenho e com a interface exigidos pelocliente. Esse processo deve lidar com diferentes pontos de vista e usar uma combinação demétodos, ferramentas e pessoal, para assim elicitar, analisar e modelar o programa a ser desenvolvido. Os requisitos, tanto para o sistema como para o software, devem ser documentados e revistos com o cliente.Os requisitos, de modo geral, podem ser classificados em dois grandes grupos: requisitosfuncionais e não-funcionais.

2.1 Requisitos funcionais

Os requisitos funcionais são aqueles que descrevem o comportamento do sistema, suasações para cada entrada, ou seja, é aquele que descreve as funcionalidades as quais se espera que o sistema forneça. Eles dependem do tipo de software que está sendo desenvolvido e dosusuários de software que se espera atingir.

2.2. Requisitos não funcionais

Os requisitos não-funcionais não estão ligados diretamente com as funções fornecidas pelo sistema. Em geral se preocupam com padrões de qualidade como confiabilidade,desempenho, robustez, segurança, usabilidade, portabilidade, legibilidade, qualidade,manutenibilidade, entre outros. São muito importantes, pois definem se o sistema seráeficiente para a tarefa que se propõe a fazer. Um sistema ineficiente certamente não seráusado.

3. Softwares “fast food”

Atualmente com o rápido desenvolvimento das tecnologias e com as várias facilidadesque encontramos para a comunicação, empresas de todos os portes acreditam que quanto maisrápido o software estiver pronto para ser usado, melhor. É aí que eles se enganam, softwares“fast food ” podem dar a impressão de estar agilizando o trabalho, mas os problemas logoaparecem.

Softwares não são feitos da noite para o dia. Eles englobam muito mais que linhas decódigo. Horas de testes, manuais, documentação e treinamento fazem parte de um sistema bem desenvolvido. Se o cliente exige um prazo absurdamente curto, é melhor nem começar odesenvolvimento. O software desenvolvido dessa maneira terá tanto problema no futuro que oque pedir para fazê-lo não valerá a pena. Percebemos isso claramente no trecho a seguir:

Interessante ver que as grandes conquistas não são feitas a toque decaixa. Dias atrás reli o livro 100 dias entre o céu e o mar de Amyr Klink onde ele narra não somente sua travessia pelo Atlântico em um barco a remo,mas principalmente os anos de preparativos para a empreitada. Não é a toaque Klink é um dos melhores palestrantes brasileiros quando se desejaconhecer estratégia e pés no chão. Ele sabe o que faz e principalmente quetempo não é uma questão de dinheiro; é uma questão de coerência. O tempoque se ganha agora pode-se perder pouco depois.(Amyr Klink apud Paulino Michelazzo- On-line).

Em primeiro lugar, é importante identificar o que não contribui para o fracasso nesse tipode software. Jim Johnson, do The Standish Group, afirma que "quando um projeto falha,raramente a causa é técnica". Com isso pode-se afirmar que o problema não é se o .NET, Javaou outras tecnologias e ferramentas sejam instrumentos limitados para a construção de softwares. A raiz da maioria das falhas está na (ausência de) utilização de metodologias dedesenvolvimento adequadas e como elas interagem com os stakeholders

em um projeto desoftware.Se a metodologia adotada não for seguida corretamente é certo que o produto final sofreráas conseqüências.Um dos piores problemas que a utilização de uma metodologia pode apresentar é ignorar o cliente e o usuário final em um projeto. A falta de envolvimento de ambos durante todo odesenvolvimento está diretamente relacionada ao fracasso, pois serão o cliente e o usuáriofinal que saberão especificamente o que o sistema deverá realizar. Por melhor preparados queos desenvolvedores estejam, não saberão ao certo quais funcionalidades deverão estar habilitadas