UNIVERSIDADE VEIGA DE ALMEIDA

SWELLEN POLIDE DEZERBELLES

A IMPORTÂNCIA DA ANÁLISE DE REQUISITOS NO

DESENVOLVIMENTO DE SOFTWARES

Cabo Frio

2008.02

SWELLEN POLIDE DEZERBELLES

A IMPORTÂNCIA DA ANÁLISE DE REQUISITOS NO

DESENVOLVIMENTO DE SOFTWARES

Trabalho apresentado à Profª.: Ms. Patrícia

Ribeiro Corado como meio de avaliação

parcial da disciplina Metodologia Científica.

Cabo Frio

2008.02

Sinopse

Este trabalho tem como principal objetivo mostrar o quão difícil e importante é a atividade do profissional que lida com o desenvolvimento de softwares, mais precisamente aquele que lida com a análise de requisitos. Para isso boa parte dessa atividade de análise será abordada ao decorrer do paper, os requisitos funcionais e não-funcionais serão explicados e os chamados softwares “Fast food” serão analisados, será que rapidez é a chave para o sucesso ou o ditado popular tem realmente razão ao dizer que “apressado como cru”?

1. Introdução

Obter qualidade nos processos e produtos de engenharia de software não é uma tarefa

fácil. Vários fatores dificultam atingir os objetivos de qualidade. No entanto, nada é mais

decepcionante 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 encomendado.

Experiências indicam que muitos desses problemas são derivados da falta de atenção na hora

de 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 de software.

2. 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 criteriosamente

elaboradas e desenvolvidas, é essencial que a equipe de desenvolvimento compreenda

exatamente 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á o

alcance da aplicação.

A equipe também deve preocupar-se com o desempenho e com a interface exigidos pelo

cliente. Esse processo deve lidar com diferentes pontos de vista e usar uma combinação de

mé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: requisitos

funcionais e não-funcionais.

2.1 Requisitos funcionais

Os requisitos funcionais são aqueles que descrevem o comportamento do sistema, suas

açõ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 dos

usuá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 facilidades

que encontramos para a comunicação, empresas de todos os portes acreditam que quanto mais

rá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 logo

aparecem.

Softwares não são feitos da noite para o dia. Eles englobam muito mais que linhas de

có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 o

desenvolvimento. O software desenvolvido dessa maneira terá tanto problema no futuro que o

que 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 de caixa. 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 toa que Klink é um dos melhores palestrantes brasileiros quando se deseja conhecer estratégia e pés no chão. Ele sabe o que faz e principalmente que tempo não é uma questão de dinheiro; é uma questão de coerência. O tempo que 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 tipo

de 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, Java

ou 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 de

desenvolvimento adequadas e como elas interagem com os stakeholders em um projeto de

software.

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 o

desenvolvimento está diretamente relacionada ao fracasso, pois serão o cliente e o usuário

final que saberão especificamente o que o sistema deverá realizar. Por melhor preparados que

os desenvolvedores estejam, não saberão ao certo quais funcionalidades deverão estar

habilitadas nesse software.

Somente muita comunicação entre os desenvolvedores, cliente e usuário final trará as

informações necessárias para que se possa começar o desenvolvimento do sistema. Embora

esta comunicação não seja fácil, também não é impossível. O grande problema é que o cliente

nem sempre sabe como expressar suas idéias e exigências, muitas vezes ele até sabe o que

quer do sistema, mas tem uma idéia distorcida do que o software pode fazer por ele.

4. Atividades do processo de análise de requisitos

Empresas distintas lidam de formas diferentes com a análise de requisitos. Uma

companhia aeroespacial não utiliza o mesmo processo de análise que uma outra companhia

que desenvolve produtos de consumo para desktops, pois as funcionalidades e objetivos de

cada um desses programas serão bastante diferentes. Essas diferenças encontram-se

geralmente no nível de detalhe dos processos.

As atividades do processo de análise de requisitos podem ser divididas nas seguintes

àreas:

Levantamento de requisitos – Nessa etapa, os membros da equipe de desenvolvimento

trabalham juntamente com o cliente e os usuários finais do sistema, afim de descobrir

informações sobre o domínio da aplicação, que serviços o sistema deve fornecer, o

desempenho exigido do sistema, as restrições de hardware, entre outros. Além de

consultas aos stakeholders, pode-se também obter informações através de

