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