documentação do sistema e estudos do mercado.

Análise e negociação de requisitos - Os requisitos são analisados em detalhe e os

diferentes stakeholders negociam para decidirem que requisitos serão utilizados no

desenvolvimento do software. Este processo é necessário, pois sempre aparecem

conflitos entre requisitos de diferentes fontes, as informações podem não ser

completas ou então os requisitos podem ser incompatíveis com o orçamento

disponível para o desenvolvimento do sistema.

Documentação de requisitos – Os requisitos especificados durante o processo de

negociação são documentados e detalhados nessa etapa. Esses requisitos devem ser

detalhados utilizando linguagem natural e diagramas, para que sejam compreendidos

por todos os stakeholders.

O fato de se ter uma boa documentação do software, traz várias vantagens para o

desenvolvedor na hora de prestar manutenção a esse programa, pois através dos

detalhes mostrados nesse documento é mais fácil entender o problema e modificá-lo.

Validação de requisitos – Se preocupa em mostrar se os requisitos levantados

realmente definem o sistema que o cliente solicitou e também analisa esses requisitos

afim de descobrir qualquer problema que comprometa a funcionalidade do software.

Esta validação é importante porque a ocorrência de erros no documento de

requisitos pode levar a grandes custos relacionados ao retrabalho, quando esses erros

são descobertos durante o desenvolvimento ou depois que o sistema estiver em

operação. O custo de fazer uma modificação no sistema, resultante de um problema de

requisito, é muito maior do que reparar erros de projeto ou de codificação. Qualquer

mudança nos requisitos implica em uma boa mudança no projeto, na implementação

do software, e é claro haverá a necessidade da realização de um novo teste no sistema.

Pode- se afirmar que essas atividades do processo de análise de requisitos não são

realizadas numa ordem rigorosa, pois o cliente sempre tem uma sugestão ou uma exigência a

fazer durante toda a evolução do projeto. Sendo assim a análise continua durante a definição e

especificação, com isso novos requisitos surgem no decorrer do desenvolvimento.

5. Conclusão

Depois dessas informações, pode-se afirmar que realmente “apressado como cru”, afinal

softwares não são feitos da noite para o dia. Eles requerem muito mais que linhas de código,

necessitam que todas as etapas do processo de análise de requisitos sejam seguidas

corretamente.

O trabalho do analista de sistemas é árduo e requer muita atenção, deve-se definir desde

as reuniões iniciais uma metodologia a ser seguida, é possível afirmar que sem uma correta

definição da metodologia a ser utilizada e uma boa gestão dos requisitos do aplicativo é certo

que o projeto terá o seu sucesso comprometido, frustrando as expectativas do cliente e

comprometendo as metas e planos da empresa contratante.

Referências Bibliográficas

CORDEIRO, Marco Aurélio. A Importância da Engenharia de Requisitos. Disponível em:

http://www.pr.gov.br/batebyte/edicoes/2000/bb98/requisitos.htm. Acesso realizado em:

15/09/2008

DA ROCHA, Ana Regina Cavalcanti et all (org.). Qualidade de software: Teoria e prática.

São Paulo: Pearson, 2004

FURTADO, André. Pontas do iceberg do Caos no Desenvolvimento de Software. Disponível

em http://www.microsoft.com/brasil/msdn/Tecnologias/Carreira/DesenvolvimentoSoftware.

Acesso realizado em 01/11/2008

GIMENEZ, Itana. Processos de desenvolvimento. In: DA ROCHA, Ana Regina Cavalcanti,

MALDONADO,José Carlos, WEBER,Kival Chaves (org.). Qualidade de software: Teoria e

prática. São Paulo: Pearson, 2004

MELO, Ana Cristina. Desenvolvendo Aplicações com UML 2.0. 2 ed. Rio de Janeiro:

Brasport, 2004

MICHELAZZO, Paulino. Softwares “fast food”. Disponível em

http://www.linhadecodigo.com.br/Artigo.aspx?id=1892. Acesso realizado em 01/11/2008

PRESSMAN, Roger. Engenharia de software. São Paulo: Pearson,2006

SILVA, Márcio Andrade. A importância do levantamento de requisitos no sucesso dos

projetos de software. Disponível em: http://www.linhadecodigo.com.br/Artigo.aspx?id=1685.

Acesso realizado em: 01/11/2008